Hacker News Reader

Comment by PreInternet01 | Hacker News Reader

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"...

View on HN

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.

NSEC3 pretty much solves this issue.

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.

> 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).

I don’t believe this is true. CT is wholly encompassing by design: if you could somehow opt out, an attacker could use that mechanism to bypass CT.

(As far as I know, the only way to “opt out” is to use a wildcard to obscure the true subdomain being accessed.)

Edit: from a quick look online, CT became mandatory for CA issued certificates in the Web PKI in 2018.

Hum, DNSSEC is highly useful tho

Both DNSSEC and DoT/DoH prevent hijack between the customer and the resolver

However, only DNSSEC prevents hijacks between the resolver and the authoritative servers

DNSSEC is the only way to trust a zone's content

Or maybe DoT/DoH shall be the only way to resolve things, and the DNS over UDP/TCP shall be deleted from the surface of the earth ?

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:

https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/

> DNSSEC is highly useful tho

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...

> Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless.

Depends on where you live. Last time I checked, about 70% of the top 25k .nl domains were signed. .ch and .se also have a lot of DNSSEC domains.

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.

He just explained why it doesn't provide the tamper detection you think it does.

People in the Netherlands still use Google, Facebook, YouTube etc and other international servers that are not signed.

95% is a much closer number.

Does that matter ?

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.

> 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.

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.

This is not true

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.

Here is an example of how that exact mark as insecure logic is used to downgrade/strip: https://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-...

This is another example, using IP fragmentation: https://www.athene-center.de/forschung/publikationen/poster-...

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.

You do not think an attack shall be prevented, for the user's best interest ?

We shall just let the man-in-the-middle go on, transparently ?

I do not agree with you.

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.

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.

Reply on news.ycombinator.com