On 2019-09-18 12:24, Brian J. Murrell wrote:

On Wed, 2019-09-18 at 09:15 +0200, Jeroen Massar wrote:

...

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:

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

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.

-----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Mike Hammett Sent: Wednesday, 18 September, 2019 08:19 To: Jeroen Massar <jeroen@massar.ch> Cc: NANOG <nanog@nanog.org> Subject: Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

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

----- Mike Hammett Intelligent Computing Solutions <http://www.ics-il.com/> <https://www.facebook.com/ICSIL> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> <https://www.linkedin.com/company/intelligent-computing-solutions> <https://twitter.com/ICSIL> Midwest Internet Exchange <http://www.midwest-ix.com/> <https://www.facebook.com/mdwestix> <https://www.linkedin.com/company/midwest-internet-exchange> <https://twitter.com/mdwestix> The Brothers WISP <http://www.thebrotherswisp.com/> <https://www.facebook.com/thebrotherswisp> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>

________________________________

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

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 Sep 27, 2019, at 10:33 , Curtis Maurand <cmaurand@xyonet.com> wrote:

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

On 9/18/19 10:19 AM, Mike Hammett wrote:

...

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

----- Mike Hammett Intelligent Computing Solutions <http://www.ics-il.com/> <https://www.facebook.com/ICSIL> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> <https://www.linkedin.com/company/intelligent-computing-solutions> <https://twitter.com/ICSIL> Midwest Internet Exchange <http://www.midwest-ix.com/> <https://www.facebook.com/mdwestix> <https://www.linkedin.com/company/midwest-internet-exchange> <https://twitter.com/mdwestix> The Brothers WISP <http://www.thebrotherswisp.com/> <https://www.facebook.com/thebrotherswisp> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> From: "Jeroen Massar" <jeroen@massar.ch> <mailto:jeroen@massar.ch> To: "NANOG" <nanog@nanog.org> <mailto: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 <http://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... <https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https> [2] https://tools.ietf.org/html/rfc7816 <https://tools.ietf.org/html/rfc7816> [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ <https://www.isc.org/blogs/qname-minimization-and-privacy/> [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 <https://gitlab.isc.org/isc-projects/bind9/issues/16> [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf <https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf> [6] https://github.com/PowerDNS/pdns/issues/2311 <https://github.com/PowerDNS/pdns/issues/2311> [7] https://wiki.mozilla.org/Security/DOH-resolver-policy <https://wiki.mozilla.org/Security/DOH-resolver-policy> [8] https://dnsprivacy.org/wiki/ <https://dnsprivacy.org/wiki/>

On Mar 11, 2020, at 18:31 , Rubens Kuhl <rubensk@gmail.com> wrote:

On Tue, Mar 10, 2020 at 5:30 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: 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 <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.

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

On Mar 11, 2020, at 19:25 , Jan Schaumann <jschauma@netmeister.org> wrote:

Owen DeLong <owen@delong.com> wrote:

...

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