Hacker News Reader

Comment by SahAssar | Hacker News Reader

What's your replacement if DNSSEC is moribund?

It seems to me like it actually solves a problem, what is the solution to "I want/need to be able to trust the DNS answer" without DNSSEC?

View on HN

Largely, DNS integrity has been addressed by making it harder to spoof dns responses without visibility.

Resolvers have put in the effort to use most of the range of source ports and all of the range of request ids, as well as mixed caps, so predicting queries is difficult and blind spoofing requires an unreasonable number of packets.

Additionally, commercial DNS services tend to be well connected anycast. This means most queries can be served with a very low round trip time; reducing the spoofing window. Additionally, there's less opportunity to observe requests as they traverse fewer networks and less distance.

Generally, traffic has moved to certificate authenticated protocols. CAs are required to verify domain control from multiple locations, so an attacker asserting domain control would need to do so for the victim as well as multiple other locations in order to get a certificate issued.

Further; if we assume you plan to assert domain control by taking over or MITMing the IP of a DNS server, it seems likely you could do the same for the IP of an application server. DNSSEC doesn't help very much in that case. (DNSSEC with DANE could help in that case, but to a first approximation, nothing supports that, and there doesn't appear to be any movement towards it)

It seems pretty clear to me that the industry, and particularly the slice of the industry that operates large, important sites and staffs big security teams, doesn't believe this is a meaningful problem at all.

I agree with them.

Would this article not be evidence the part of the industry that makes up the CA/B Forum (i.e. CAs and Browsers) disagree?

Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.

Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.

They do have uniform policies, those policies come from the aforementioned CA/Browser Forum, which has been issuing its Baseline Requirements for over a decade.

The fact that it's 2026 and the CAs are only now getting around to requiring any CA to take DNSSEC, which has in its current form been operational for well over a decade, makes you take DNSSEC more seriously?

Why dodge the question? Clearly they care today, and I live in today.

If we're doing to defer to industry, does only the opinion of website operators matter, or do browsers and CAs matter too? Browsers and CAs tend to be pretty important and staff big security teams too.

Are they requiring DNSSEC in order to acquire the certificate? That would be a better indicator to me that it's not security theater=security

No CA requires DNSSEC. Obviously they can't: almost nothing is signed. The only change "today" is that technically CAs are now required to honor DNSSEC, where they weren't before.

Which is really unfortunate, since it's pretty easy to do.

I agree that it's relatively easy for CAs to validate DNSSEC. I think the fact that they weren't technically required to, despite the sole remaining use case for DNSSEC being to protect against misissuance, is a pretty strong indicator of how cooked DNSSEC is.

I think the fact they don't require it shows it's moribund. If cert providers (or google with their big stick of chrome) specified it is required to have DNSSEC to get a certificate, everyone would jump in line and set it up because there'd be no other choice.

I agree that not checking it all is an even worse signal. I'm just saying the fact that this is officially enforced only in 2026 is itself a bad signal. At any rate, the CAs you'd have worked with were enforcing DNSSEC this whole time.

Barely 5% of the internet have DNSSEC signed zones and a big chunk of that are handled by CDN's that do the signing automagically for the domain owner as they also host SOA DNS. Mandating DNSSEC would require years of planning and warning those that have not yet set it up and in my opinion DNSSEC tooling should become a better first class citizen in all of the authoritative DNS daemons. as in there should be so many levels of error handling and validation that it would be next to impossible for anyone to break their zones.

So do we wait for all the stragglers? Wait for the top 500 or top 2500 to make it mandatory? Who takes financial responsibility for those that fell through the cracks?

LetsEncrypt has been checking for DNSSEC since they launched 10+ years ago.

       The ACME standard recommends ACME-based CAs use DNSSEC for validation, section 11.2 [1]:
       An ACME-based CA will often need to make DNS queries, e.g., to
       validate control of DNS names.  Because the security of such
       validations ultimately depends on the authenticity of DNS data, every
       possible precaution should be taken to secure DNS queries done by the
       CA.  Therefore, it is RECOMMENDED that ACME-based CAs make all DNS
       queries via DNSSEC-validating stub or recursive resolvers.  This
       provides additional protection to domains that choose to make use of
       DNSSEC.

       An ACME-based CA must only use a resolver if it trusts the resolver
       and every component of the network route by which it is accessed.
       Therefore, it is RECOMMENDED that ACME-based CAs operate their own
       DNSSEC-validating resolvers within their trusted network and use
       these resolvers both for CAA record lookups and all record lookups in
       furtherance of a challenge scheme (A, AAAA, TXT, etc.).

[1]: https://datatracker.ietf.org/doc/html/rfc8555/#section-11.2

Yes, that's my understanding as well. You'll notice my top-level comment from a few hours ago says that as well.

(You edited your comment to include more detail about when LE started validating DNSSEC; all I know is that it's been many years that they've been doing it.)

Big sites don't have the same concerns as individual end users, in this case specifically about centralized servers surveilling DNS queries.

DNSSEC zone signing lets one resolve records without having to directly go through trusted (ie centralizing) nameservers. (If you run your own recursive resolver this just changes the set of trusted servers to the zones' servers).

I've made this argument in the context of your poo-pooing DNSSEC before, and I don't expect you to be receptive to it this time. Rather I just really wish I could get around to writing code to demonstrate what I mean.

It will change as soon as one of them gets meaningfully DNS hijacked.

Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.

Phishing existing isn't a good argument against cryptographically authenticating DNS records.

"Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.

But it also applies to every other part of the stack, including WebPKI. Would you accept this as a valid argument against using HTTPS everywhere?

I can't even follow your argument anymore. DNSSEC is proposed as a feature to make DCV certificates more difficult to misissue. But DCV misisuance is overwhelmingly caused by registrar ATO. DNSSEC therefore can't address most DCV misissuance. And it has no other mainstream security proposition.

That is obviously not a claim you can make of the WebPKI. Your problem here is that the WebPKI is a very large superset of the security capabilities of DNSSEC. Unlike with DNSSEC, people --- millions of them --- actually rely on it.

I'll rephrase the argument to make it more clear for you: Phishing attacks are far more common than HTTP MITM, so we don't need protection against HTTP MITM. If you think this conclusion doesn't follow from this premise, then what differentiates HTTP from DNS in your mind, because you are making this argument about DNS?

Neither DNSSEC nor the WebPKI are defenses against phishing. But phishing (registrar ATO more generally) is the dominant vector through which DNS spoofing occurs, and DNSSEC solely addresses DNSSEC spoofing.

Do you agree that we don't need HTTPS because phishing is the most common HTTP attack, not MITM?

No? This is the third attempt you've made at this faulty syllogism. If we simply can't resolve enough premises to hash it out, that's fine, we don't have to try to understand each other.

Reply on news.ycombinator.com