It's not clear to me why any user of Mozilla would care about DNSSEC (which Mozilla doesn't support anyways). For that matter: while it's obvious why Mozilla users would want to choose which resolver they trust (Cloud Flare, or something else), it's not at all clear why they'd actively want DoT, whose only real "benefit" over DoH is that it can be actively filtered by network providers who don't want users encrypting their DNS queries.
On my network's (both home and work) I definitively want to block, any other DNS than the ones I set up.
It was easy and effective way, to block sites, ads, and make sure that internal sites resolved correctly.
Trying to play whack a mole with DOH servers blacklists, sounds like a loosing game.
Not exactly sure what solution there will be. Because in combination with ESNI, you will essentially have to block whole cloud flare, if you just want to block a single site.
And since a lot of ad networks use cloud flare ...
This gives more power to individual clients (both good ones like firefox, and chrome and bad ones like malware, trackers, other crap), but takes away power from centrally managing your own network.
I definitively see reasons on both sides, why this is good or bad.
> It's not clear to me why any user of Mozilla would care about DNSSEC (which Mozilla doesn't support anyways).
So you talk to Cloudflare via DoH: how do you know that CF isn't manipulating the results? (Perhaps by government coercion.)
> ... it's not at all clear why they'd actively want DoT, whose only real "benefit" over DoH is that it can be actively filtered by network providers who don't want users encrypting their DNS queries.
Mozilla may want to support it because it could prevent them from being banned from corporate environments that may need to monitor queries for regulatory reasons. It doesn't have to be the default, but being able to enable it via a GPO could be useful.
First, almost nobody signs their zones. DNSSEC has practically no meaningful adoption (lots of tiny zones in Europe are signed because their registrars do it automatically, but break zones down by usage and you'll see a very different story). But, more importantly, DNSSEC is a server-server protocol; it doesn't protect end-systems at all. If you're using any external resolver, the "SEC" part of DNSSEC is a single bit in the header saying "some other resolver checked signatures". You'd have to trust Cloud Flare either way.
More importantly, 91% of TLDs are signed. See http://stats.research.icann.org/dns/tld_report/ Because only the most esoteric of domains lack DNSSEC at the TLD level, this means you can prevent your domain from being hijacked for anyone who cares by simply signing your own zone. Who would care to validate DNSSEC at 25% deployment? Providers of ridiculously centralized DoT and DoH DNS proxies, like Google and Cloudflare.
> But, more importantly, DNSSEC is a server-server protocol; it doesn't protect end-systems at all.
It's trivial for systems to run their own recursive DNS service locally, while also making use of intermediate caching nameservers. systemd supports this, for example, and OpenBSD almost shipped with a local resolver service that enforced DNSSEC by default (some last minute hiccups caused them to disable it before release).
Chrome and Mozilla are shipping entire bespoke client DNS transports. Adding recursive resolution support with DNSSEC verification to their in-browser resolver is trivial by comparison. I've written a recursive DNS stub resolver, so know first hand. In fact, CNAME chaining requires client stub resolvers to already support recursive lookup logic as intermediate recursive, caching resolvers don't always include CNAME chains in their responses, especially for out-of-bailiwick chains or when chains can't be resolved from the local cache. Going from CNAME recursion to recursion on authorities is trivial. Likewise, DNSSEC verification is trivial compared to the nightmare that is TLS and X.509 certificate parsing and constraint checking.
Those numbers are based on random zones nobody cares about largely being auto-signed by registrars, which is security theater. Instead, look at popular/major sites, and count how many of them are signed. Look at sites run by actual security teams and note that virtually none of them except for Cloud Flare, which sells DNSSEC services, sign their zones.
Obviously people can stop using DNS servers altogether and run recursive resolvers (and, of course, expose all their queries to their ISP, which is precisely the problem DoH is trying to solve). And, as you know, effectively nobody does this. Obviously, browsers can add support for DNSSEC. But they've done the opposite thing: they've piloted it --- at Apple, at Mozilla, and at Google --- and then later withdrew support.
DNSSEC is a dead letter. It has no operational relevance today; the root keys could be Pastebinned and no site on the Internet would be compromised. And after 25 years of pointless effort, no meaningful adoption has occurred; rather, it has been un-adopted from the few places that tried.
> auto-signed by registrars, which is security theater
Do you consider Let's Encrypt security theater?
> And after 25 years of pointless effort, no meaningful adoption has occurred; rather, it has been un-adopted from the few places that tried.
For a long time the zone enumeration "problem" plagued DNSSEC. Everybody thought it was a fatal flaw, and it even led to a redesign that added complexity in an attempt to mitigate it. This made DNSSEC seem unnecessarily costly, a potential insecurity, and substantially hurt deployment.
Fast forward two decades and best practice is to put all your corporate resources on the public network, hosted by third parties. The refrain from those advocating for Google and Cloudflare DoH proxies is that organizations should be moving away from hidden domains. Well, if you don't have hidden internal networks and don't care about leaking your subdomains, then DNSSEC is simple and easy to deploy when self-hosting DNS, and a trivial upgrade to DNS hosting providers.
I get that you're a long-term opponent of DNSSEC. Well, I'm a weak opponent of QUIC, especially QUIC outside the kernel. That doesn't mean I don't appreciate and recognize the benefits, or actively try to oppose it. I try not to be inconsistent.
If you think Let's Encrypt is great, and you advocate for centralized DoH, then the major objections to DNSSEC cannot be sustained. That's different than affirmatively advocating for DNSSEC, but I just don't get the fierce opposition. To say that DNSSEC is, on balance, worse for the Internet (e.g. security theater) seems preposterous to me.
As you'll see, I have multiple reasons to believe DNSSEC is a powerful net negative for the Internet. The simplest one to communicate is that unlike LetsEncrypt, whose nuts-and-bolts security DNSSEC does not improve on, DNSSEC also escrows out authority to world governments. But there are other arguments that are actually more meaningful to me, such as the clunky, 1990s design of its cryptography and the near-certainty that its installed base will be RSA-dependent for the protocol's entire lifespan, be it 1 year or 20.
That piece goes into a lot more detail that I won't belabor here.
My point on this thread though is simple and factual and descriptive: an ordinary user of the Internet --- in fact, even an ordinary software developer on HN --- can expect to interact with the Internet at length without ever once coming into contact with a website on a DNSSEC-signed zone. You see DNSSEC brought up on these threads as if it was an important operational security concern for people setting up Pi-Holes and whatnot, and you know as well as I do that's simply false. You probably assume at first blush that I'm snarking when I say the DNSSEC root keys could be Pastebinned to no real ill-effect, but if you think about it for a few minutes I think you'll find that I'm not snarking at all. You want DNSSEC to work, and you're right, I don't, but neither of us can kid each other about the fact that it's not working now.
Still, as someone who works in IT, I'm happy to implement DoT/DoH internally--just don't go around overriding the settings I want my desktops to use. We're already noticing breakage in our testing due to split-horizon DNS and hairpin NAT.
Is there a stub resolver you're aware of that is in mainstream use anywhere that sets CD and does its own validation? My belief is that the answer is "no", but you might know better.
