[sumtechguy]

It is an interesting tricky problem. As the DNS system was designed for caching and an 'honor system'. How do you allow caching so you do not completely overwhelm the root servers yet still prevent modification/interception of the contents of the messages? DoH sort of addresses it. But then you still have to trust that the message has not been altered/intercepted at the DoH server. Yet we also want the server to be able to do a replay of that message to another client. Also how to retrofit all of the existing code that uses DNS that uses this magic system. It is like we need a lightweight one way TLS session but with certificate caching and a second request/response type with a hash. But you have to watch out for cert forging then.

That the browsers are reacting in this way says we have a failure at the DNS software level. Those projects do seem to be giving the security that is wanted. So we are starting to get some fragmentation. Which can not be good. Perhaps we need new record types to support this?

[mschuster91]

> Perhaps we need new record types to support this?

The solution would have been DNSSEC, the problem is that authenticating NXDOMAIN responses comes with a ton of challenges on its own and so there, in the end, was just workarounds and messy hacks [1] that IIRC no one ended up utilizing.

[1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...

[tptacek]

No, it's not! The problem here is end-users being forced to trust their upstream DNS caches. DNSSEC doesn't change that! It's a server-to-server protocol, so the same NXDOMAIN interception problem exists --- the intercepting DNS server just sets the AD bit in the header. You can run DNSSEC directly from an end-system, bypassing caches --- but then, relieving load on the roots (a non-issue, but still) is right out the window.

[sumtechguy]

You are right. My brain decided to forget that existed!

[tptacek]

We are nowhere even in the perceptible range of "completely overwhelming" the root servers.