At this point, someone should just file a high severity / high impact CVE against DNSSEC in its entirety, and ensure the box-tickers all across the world mandate its eradication.
While I'm sure (even stronger: I know) that at some point DNSSEC was a good idea, it's just a liability-slash-infrastructure-tax these days (a footgun at best, an additional DoS vector in most cases), and it's time for it to go.
99% of DNSSEC deployments come down to "I trust the entity I have outsourced my DNS management to with my private key management as well", which makes no sense whatsoever, and the reasoning behind the remaining 1% doesn't inspire much confidence either.
DoH satisfies the DNS privacy/security requirements of most Internet users just fine, and with or without DNSSEC, the management of the underlying infrastructure remains the same as it was before, i.e. "trust us"...
DNSSEC doesn't have encryption, and does nothing for end-user privacy, so that's not even an alternative to DoH or DNSCurve.
The only thing it deems a potential privacy issue is possibility of enumeration of subdomains, which is security by obscurity for the domain owner, from a time before certificate transparency logs ruined that anyway.
> from a time before certificate transparency logs ruined that anyway.
Isn't it possible under WebPKI rules to get an intermediate cert for all of your subdomains so that only the intermediate cert needs to get logged in certificate transparency? Or at the very least, you could use a wildcard underneath the domain you own...
I don’t think CAB would prevent that kind of intermediate, but I don’t know of any CA that issues them. The domain set would need to be enforced with name constraints, which are notoriously buggy in a lot of validators.
But yes, a wildcard accomplishes the same thing, and I think that’s the route (almost?) everyone goes if a service’s subdomains really need to be kept out of a transparency log.
I was under the impression you could flag your domain to not be in cert transparency logs. Security through obscurity is generally considered a bad idea (to which I think exceptions or nuance exist), but the likelihood of dns names being burnt via other mechanisms (isps/‘security’ products and platforms logging dns requests and selling them being a reasonable assumption).
It doesn't, at all. NSEC3 is crackable like a 1990s password file, and several tools exist to do it. The "standard" solution to this is "whitelies" (RFC4470), which requires your DNSSEC server to be an online signer so it can generate chaff records; the supposedly upcoming solution is NSEC5, which fixes the broken cryptography in NSEC3.
It's important to understand why one might care about trusting the zone's content.
From the perspective of something like a browser, the mapping from the domain name to the IP address (i.e., the A or AAAA records) need not be secured via DNS because the connection to the server is secured via TLS and the WebPKI. So DNSSEC isn't helping here, especially because the clients don't check DNSSEC, so it doesn't protect them from attack on the local network, which is one of the main loci. If the DNS server provides the wrong IP, this is mostly a DoS attack.
I am aware that the situation is somewhat different in email but I'm not sure how different really. Note that it is the case that DNSSEC could help secure ACME validation queries, but as tpacek observes, CT has greatly reduced the risk of misissuance.
Of course there are other mappings in the DNS, but as a general matter those are being designed under the assumption that the DNS is untrustworthy, due to the low level of DNSSEC deployment. For instance, if you look at the HTTPS RR, it's fine to put a key for Encrypted Client Hello in it because the resolver already knows the desired domain name, so lying about the key doesn't really help. However, we can't safely publish the server's public key to be used for TLS 1.3 early data ("Zero RTT priming") because that would require trusting the DNS. So, any features which require the DNS to be secure have the usual chicken-and-egg deployment problems (this is also to a great extent what happened with DANE).
Taking the opportunity to reference myself, the following longer writeups might be useful on this topic:
> However, only DNSSEC prevents hijacks between the resolver and the authoritative servers
It does no such thing. An attacker on the resolver or between the resolver and authoritative is able to strip DNSSEC.
DNSCrypt was the solution to all the problems we had, but at the time DNS software vendors and operators also had a financial interest in passive monitoring so DNSSEC being clear on the wire won.
A recursive will drop unsigned responses from root servers. So that if a zone should be signed, then all unsigned answers are boggus and dropped.
On unbound, for instance:
harden-dnssec-stripped: <yes or no>
Require DNSSEC data for trust-anchored zones, if such data is
absent, the zone becomes bogus. If turned off, and no DNSSEC
data is received (or the DNSKEY data fails to validate), then
the zone is made insecure, this behaves like there is no trust
anchor. You could turn this off if you are sometimes behind an
intrusive firewall (of some sort) that removes DNSSEC data from
packets, or a zone changes from signed to unsigned to badly
signed often. If turned off you run the risk of a downgrade at-
tack that disables security for a zone. Default is yes.
DNSSEC is also a huge foot-gun in that the end user just sees "the internet is broken." This leads to many recursive operators turning off DNSSEC validation when big zones break and eyeballs complain. Perfect homelab quality configurations are rarely deployed to the real world.
It really is hot garbage and should be taken out behind the woodshed.
No, I think that is very important which is why I fight against DNSSEC.
Have a look at DNSCurve, it solves many of the problems DNSSEC was attempting to address but with proper transport security. We implemented this at OpenDNS back in 2010 so it would opportunistically use it if available.
I don't think that's really true at all, re the incentive story. DNSSEC (or, at least, the classic IETF DNS stack) has a story for encrypted transport; it's just that nobody ever wanted to deploy it.
I don't want to dig up private discussions from a dozen years ago, but the DNS vendors that mattered at the time also had passive DNS/security products that paid the bills.
Not as it's deployed today. Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless.
The 'evil ISP or IT MITMs my DNS traffic' scenario is much more effectively addressed with DoH (since it only requires clients and some resolvers to coordinate, not the entire Internet, and it looks like regular HTTPS, which implementers already understand how to deal with, as a bonus).
And the 'evil government redirects some or all zones' play is still very much possible even with DNSSEC, since, guess who ultimately controls the keys.
Even if you think that making the latter scenario more difficult to implement is worth it, getting more people to sign their zones is a losing battle, since they're very much likely to self-DoS themselves in the process, significantly reducing their enthusiasm...
Unlike IPv6, everybody who deploy dnssec gets the full benefits, regardless of what others are doing : you just need to get a fully-DNSSEC-supported chain from the roots to your zone.
Yes, I'm aware of the .nl situation in particular, and... it only underscores my point?
If those .nl domains dropped off the Internet tomorrow, that (while of course very inconvenient for lots of people) wouldn't cause more than a tiny dip in global traffic. The benchmark here is how much of, say .com and .net combined, is signed. And that's around 4% (4.5M signed zones out of a total 170M, give or take).
Because of a well-intended mandate, most .nl domains are signed by their registrar, which generates and holds the private keys. So: the very same entity responsible for enabling domain delegation also secures that delegation. Virtually nobody generates and supplies their own DNSSEC keys when registering their .nl domain. So, a government looking for someone to lean on to modify a delegation, doesn't need to do that much extra work for such 'secure' zones, do they now?
From a consumer perspective, visiting digid.nl (signed, probably with their own keys, kept in a nice HSM somewhere!) vs. ah.nl (not signed) offers no meaningful extra privacy or security: when not using DoH, their ISP and anyone else in the middle will still have a pretty good idea what they're up to, and can strip off the 'hey, tell me about your signature' bits in any requests, leaving the client unable to tell the difference in the first place in most situations.
In case of a DNS hijack, the consumer security implications are exactly the same for both login (digid.nl) and shopping (ah.nl): their browser or app will refuse to connect, because DNS is already a negligible factor there, and it's the TLS certificate that makes the difference. That, combined with the very real danger that turning on DNSSEC makes a zone unresolvable for hours or even days on end, makes most people a bit wary about doing do. And they're absolutely right.
DNSSEC doesn't provide privacy. It was never designed to. If you want privacy, use ODoH.
What it does offer, is tamper detection. I don't trust Cloudflare enough to always provide me with the right DNS data even if resolving the domain happens over TLS, and that's the part of the chain DNSSEC covers. DNS servers don't use DoH to resolve records, so the MitM risk remains.
In my experience, the practical risks of enabling DNSSEC are minimal. Some broken (often Big Tech) DNS providers have had issues in the past (Amazon, notably) but every major DNS provider I've used has never let me down, and that includes some of the cheapest domain servers on the market.
You may be as wary if you want to be, but .nl proves that the risks of DNSSEC are quite minimal in practice if the TLD registrar is competent.
It sounds good as long we apply it to all outsourcing where security relies on a third-party. End-to-end encryption was never designed with the concept of clouds and anycast providers, including the whole idea of virtual servers. They all depend on "I trust the entity who owns this hardware" which can be any partner which the cloud provider deemed worthy.
While I'm sure (even stronger: I know) that at some point DNSSEC was a good idea, it's just a liability-slash-infrastructure-tax these days (a footgun at best, an additional DoS vector in most cases), and it's time for it to go.
99% of DNSSEC deployments come down to "I trust the entity I have outsourced my DNS management to with my private key management as well", which makes no sense whatsoever, and the reasoning behind the remaining 1% doesn't inspire much confidence either.
DoH satisfies the DNS privacy/security requirements of most Internet users just fine, and with or without DNSSEC, the management of the underlying infrastructure remains the same as it was before, i.e. "trust us"...