12 Lis
2019
12 Lis
'19
8:32
Now that Firefox blocks 3rd-party cookies by default, many sites try to
hide the fact that a cookie is 3rd-party by using CNAMEs.
% kdig +short A ftn.fortuneo.fr
ftn-fr.eulerian.net.
ftn.eulerian.net.
109.232.194.56
I want to block all the requests to *.eulerian.net.
policy.add(policy.suffix(policy.DENY, {todname('eulerian.net.')}))
Does not work since, to quote the documentation "The policy module
currently only looks at whole DNS requests. The rules won’t be
re-applied e.g. when following CNAMEs."
% kdig A ftn.eulerian.net
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 42477
...
ftn.eulerian.net. 10800 IN SOA ftn.eulerian.net. nobody.invalid. 1 3600 1200 604800
10800
% kdig A ftn.fortuneo.fr
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 59262
...
ftn.fortuneo.fr. 600 IN CNAME ftn-fr.eulerian.net.
ftn-fr.eulerian.net. 5799 IN CNAME ftn.eulerian.net.
ftn.eulerian.net. 5799 IN A 109.232.194.56
This seriously limits the usefulness of policy.DENY. What are the
possible solutions?
12 Lis
12 Lis
9:05
Hello!
On 11/12/19 8:32 AM, Stephane Bortzmeyer wrote:
This seriously limits the usefulness of policy.DENY.
What are the
possible solutions?
Right, normal policy rules only apply once before request starts.
The only easy solution I can think of is to use hints module, assuming
it's sufficient to (1) block particular names (not subtrees) and (2)
only redirect them to some address that will fail fast instead of really
blocking them (e.g. localhost).
[hints]
https://knot-resolver.readthedocs.io/en/stable/modules.html#static-hints
All others ways would be like writing one's own module, I think. We've
been thinking of redesigning the user APIs around policies because of
this and a couple other reasons. People usually don't seem to think of
this imperatively (what actions to do at some points in the resolution
process) but more like modifying the official DNS tree. Still, at this
point I only have some vague ideas about this.
--Vladimir
9:16
On Tue, Nov 12, 2019 at 09:05:29AM +0100,
Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote
a message of 24 lines which said:
Right, normal policy rules only apply once before
request starts.
So, same thing for RPZ?
The only easy solution I can think of is to use hints
module, assuming
it's sufficient to (1) block particular names (not subtrees)
Unfortunately no, in that case.
People usually don't seem to think of this
imperatively (what
actions to do at some points in the resolution process) but more
like modifying the official DNS tree.
Well, now that a *lot* of Web sites are using this technique to hide
the fact that they use 3rd-party cookies, I tend to think it is
important to have a solution.
10:00
On 11/12/19 9:16 AM, Stephane Bortzmeyer wrote:
Correct.
I'll think on the CNAME policies a bit more. There might be some
medium-term improvement - one that's not too hacky, before we get to
completely rewrite this API to some declarative style. Some additional
information has collected on this issue:
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/217
Right, normal
policy rules only apply once before request starts.
So, same thing for RPZ?
10:38
On 11/12/19 9:16 AM, Stephane Bortzmeyer wrote:
Well, now that a *lot* of Web sites are using this
technique to hide
the fact that they use 3rd-party cookies, I tend to think it is
important to have a solution.
This particular case feels like it might become just an arms-race. When
CNAMEs stop being sufficiently efficient, they can just copy the address
records into their zones - and I think some forms of automatic CNAME
flattening actually aren't too rare at large DNS hosters, though I
suppose the main motivation there is to get a CNAME at zone apex. (I
don't know how much these services are currently usable at deeper places.)
Still, I certainly don't want to dismiss the usefulness of filtering
CNAME targets, and perhaps the tracker situation will never come so far.
25 Lis
25 Lis
16:46
On Tue, Nov 12, 2019 at 08:32:01AM +0100,
Stephane Bortzmeyer <stephane(a)bortzmeyer.org> wrote
a message of 20 lines which said:
Now that Firefox blocks 3rd-party cookies by default,
many sites try to
hide the fact that a cookie is 3rd-party by using CNAMEs.
A good explanation of this "CNAME cloaking":
https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-p…
27 Lis
27 Lis
15:35
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi everyone,
on the topic of answer filtering:
1. If you want to play with blocking answers based on domain names please give a try to
the attached plugin experimental_filter.lua.
This plugin inspects owner names for each RRset in ANSWER section, and if any of the names
is present in the configured black list the original answer is replaced with new empty
answer with RCODE=REFUSED.
The plugin file experimental_filter.lua has usage instructions in its header.
2. As others already pointed out [1] we can expect arms race, where domain owners either
copy A/AAAA records into their zones, or delegate a sub-domain to a tracking company. In
the end the situation is likely to require IP-address blacklisting.
Blocking based on IP addresses in answers can be done using rebinding module, see attached
example config file.
Please report your experience back to us, we are curious what interesting consequences
this module and configuration will have in practice.
Enjoy.
Petr Špaček @ CZ.NIC
[1] https://github.com/uBlockOrigin/uBlock-issues/issues/780#issuecomment-55632…
On 25. 11. 19 16:46, Stephane Bortzmeyer wrote:
On Tue, Nov 12, 2019 at 08:32:01AM +0100,
Stephane Bortzmeyer <stephane(a)bortzmeyer.org> wrote
a message of 20 lines which said:
Now that Firefox blocks 3rd-party cookies by
default, many sites try to
hide the fact that a cookie is 3rd-party by using CNAMEs.
A good explanation of this "CNAME cloaking":
https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-p…
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl3eiaQACgkQzo3WoaUK
IeR6yRAAp44fTwIfxJA/3cI/3W/r8KVRwOunsmXfNK2moT3HuoZw1U559BXq6Ibg
5P2eT3e9pnYQiE1qeMpq9OEeiLZRIITNn//gaiicUtbpqsYCtwQyPqVGaIXLz2SI
Xwnyj6lPG/wwL+efYRn/cPW/twzZ4u59XMhPNFFAmwYS59AYlUEEmL1v2AqMUhrP
Fv9McvkUM24iBA1ytb66V5ODSemDL9JtLWqxCn7NRVjZ1bey9UHfyIdVHfK59Cnq
7B5jUXH8YxJRR1Ye90yirTs+RgCWfWYtebD5bSkmVrf65mexJ2O3Ulnbd7GQgyB4
PvyOkdDPz2iLeVmw6PbAaAG/w8lGdGI3hVMNh9nTjotJekvbiB0SG3tSFkuXZdGf
mqSObuvE5lwhKB+QVRzZ62Gr0Fjs2WynCaUqZhem6rZrJaR7PvIh+GZm24fW00WF
AgqMIYk4kG3dLuLLPtDuvdqEtJAd0oDnSNyXHy9p5MUiI6mo8+EUUoIYyXATX5cC
SqjyRYZH2710KbbE6GpVvpzZr6ja2bQ6YJY+OfqT+Ou7SX9Wd8o1bRuk4n8DOku0
SJphMzJdDCj+ko1Z8xmPfXE7QGyhnCsRNANOlZPrmYviWtN2kQLYuWJBAdtR/k9L
MTAKeRFQxgjkivQSkK2YgOrgpmpCgYSqCiAWZC6I6HCDxGqeXjs=
=cdMH
-----END PGP SIGNATURE-----
1626
days inactive
1641
days old
knot-resolver-users@lists.nic.cz
6 comments
3 participants
participants (3)
-
Petr Špaček -
Stephane Bortzmeyer -
Vladimír Čunát