This is the discussion separation I am requesting. There is benefit of in-transit encryption regardless of who the endpoint is. There may also be benefits to defaulting to non-system DNS, but those discussions should be separate IMO.
Also "not the ISP" != "non-system dns". Don't conflate that just because browsers were first/most famous to implement.
I liken these arguments to the same ones made in the past by our more-naive selves concerning encryption of corporate intranet traffic. We should be smarter now.
Encrypting traffic, internal or external, only makes sense if you don't trust whatever you happen to plug in to tell you what to trust. OWE in Wi-Fi has similar faults.
But whoever runs the resolver you use gets to see what domainnames you're resolving. Your resolver's operator will be sorely tempted to monetize that metadata.
Your only choice is which resolver operator you'll allow to monetize your metadata.
So you lose no matter what, unless you have a contract with the operator, and then you'd better be giving them something of value if you want to be able to enforce the contract's confidentiality requirements.
ISPs mostly don't even support DoH/DoT, which is a reason to not want to use their resolvers. But using public resolvers helps centralize the DNS, which is not good.
I preemptively agree that Cloud Flare is not one of those organizations.
It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
The choice of DoT vs DoH will mostly be about what is supported by one's choice of resolver. Of course, choosing DoH first will narrow the choice of resolvers.
Then there's captive portal situations.
But this isn't a stable equilibrium; as I said, it seems clear that privacy-minded organizations will eventually stand up their own trustworthy DoH resolvers.
DoH makes things somewhat better today for all users, and much better for power users. In the long term, it's easy to see how DoH makes things much better for everybody.
But I don't disagree that DoH is better.
I do hope that in the long run ISPs become less toxic.
That means running your own caching resolver, with a local copy of the root zone and QNAME minimization enabled, and then using DNS-over-TLS to forward the minimum necessary query onward.
The next question then becomes whether to perform recursion yourself (by talking directly with authoritative nameservers) or to have Quad9 or another recursive server perform the recursion for you. Authoritative nameservers don't yet support transport encryption, though we're working very hard to support it on the 500 TLDs PCH is authoritative for, and Verisign is working very hard to support it on .COM and .NET. So that means that your traffic is subject to interception, and essentially all authoritative servers either log queries or have people logging queries off the wire in front of them. And if you're handling your own recursion, everything you don't have cached crosses the wire, and none of it is blended together with anyone else's traffic.
To make the decision as to whether it's better to trust a recursive or send queries directly, knowing something about the practices and purpose of the recursive is necessary. Quad9 is the only major recursive that's a public-benefit not-for-profit. There are other small ones which are not-for-profits (like the Taiwanese 101.101.101.101, operated by TWNIC), but all of the others that come near Quad9's scale or traffic are for-profit, operated by companies that monetize data. Quad9 and Cisco's commercial Umbrella service are the only two which are GDPR-compliant and thus legal to provide to European citizens.
Quad9 exists solely so that bad choices won't be the only choices.
-Bill Woodcock
Chairman of the Board of Directors
Quad9Perhaps a parent wants something that's easier to filter.
Paul Vixie has said a lot on this topic.
And to me, who works in IT, it's a bloody annoying.
We've already implemented the use-application-dns.net NXDOMAIN canary at work because after some testing Firefox breaks a bunch of apps because of split-horizon DNS.
There's already (at least) two malware that's using DoH to get around network monitoring:
* https://www.zdnet.com/article/first-ever-malware-strain-spot...
* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...
If the host is compromised we can no longer trust end-point monitoring, and with DoH/ESNI we lose network monitoring. Awesome. Great work.
DoH+ESNI will make it even harder.
It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.
This is amplified by moving DNS resolution into applications, Mozilla style. Now even the operating system or local firewall applications (Little Snitch, etc) can't know, where the processes are connecting.
Again, the application vendors can have objectives that are not aligned with the users. It is a mistake to conflate the home users with random applications running on their computers.
The argument is, that a random process should not be a world into itself; there should be a way to check on what it is doing. It does not have to be network based, it can be done by another process on the local machine. Things like DNS should be done by the OS, with hooks for the monitoring. It should be not be done by the application, with zero transparency to the owner. The system resolver, on the other hand, can use DoH/DoT/ESNI/whatever.
Giving random processes unlimited, uncontrolled and uncontrollable access to Internet is disaster waiting to happen. Quite similar to what happened to applications on Android.
I don't know, whether I'm expressing badly due to English not being my native language, or where is the problem in understanding. I hope that you are not just misunderstanding intentionally.
So once again: The combination of ESNI and DNS resolving inside applications (and not OS, not checked by some user agent) provides privacy to application, not users. That application might or might not have its objectives aligned with the users; more often than not, it will focus on interests of its vendor instead. So conflating privacy for application with privacy for user is mistake.
By applications using custom DNS+ESNI, the user loses control over who the application communicates with, he just sees that it can send and receive blobs. What it is sending out, to whom, is and will be unknown. That is the negative wrt user's privacy, compared to which the current Android ecosystem is squeaky clean.
As a 'network operator' at work and home, it is my responsibility to keep my network clean. Both for my own sake and for the sake of the greater Internet (is malware being spread from my network?).
End-host security is used to make sure that connected systems are clean. But if the end-host is compromised, then that may now become useless. So a second level of security is network monitoring.
However, how can I be responsible network operator if I have no visibility into my own infrastructure? DoH by-passing local DNS, and ESNI cloaking the destinations, make it impossible to see who is doing what. At least with Do53 (and DoT) I can control lookups (possibly to C&C servers).
A real client expects the encrypted parts that follow Certificate to match up and should abort if they don't, but malware is under no obligation to do that, and a 3rd party which can't decrypt the rest of the handshake won't know e.g.
Malware client: SNI for bigbank.example (knowing bigbank will have been excluded from snooping rules at the target)
Malware C&C server: 100% Legitimate Certificate copied from bigbank.example
Malware client: Cool, let's continue with encrypted setup (ignores the pretence that this is bigbank.example and now communicates with the C&C server undetected and encrypted knowing the logs will just show "bigbank.example")
"Security" products can't protect against this without snooping each and every single transaction, but many will be deployed by ignorant/ well-meaning people who don't understand how this works and thus that the products can't actually do what they appear to offer to do.
Except before DoH I could monitor DNS: with plain DNS ("Do53") it is completely visible, and with DoT it is on a different port so it can be filtered.
Which is Paul Vixie's point: DoH takes control away from network owners, like me and my home Asus, and me and work.
Regardless of what the OS or Firefox or whatever existing app uses, a malicious binary could just use DoH, or just make an HTTP request directly to an IP, or skip HTTP/DNS entirely and fling data out over UDP to an external IP.
Put another way: if your issue is that DoH removes your ability to catch DNS requests from malware, your issue isn't with users enabling DoH, or with app devs defaulting their apps to DoH, your issue is with the concept of non-DNS network protocols. Even if DoH was never standardized, an attacker isn't required to make lookups on port 53 as you desire.
Would you please elaborate on your distrust of Cloudflare? I’m not looking to call you out. Quite the opposite, I appreciate your candor. I just feel like I’m missing some context.
One's ISP could be a mobile telco: I could trust the telco more that I trust the security of GSM/3G/LTE.
Also: does my ISP use Huawei equipment? I could trust my ISP's servers more than their network gear. :) Ask the IT folks at the Africa Union HQ:
* https://en.wikipedia.org/wiki/AU_Conference_Center_and_Offic...
If we are concerned with kill switches, the end-to-end design is less fragile to malicious and legal attacks than a proxy scheme with a handful of operators.
With DoT there is little reasons to not apply the same technology to authoritative resolvers. Conceptually it is almost as simple as supporting both UDP and TCP, and with the low number of root authoritative servers you can even store locally the address and certificates as part of the operating system. Since a lot of TLDs already have signed roots for DNSSEC it is even a pretty simple move forward to imagine a TLS support being enabled by them and the root. I would be amiss to not mention that Bind already store address and root zone keys of root servers as part of the install package.
A bit of a tell is that there is an RFC for authoritative servers running DoT. It is called aDoT. There is no RFC for DoH, and no one is talking about aDoH. Authoritative servers running DoH is not on the map, but aDoT is. Again we can disagree on the terminology but this is the reason why I see DoH as primary a security tool for proxying DNS request while DoT can be used for end-to-end.
Have a look at https://datatracker.ietf.org/wg/dprive/documents/
None of the authoritative DoT drafts have even been adopted by a working group yet, so based on the usual IETF timescales means they are probably years away from an RFC.
There are still substantial problems to be worked out wrt working out if an auth server supports DoT without slowing things down horribly, and working out how to authenticate a server without getting mired in EPP and the ICANN/registry/registrar policy swamp. The threat model needs to be clarified: do we need to protect against active attacks (much more difficult and stronger authentication required) or just passive snooping (which allows opportunistic upgrade). Does TOFU make sense?
So many questions still to be resolved, as it were
The idea that communication between resolver and authoritative servers should be encrypted is not a new concept. People have been discussing and talking about it for, I would like to say decades. What it does not have is an opportunity for data collection and there is not multiple companies competing to become the central location for dns query data. There is no default setting which a company might pay a significant sum for. Like DNSSEC there is also very little to be gained by authoritative DNS server providers in return for any added complexity. Since I work in this industry I can with fair confidence say that for most registrars the added risk and complexity is the primary reason why security technology in the DNS space is not moving like it does in other areas.
It used to be the same thing for email servers but googles attitude more or less changed that. If you do not support TLS then google is more likely to mark your email as spam. The cost of installing TLS is significant smaller than the cost of users email getting flagged as spam, so within a very short time window most email providers suddenly started to support TLS. Getting people to care about security is often a simple matter between risk and cost, a fact often brought up by Bruce Schneier.
> Does TOFU make sense
There is many potential schemes but one of the more simpler one would be to use DNSSEC and hardcode the certificates of the root servers (Authoritive server programs already hardcode some information about root servers as they rarely change). About 1398 of 1527 TLDs have signed zone in dnssec and it would cover most lookup. In theory there is nothing to prevent the root server from simply publishing TLS keys next to the NS records, with registries doing the same. Looking at how communication between email servers became TLS protected, they did not resolve all those questions and yet we went from all plaintext to almost all encrypted in a few years.
As side note, let me give one example of a business concept. When you buy a domain there is usually a way to get analytics of how the domain get queried. Information like how often and from where which helps the domain owner get a perspective of how their domain get used. Let now say 80% of the traffic get routed through cloudflare. 80% of the logs are now gone. That is sad but you can buy it back If you move your DNS to cloudflare which will happy provide analytic for your domain. All Pro, Business and Enterprise plan customers will even get additional geographical information.
There is nothing inherent of the DoT protocol that forces a model of client->recursive->authoritative. The RFC is pretty light on even mentioning recursive. It mention a technical aspect of recursive client in exactly one place, which is when discussing connection reuse for multiple requests by saying it should (not must) reuse TCP connection if possible. The RFC really just boils down to the concept of applying TLS to a tcp and udp based protocol.
The DoH RFC 8484 is very different and as mentioned above there is no one who is suggesting to apply it in any form beyond as a technology between stub resolver and a recursive server.
The dns-privacy IETF is quite relevant in context. If we want to be technically correct here, there is a draft RFC for authoritative servers running DoT called aDoT, with DANE as authentication.
Lets imagine a DoH protocol for email where Google or Microsoft suggest that email client should ignore smtp setting and send all email to them by default, and compare that to current model that we use today where client talk securely to servers and server talk security between each other. When viewed like that, is it unfair to describe DoH as being a proxy and the model of just adding TLS as being end-to-end?