DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

Mailman List Mirror (Read Only)
1

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! :slight_smile:

Greets,
Jeroen

[1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
[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/

2

Hi Folks,

Hi.

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]).

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.

3

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? :slight_smile:
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.html

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-HowTheInternetSeesYou/

4

Why on Earth would anyone want that (Firefox deciding to do it’s own DNS) as default behavior?

5

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

6

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.

7

In article <8580e3e4-98b8-2828-e43f-6115c92faee5@massar.ch> you write:

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.

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.

8

powerdns dnsdist supports dns over https so you don’t have to be held hostage by cloudflare or google.

9

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

10

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

11

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

12

DOH isn?t inherently bad, but every implementation
of DOH that I am aware of involves depriving the
user of choice and/or control

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

13

The enterprise as well. I’m certain many are blindly unaware as this could have negative impacts beyond traditional control.

J~

14

DOH isn?t inherently bad, but every implementation
of DOH that I am aware of involves depriving the
user of choice and/or control

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.)

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.

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.

Yeah, the part they leave out is that name servers like 2001:4860:4860::8888 and 2001:4860:4860::8844 are on that list.

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 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?

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.

OK, but what about the network operator’s ability to defend against an untrusted user?

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.)

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