DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users
Hi Folks, While in the US soon all Firefox users will *NOT* use your DNS Recursives configured using DHCP anymore (NXDOMAIN use-application-dns.net to avoid that[1]). Next to that, it seems some of the root operators are now creating instances in the same networks that offer these kind of services for globally figuring out what queries are being made. For those that thus either opt-out or otherwise want to use their own system resolvers, I suggest that all that run DNS Recursive setups enable "QNAME minimization" as defined in (experimental) RFC7816 [2] For pdns "qname-minimization=yes" [6] For unbound "qname-minimisation: yes" [5] For BIND "qname-minimization" option [3] and [4] Of course, do also provider your users with the option of using DoT or even DoH on your recursors... Noting that DoH operators are supposed to enable RFC7816 also [7], guess they do not want others to see all the details they get... Some more details in DNS Privacy Wiki [8]... Discuss! :) Greets, Jeroen [1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-h... [2] https://tools.ietf.org/html/rfc7816 [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf [6] https://github.com/PowerDNS/pdns/issues/2311 [7] https://wiki.mozilla.org/Security/DOH-resolver-policy [8] https://dnsprivacy.org/wiki/
On Wed, 2019-09-18 at 09:15 +0200, Jeroen Massar wrote:
Hi Folks,
Hi.
What am I misunderstanding? Isn't use-application-dns.net supposed to return A results until "defeated"? I have not configured my own DNS server to NXDOMAIN that yet, however: $ dig use-application-dns.net a ; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> use-application-dns.net a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33589 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; Query time: 1181 msec ;; SERVER: fd31:aeb1:48df::2#53(fd31:aeb1:48df::2) ;; WHEN: Wed Sep 18 06:22:19 EDT 2019 ;; MSG SIZE rcvd: 52 And even Google's global DNS: $ dig @8.8.8.8 use-application-dns.net a ; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> @8.8.8.8 use-application- dns.net a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33725 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; Query time: 1454 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Sep 18 06:22:42 EDT 2019 ;; MSG SIZE rcvd: 52 Cheers, b.
On 2019-09-18 12:24, Brian J. Murrell wrote:
That just means that somebody broke that setup as it worked last week and was pointing to Github Pages serving: https://github.com/agrover/global-canary/ Maybe Google does not want Mozilla/CloudFlare to get all the DoH queries? :) Nah likely just a failure somewhere, as both are supported heavily by Google (if there was no competition then Google would truly have a monopoly in the browser market and that would be bad, at least with them funding Mozilla and CF through the backdoor it looks like it isn't a monopoly as there "is that other thing") There is a little thread about that domain here on dns-operations: https://lists.dns-oarc.net/pipermail/dns-operations/2019-September/019179.ht... Currently though: use-application-dns.net. 172800 IN NS ns-cloud-b1.googledomains.com. use-application-dns.net. 172800 IN NS ns-cloud-b2.googledomains.com. use-application-dns.net. 172800 IN NS ns-cloud-b3.googledomains.com. use-application-dns.net. 172800 IN NS ns-cloud-b4.googledomains.com. $ dig @ns-cloud-b1.googledomains.com. use-application-dns.net. a [..] ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21669 ... that is from my test host, but of course, from my other hosts it nicely NXDOMAINs.... but those hosts also route 1.1.1.1/8.8.8.8/8.8.4.4 and the IPv6 equivalents and many other such IPs (OpenDNS, etc and even root servers) to the local anycasted edition.... cause I don't want that in my networks. Then again, as that makes me not a sheep, I am likely more visible anyway...[1] Greets, Jeroen [1] https://jeroen.massar.ch/presentations/vid/27C3-JeroenMassar-HowTheInternetS...
In article <8580e3e4-98b8-2828-e43f-6115c92faee5@massar.ch> you write:
Nope. ;; ANSWER SECTION: ;; AUTHORITY SECTION: use-application-dns.net. 172800 IN NS ns4-64.akam.net. use-application-dns.net. 172800 IN NS ns7-66.akam.net. use-application-dns.net. 172800 IN NS ns5-65.akam.net. use-application-dns.net. 172800 IN NS ns1-240.akam.net. $ drill @ns5-65.akam.net. use-application-dns.net a ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48353 ;; flags: qr aa rd ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; use-application-dns.net. IN A ;; ANSWER SECTION: use-application-dns.net. 60 IN A 185.199.108.153 use-application-dns.net. 60 IN A 185.199.109.153 use-application-dns.net. 60 IN A 185.199.111.153 use-application-dns.net. 60 IN A 185.199.110.153 I have this special-cased in my own resolver, of course. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Why on Earth would anyone want that (Firefox deciding to do it's own DNS) as default behavior? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jeroen Massar" <jeroen@massar.ch> To: "NANOG" <nanog@nanog.org> Sent: Wednesday, September 18, 2019 2:15:49 AM Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users Hi Folks, While in the US soon all Firefox users will *NOT* use your DNS Recursives configured using DHCP anymore (NXDOMAIN use-application-dns.net to avoid that[1]). Next to that, it seems some of the root operators are now creating instances in the same networks that offer these kind of services for globally figuring out what queries are being made. For those that thus either opt-out or otherwise want to use their own system resolvers, I suggest that all that run DNS Recursive setups enable "QNAME minimization" as defined in (experimental) RFC7816 [2] For pdns "qname-minimization=yes" [6] For unbound "qname-minimisation: yes" [5] For BIND "qname-minimization" option [3] and [4] Of course, do also provider your users with the option of using DoT or even DoH on your recursors... Noting that DoH operators are supposed to enable RFC7816 also [7], guess they do not want others to see all the details they get... Some more details in DNS Privacy Wiki [8]... Discuss! :) Greets, Jeroen [1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-h... [2] https://tools.ietf.org/html/rfc7816 [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf [6] https://github.com/PowerDNS/pdns/issues/2311 [7] https://wiki.mozilla.org/Security/DOH-resolver-policy [8] https://dnsprivacy.org/wiki/
Because getting each ISP in the world to comply with NSA monitoring requests was too hard, instead they get to centralize the full list of every website the everyone in the world visits on a single fleet of servers in Cloudflare's datacenters. This means we only need to compromise one person to monitor the world, saving the US taxpayer significantly. Progress! Matt
For efficiency of censorship. If you want to stop some domain name from resolving you have to get everyone on the planet to block that DNS resolution in their recursive resolver. However, if everyone uses the same single DNS server operated by a single entity, then you only have to coerce that one entity to block resolution of that DNS name. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
For anyone considering enabling DOH, I seriously recommend reviewing Paul Vixie’s keynote at SCaLE 18x Saturday morning. https://www.youtube.com/watch?v=artLJOwToVY It contains a great deal of food for thought on a variety of forms of giving control over to corporations over things you probably don’t really want corporations controlling in your life. Owen
On Tue, Mar 10, 2020 at 5:30 PM Owen DeLong <owen@delong.com> wrote:
Depends on your threat model: ISPs, Big Tech companies, State-level actors, random hacker at the same Wi-Fi network. The problem with DoH is that software developer picks the threat model he or she thinks is most relevant, and applies to all use cases. Solution is to ask user what is the user threat model and apply it. DoH/DoT are not harmful per se, their indiscriminate usage is. Rubens
Yes and no… DOH isn’t inherently bad, but every implementation of DOH that I am aware of involves depriving the user of choice and/or control and also depriving network operators of the ability to enforce the “my network, my rules” concept. While I realize some may argue that this is desirable in some instances, understand that I’m not talking about the ISP level, but even within the home. Parents should be able to enforce DNS policy on their children, for example. DOH allows the average child to generally bypass any such limitations. Worse, most parents are unlikely to even realize that this is the case. Owen
Owen DeLong <owen@delong.com> wrote:
I don't think that's quite correct. There is an unfortunate and persistent conflation of "DoH" with "DoH to a centralized third-party resolver"; that is largely Mozilla's fault, but even for Firefox the argument can be made that that is not _depriving_ the user of choice, but enabling their choice. (Defaults being seen as no-choice seems a stretch, even if we know the majority of users will not (know how to) change the defaults.) Google, for example, has noted that they have no plans to follow Mozilla's example, and instead will only use DoH if the local stub resolver in question is on their explicit shortlist of DoH resolvers. That is, the user (or the organization controlling the end-point) have already set the stub resolver to that service; if the user changes the stub resolver to point to some other IP, then Chrome will _not_ override that and use DoH to e.g., Google's public resolver.
and also depriving network operators of the ability to enforce the ?my network, my rules? concept.
The network operator has _some_ control, but that control is limited by design, as the primary threat model for DoH and especially for _DoH to a third-party resolver_ is to defend against an untrusted network operator. That is indeed the argument of increased choice made by Mozilla: if a user explicitly enables DoH to a given server, they can enable it to be mandatory with no fallback and the network operator cannot change that. (Unless the network operator is also in control of the user's device, of course.) -Jan
When you change the way a system works and make the new behavior “opt-out”, especially when you present the option in such a misleading way, I’ll stand by my statement.
Yeah, the part they leave out is that name servers like 2001:4860:4860::8888 and 2001:4860:4860::8844 are on that list.
And you think that the average internet user has a sufficient level of understanding to make an informed choice about this, let alone implement said choice?
OK, but what about the network operator’s ability to defend against an untrusted user?
Right… Now put yourself in the position of a typical parent who works in a widget factory and has all the skills necessary to find the power switch on a computer. Said parent’s pre-teen child decides that DoH can lock dad out of snooping her web-surfing and chat room choices and, so, enables it. Dad, in the meantime, has decided to depend on the Disney service that came bundled with his Netgear router and is assuming that has him covered there and won’t allow her to resolve adult sites and risky chatrooms. Do you not see a problem here? Owen
participants (11)
-
Brian J. Murrell -
Curtis Maurand -
Jan Schaumann -
JASON BOTHE -
Jeroen Massar -
John Levine -
Keith Medcalf -
Matt Corallo -
Mike Hammett -
Owen DeLong -
Rubens Kuhl