Comment by SahAssar
5 hours ago
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?
5 hours ago
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?
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)
Port randomization helps against blind spoofing, but once an attacker is on-path or owns a resolver, it stops mattering.
If an attacker owns a resolver DNSSEC stops mattering too; from the resolver to the stub-resolver, the protocol collapses down to a single "yes we did DNSSEC" bit in the header.
The bigger thing here is DoH, which has very real penetration, and works for zones that don't do anything to opt-in. That's what a good design looks like: it just works without uninvolved people having to do extra stuff.
I think DNSSEC supporters, what few of them are left, are really deep into cope about what transport security is doing to the the rationale for DNSSEC deployment. There's nothing about DoH that makes it complicated to speak it to an authority server. The only reason I can see that we're not going to get that is that multi-perspective kills the value proposition of even doing that much.
4 replies →
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.
1 reply →
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?
8 replies →
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.