As I wrote above: DNSSEC can't do anything about unsigned zones, and the overwhelming majority of zones in both the North American Internet and in popular domain lists like the Moz 500 are unsigned, and will remain unsigned, despite almost a decade of pleading from DNSSEC advocates to recant.

What's crazy about this is that there's a trivial solution to forged NXDOMAIN responses that people can adopt immediately: just DoH to a provider that doesn't forge NXDOMAIN responses (none of the major providers do).

I sometimes wonder whether the vehemence of the anti-DoH advocacy is rooted in concern that it will cause DNSSEC to lose yet another potential motivating use case.

I've never looked at DOH as an attack on DNSSEC, though I suppose you could. I think the resistance is more about the big corporate and the Internet level DNS operators like Google's 8.8.8.8, they want to be able to manipulate DNS responses when necessary. I know, evil corporate IT Ops hijacking my HNN connection. No, not that.

Think about a coordinated effort by top tier DNS providers globally to stop a giant bot network by simultaneously 'hijacking' DNS responses for the command and control server host-names. In classic DNS this is easy, just intercept the requests at the LDNS provider and return a dummy server IP, all good.

That falls apart with DOH and DNSSEC. With DNSSEC you cannot forge a response to a client that strictly expects signed responses for a particular zone. And with DOH, the various corporate IT shops cannot inspect and 'hijack' the responses. Though, the DOH operator can still change the response. But that moves the capability outside of local corporate IT and into a multinational company that might not agree with your request to 'fix' a problem via assisted DNS hijacking.

So all of these new, safer DNS delivery methods do legitimately impact the ability of "good"* operators to protect the Internet. Is the trade off worth it to protect users DNS traffic versus being able to respond to threats? I think that protecting users daily traffic is net-net better as it is a steady state problem and state sponsored actors have the resources to subvert a population via DNS. But I also feel the loss of a tool to protect users at the same time. Things like this are never zero-sum.

Disclaimer: I work for Microsoft and although I don't operate DNS services as part of my job, I have spent a lot of time on this particular topic over the years. These are my opinions, not the companies. I welcome challenges to my opinions, that's how I learn.

*"good" is always a situational thing.

Losing the ability to do this very specific mitigation seems a tiny price to pay for not having everybody's DNS requests have zilch for transit privacy and integrity all the time.

DNSSEC allows a recursive DNS server to absorb these Google Chrome junk queries: the resolver can use a secure proof of nonexistence to answer the junk query from cache. Much more efficient, and works to absorb junk traffic in any domain signed with NSEC, not just the root. https://tools.ietf.org/html/rfc8198 https://www.potaroo.net/ispcol/2019-04/root.html

> hijacks requests to valid top level domains

I believe the purpose of this feature is not about detecting hijack requests to valid top level domains. In other words, a well written NXDOMAIN interceptor would not cause a harm to their intended audience, so they didn't bother trying to detect it.

It's about detecting that a "eng-wiki A aa.bb.cc.dd" record it just received from the user's DNS server is actually intended to be eng-wiki served from corp network instead of a stupid ISP page.

This comment, and another one mentioning DNSSEC has been downvoted.

Please explain why you hate DNSSEC instead of downvoting things you disagree with.

Browser vendors seem to have shelved all work on DNSSEC for reasons they haven't publically stated. It had such promises to be able to reduce trust in CA's by pinning HTTPS certificates to DNS responses, so was exactly what browsers would have wanted, yet still all work stopped around 2015 or so.

To me, it's as if DNSSEC has some critical and unfixable security vulnerability, and people who make these decisions decided to stop all work on it, but not reveal the vulnerability because doing so would do too much damage.

This is probably the most comprehensive list of reasons not to use it: https://www.imperialviolet.org/2015/01/17/notdane.html

This is not what DNSSEC does. DNSSEC is about signing DNS records to prevent spoofing of records.

DNSSEC has not seen widespread adoption because of complexity in implementing and maintaining DNSSEC and concern over weaknesses in the encryption chosen. The protocol has been around a long time now and the encryption involved is not modern. Some DNS providers are making DNSSEC easier by handling keysigning and rotation with no user involvement. Just check the box that you want it activated.

DANE is the storage and retrieval of certificates via DNS. DANE depends upon DNSSEC to sign the certificate records to determine that haven't been spoofed.

There is no great conspiracy theory needed regarding why DANE has not been implemented in browsers. The browser makers have been pretty open about why they have chosen not to support it. For example code has been written for Chrome but Google has said they haven't shipped it because they don't want to support the 1024-bit RSA required as part of the DNSSEC standard.

I don't understand why browser vendors should be involved

My browser should ask my OS to resolve DNS

It's my OS's responsibility to do that - maybe sending a request to a remote server, maybe running it's own resolved, maybe using DoT, DoH, DNSSec or not

What business should it be of browser vendors?

This weird idea of the delineation of responsibilities between the OS and applications has never actually been how things worked. For a very long time, the OS resolver libraries couldn't even reliably do asynchronous resolution, and applications like your browser provided their own. I think the notion that the OS "owns" DNS comes from the fact that people used to get their DNS servers from DHCP, and the OS's libraries automatically knew what servers DHCP had been configured. It's not like some kind of law of system design.

The OS resolves DNS names to IP addresses... Except an IP address isn't a security identifier of any kind, so there is no benefit to it not being spoofed.

The relation to browser vendors is that DNSSEC allows DNS to verify/validate certificates for TLS connections, which can be used by web browsers (and other applications, but web browsers would be the main users).

Shouldn't it be up to my OS to do that validation though, not the browser? After all when I ssh to my.server.com I want the same guarentee as when I https to it.

That’s not how SSH or HTTP work.

If you ssh to a server your OS will resolve the IP, but your SSH client will request and attempt to verify the server key. Same with browsers and HTTP.

No, browsers won't do anything of the sort with HTTP. Or ftp. Or SMTP.

HTTPS sure. SMTP when they start a TLS session sure, FTPs too, there's protections at a higher level to ensure MITM isn't working, and you could probably argue that's a reason that DNSSec isn't required at all - after all get the wrong IP and your secure application won't do anything past the initial handshake. That's still leaking information though.

DNSSec, if used, is something that should sit in my DNS resolver, which should be part of my OS, not in my browser or ssh client - after all I might not want to use DNS, I might want to use a different protocol for resolving address lookups.

In an alternate universe, an application would call connect('google.com', secure=true), and the OS would make an encrypted connection and verify that the person on the other end of the connection really was google.com using dnssec published keys.

While that might have been a better design, the reality is OS's only provide API's for unencrypted connections and each application builds their own encryption and authentication on top of that.

> In an alternate universe, an application would call connect('google.com', secure=true), and the OS would make an encrypted connection

IBM's mainframe operating system z/OS (formerly known as MVS) has a feature called AT-TLS (Application Transparent TLS).

With AT-TLS, you can configure operating system policies to intercept TCP socket calls from an application, and automatically add TLS to the sockets. That way, some legacy app, which knows nothing about TLS, can have TLS support added to it, without any modifications required.

There is an IOCTL that can be called on the sockets, which can find out whether AT-TLS is enabled, what certificate is being used, etc. So applications can easily be enhanced to detect whether AT-TLS is enabled on a connection and respond differently.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/...

In reality my browser says "connect to www.google.com on port 80", the the library eventually calling like getaddrinfo to translate the domain name to an IP address.

My OS resolves www.google.com to 123.45.67.8. It's the OS's responsibility to resolve the DNS, not the browser.

That blog post is five years old, and most of the things it lists are now moot.

True, but dnssec is still going nowhere...

The future seems to be HTTPS with domain-validated certificates over insecure DNS, or even dnssec but doing the http challenge over an insecure network.

Great for state actors to inject malware into any site...