5 ms·

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 D

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?

tptacek 7mo ago
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 7mo ago
  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 7mo ago
    Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
    - ekr____ 7mo ago
      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 7mo ago
        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 7mo ago
    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?
    - thenewnewguy 7mo ago
      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 7mo ago
        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
        tptacek 7mo ago
        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.
        indolering 7mo ago
        Which is really unfortunate, since it's pretty easy to do.
        tptacek 7mo ago
        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.
        7mo ago
- mindslight 7mo ago
  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 7mo ago
It will change as soon as one of them gets meaningfully DNS hijacked.
- tptacek 7mo ago
  Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
  - indolering 7mo ago
    Phishing existing isn't a good argument against cryptographically authenticating DNS records.
    - tptacek 7mo ago
      "Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.
      - indolering 7mo ago
        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 7mo ago
        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.
toast0 7mo ago
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 7mo ago
  [flagged]
  - tptacek 7mo ago
    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.
    - 7mo 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?

tptacek 7mo ago

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 7mo ago
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 7mo ago
  Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
  - ekr____ 7mo ago
    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 7mo ago
      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 7mo ago
  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?
  - thenewnewguy 7mo ago
    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 7mo ago
      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
      - tptacek 7mo ago
        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.
        indolering 7mo ago
        Which is really unfortunate, since it's pretty easy to do.
        tptacek 7mo ago
        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.
        7mo ago
mindslight 7mo ago
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 7mo ago

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

tptacek 7mo ago
Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
- indolering 7mo ago
  Phishing existing isn't a good argument against cryptographically authenticating DNS records.
  - tptacek 7mo ago
    "Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.
    - indolering 7mo ago
      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 7mo ago
        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.

toast0 7mo ago

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 7mo ago
[flagged]
- tptacek 7mo ago
  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.
  - 7mo ago