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?

▲ toast0 6 hours ago | parent | next [-]

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)

▲ hrmtst93837 6 hours ago | parent [-]

Port randomization helps against blind spoofing, but once an attacker is on-path or owns a resolver, it stops mattering.

▲ tptacek 6 hours ago | parent [-]

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.

▲ amluto 5 hours ago | parent | next [-]

> There's nothing about DoH that makes it complicated to speak it to an authority server.

There’s a problem with HTTPS, though. HTTPS uses URLs that use WebPKI to tie the URL to the certificate validation algorithm. Which means you need WebPKI certificates, which needs DNS. Chicken, meet egg.

Maybe there could be a new URL scheme that doesn’t need WebPKI. It could be spelled like:

    https_explicit:[key material]//host.name/path

or maybe something slightly crazy and even somewhat backwards compatible if the CA/browser people wouldn’t blow a fuse:

    https://1.2.3.4.ipv4.[key material].explicit_key.net

explicit_key.net would be some appropriate reserved domain, and some neutral party (ICANN?) could actually register it, expose the appropriate A records and, using a trusted and name-constrained intermediate CA, issue actual certificates that allow existing browsers to validate the key material in the domain name.

▲

tptacek 5 hours ago | parent [-]

I think stuff like this is more than promising; I think it's likely to happen relatively soon.

▲

amluto an hour ago | parent [-]

Got any links?

	▲	tptacek an hour ago \| parent [-]
		I wish I did, but right now it's all conversations with CA and browser people.

▲ indolering 4 hours ago | parent | prev [-]

Which is a problem with the OS and browser, not with DNSSEC.

	▲	tptacek 4 hours ago \| parent [-]
		Eric Rescorla's post, linked upthread, goes into detail about why "OS's and browsers" can't easily solve this problem without breaking the Internet for materially large fractions of their users. In practice, browsers that care about DNS security just use DoH.

▲ tptacek 9 hours ago | parent | prev | next [-]

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.

▲ thenewnewguy 9 hours ago | parent | next [-]

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

▲ throwway120385 9 hours ago | parent | next [-]

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

▲

ekr____ 6 hours ago | parent [-]

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.

	▲	kbolino 2 hours ago \| parent [-]
		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.

▲ tptacek 8 hours ago | parent | prev [-]

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?

▲ alwillis 3 hours ago | parent | next [-]

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

	▲	tptacek 2 hours ago \| parent [-]
		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.)

▲ thenewnewguy 8 hours ago | parent | prev [-]

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.

▲

rstupek 8 hours ago | parent [-]

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

▲

Bender 8 hours ago | parent | next [-]

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?

▲

tptacek 8 hours ago | parent | prev [-]

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.

▲

rstupek 7 hours ago | parent | next [-]

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.

	▲	tptacek 7 hours ago \| parent [-]
		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.

▲

indolering 8 hours ago | parent | prev [-]

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

	▲	tptacek 8 hours ago \| parent [-]
		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.

▲ mindslight 6 hours ago | parent | prev [-]

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.

▲ gzread 9 hours ago | parent | prev [-]

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

▲

tptacek 6 hours ago | parent [-]

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

▲

indolering 3 hours ago | parent [-]

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

▲

tptacek 3 hours ago | parent [-]

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

▲

indolering 2 hours ago | parent [-]

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?

▲

tptacek 2 hours ago | parent [-]

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.

▲

gzread an hour ago | parent [-]

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?

	▲	tptacek 35 minutes ago \| parent [-]
		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.