7 ms·

I am not an expert in DNS but isnt' DNSSEC sort of like IPV6 when it comes to utility vs adoption vs overhead ? In other words, hasn't really lived up to the ex

I am not an expert in DNS but isnt' DNSSEC sort of like IPV6 when it comes to utility vs adoption vs overhead ? In other words, hasn't really lived up to the expectations or am I missing something ?

tptacek 3y ago
It has massively underperformed expectations in a way that far outstrips any disappointment anyone could have in IPv6. IPv6 has adoption approaching 50%. If you have a modern ISP and a modern router, you might be using IPv6 right now without even noticing it. Meanwhile: less than 5% of the major US TLDs are signed, and an even smaller fraction of the "top domains" (given any list of top domains, like the Moz 500) are. The major prevailing use case for DNSSEC, which is DANE, has no browser support --- browsers actually tried it and removed that support.
- teddyh 3y ago
  My usual alternative viewpoint whenever you try to claim that DNSSEC is dead: From where I sit, I work at a registry and DNS server host (among other things) where about 40% of all our domains have DNSSEC (and that number is constantly climbing). Every conference I go to, and in every webinar, people seemingly always talk about DNSSEC and how usage is increasing. From my perspective, your continuous claim that “nobody uses” DNSSEC is simply false. DNSSEC works, usage of DNSSEC is steadily increasing, and new protocols (like DANE) are starting to make use of DNSSEC for its features. Conversely, I only relatively rarely hear anything about MTA-STS. (Originally written as a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530 https://news.ycombinator.com/item?id=27837530>, but the details given have not changed substantially.)
  - tptacek 3y ago
    Start by convincing Geoff Huston, from who I could shoplift all the rebuttals I'd need to this argument. TLD DNSSEC signing stats are easy for people to look up, and people can quickly see I'm not making any of this up.
    - mjl- 3y ago
      fwiw, i live in a country where rolling out dnssec apparently had some financial incentives for providers, which apparently helped adoption: https://stats.sidnlabs.nl/en/dnssec.html https://stats.sidnlabs.nl/en/dnssec.html adoption still growing, more than 60% of .nl domains currently dnssec-signed, and around 60% of queries are from validation resolvers. i looked up global stats. world map + tables about current validating resolver queries: https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec. and this is the graph over time of for the world: https://stats.labs.apnic.net/dnssec/XA https://stats.labs.apnic.net/dnssec/XA (30% validating, don't know what the additional 10% mixed means). i did a quick search, but didn't find global stats about domains being dnssec-signed. dnssec is not easy/simple (especially when getting into the details), but i think the contemporary dns servers make it relatively easy to enable dnssec on a zone, managing the signing themselves. i do like the idea of being able to set up secure connections without relying on CAs.
      - ekr____ 3y ago
        The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.
        mjl- 3y ago
        > The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever. fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is. i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled. i used to dislike the unhelpful generic error messages for dnssec-related problems (servfail). perhaps that was holding adoption back. but extended dns errors (ede) seem to solve that, though i don't know how commonly the detailed errors make it up the stack in old software.
  - simoncion 3y ago
    > ...new protocols (like DANE)... DANE? New? It's at least ten years old.
    - tptacek 3y ago
      It's old enough to have been attempted in Chrome more than a decade ago, and then removed, a decade ago.
  - silisili 3y ago
    I'm usually on your side in these perennial debates, but I worked at a registry also. Tons of inquiries, requests for assistance with it, and requirements for zone signing. Maybe the registry side views things a lot differently than the end user side.
  - rezonant 3y ago
    I'm not sure where I stand on the efficacy of DNSSEC but... 2024: > where about 40% of all our domains have DNSSEC (and that number is constantly climbing) > Originally written as a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530 https://news.ycombinator.com/item?id=27837530> 2021: > where about 40% of all our domains have DNSSEC (and that number is constantly climbing) Guessing it isn't increasing very fast then? That's 2.5 years and there's no update on that 40% figure?
    - teddyh 3y ago
      It used to be just a bit below 40%, and now it’s a bit above. It has always been steadlily increasing.
      - tptacek 3y ago
        DNSSEC delegation stats are not hard to come by. Several entities (most notably APNIC) do routine surveys and collect historical data. Here's one: https://rick.eng.br/dnssecstat/ https://rick.eng.br/dnssecstat/ Here's another: https://www.statdns.com/ https://www.statdns.com/ Notice the shape of the histograms. Things are not exactly going up and to the left, are they?
- tick_tock_tick 3y ago
  At what percent adoption will you give up? It's been marching up non stop and with the inclusion of DNSSEC in FedRAMP requirements any hope of it being a "failure" has long since past.
  - tptacek 3y ago
    It's been a FedRAMP requirement for something like a decade (when Trump took office, one of the first OMB actions rescinded it, though its current status as a federal IT requirement is uncertain; notably: CLOUD.GOV doesn't do DNSSEC, or didn't last I checked). The corresponding period is one in which .COM lost signed domains. It is very much a failure.
pornel 3y ago
DNSSEC struggles to justify its existence, because it's mostly useless without transport security, and for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC. This leaves only few scenarios where DNSSEC makes a difference. The current Web's CAs system has obvious flaws, and periodic clown shows, but it gets just enough workarounds to maintain the status quo. DNSSEC would like to replace Web's CAs with its own (DANE), but that isn't a fundamental departure from trusting CAs, only a different arrangement of authorities.
- aleph_minus_one 3y ago
  > for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC There exist other application-layer protocols than HTTP.
- tialaramex 3y ago
  > for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC The Web PKI relies heavily on DNS, and thus without DNSSEC it's vulnerable to spoofing. Of course people like Thomas have worked very hard to get people not to enable DNSSEC, and so a great many domains can be spoofed. Are they? Maybe†. It's hard to tell, after all there would be no sign of a problem, everything looks fine, there's no validation step because you said you didn't want one... † At a previous employer in 2019 I looked into this. Military intelligence definitely perform attacks on foreign country Internet infrastructure, but at that time they mostly seemed to rely on the fact that users don't use TLS and/or dismiss dialogs saying the certificates didn't match. The UX got better since, so I'd expect today they routinely ask a CA to issue for these unvalidatable domains once they control the packet flow.
  - tptacek 3y ago
    DNS transaction spoofing is not, in fact, a common cause of domain hijacking; generally, when domains are stolen and have certs misissued, it's through registrar phishing. DNSSEC does not in fact solve a real problem for the WebPKI, which is why virtually none of the Internet's most sensitive WebPKI users (for instance, Google Mail) use it.
troglodynellc 3y ago
The core problem with DNSSEC adoption has always been what happens when your ZSK/KSK expires, which it ought to for the same reason SSL certs expire. Rolling this over in an automated fashion is desirable, as if this just happens to slip your mind, too bad, NXDOMAIN This is obviously a non-starter for most people; otherwise this would just be automagic like letsencrypt is now. CDS and CDNSKEY records basically solve this problem, but last I checked only a tiny minority of registrars implement them. Even then, some of them require things like 3-day windows in which the CDS/CDNSKEY must not change before they obey. It's basically a recipe for raising your blood pressure 10mmHg. So, everyone ignores it for this very good reason. As long as it's essentially installing a landmine in your office chair nobody will touch it.
- xz53 3y ago
  > The core problem with DNSSEC adoption has always been what happens when your ZSK/KSK expires, which it ought to for the same reason SSL certs expire. For most users there's really no reason for a ZSK/KSK split or rolling keys, much the same as there's no need for rolling SSH keys for most users.

I am not an expert in DNS but isnt' DNSSEC sort of like IPV6 when it comes to utility vs adoption vs overhead ? In other words, hasn't really lived up to the expectations or am I missing something ?

tptacek 3y ago

It has massively underperformed expectations in a way that far outstrips any disappointment anyone could have in IPv6. IPv6 has adoption approaching 50%. If you have a modern ISP and a modern router, you might be using IPv6 right now without even noticing it. Meanwhile: less than 5% of the major US TLDs are signed, and an even smaller fraction of the "top domains" (given any list of top domains, like the Moz 500) are. The major prevailing use case for DNSSEC, which is DANE, has no browser support --- browsers actually tried it and removed that support.

teddyh 3y ago
My usual alternative viewpoint whenever you try to claim that DNSSEC is dead: From where I sit, I work at a registry and DNS server host (among other things) where about 40% of all our domains have DNSSEC (and that number is constantly climbing). Every conference I go to, and in every webinar, people seemingly always talk about DNSSEC and how usage is increasing. From my perspective, your continuous claim that “nobody uses” DNSSEC is simply false. DNSSEC works, usage of DNSSEC is steadily increasing, and new protocols (like DANE) are starting to make use of DNSSEC for its features. Conversely, I only relatively rarely hear anything about MTA-STS. (Originally written as a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530 https://news.ycombinator.com/item?id=27837530>, but the details given have not changed substantially.)
- tptacek 3y ago
  Start by convincing Geoff Huston, from who I could shoplift all the rebuttals I'd need to this argument. TLD DNSSEC signing stats are easy for people to look up, and people can quickly see I'm not making any of this up.
  - mjl- 3y ago
    fwiw, i live in a country where rolling out dnssec apparently had some financial incentives for providers, which apparently helped adoption: https://stats.sidnlabs.nl/en/dnssec.html https://stats.sidnlabs.nl/en/dnssec.html adoption still growing, more than 60% of .nl domains currently dnssec-signed, and around 60% of queries are from validation resolvers. i looked up global stats. world map + tables about current validating resolver queries: https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec. and this is the graph over time of for the world: https://stats.labs.apnic.net/dnssec/XA https://stats.labs.apnic.net/dnssec/XA (30% validating, don't know what the additional 10% mixed means). i did a quick search, but didn't find global stats about domains being dnssec-signed. dnssec is not easy/simple (especially when getting into the details), but i think the contemporary dns servers make it relatively easy to enable dnssec on a zone, managing the signing themselves. i do like the idea of being able to set up secure connections without relying on CAs.
    - ekr____ 3y ago
      The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.
      - mjl- 3y ago
        > The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever. fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is. i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled. i used to dislike the unhelpful generic error messages for dnssec-related problems (servfail). perhaps that was holding adoption back. but extended dns errors (ede) seem to solve that, though i don't know how commonly the detailed errors make it up the stack in old software.
- simoncion 3y ago
  > ...new protocols (like DANE)... DANE? New? It's at least ten years old.
  - tptacek 3y ago
    It's old enough to have been attempted in Chrome more than a decade ago, and then removed, a decade ago.
- silisili 3y ago
  I'm usually on your side in these perennial debates, but I worked at a registry also. Tons of inquiries, requests for assistance with it, and requirements for zone signing. Maybe the registry side views things a lot differently than the end user side.
- rezonant 3y ago
  I'm not sure where I stand on the efficacy of DNSSEC but... 2024: > where about 40% of all our domains have DNSSEC (and that number is constantly climbing) > Originally written as a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530 https://news.ycombinator.com/item?id=27837530> 2021: > where about 40% of all our domains have DNSSEC (and that number is constantly climbing) Guessing it isn't increasing very fast then? That's 2.5 years and there's no update on that 40% figure?
  - teddyh 3y ago
    It used to be just a bit below 40%, and now it’s a bit above. It has always been steadlily increasing.
    - tptacek 3y ago
      DNSSEC delegation stats are not hard to come by. Several entities (most notably APNIC) do routine surveys and collect historical data. Here's one: https://rick.eng.br/dnssecstat/ https://rick.eng.br/dnssecstat/ Here's another: https://www.statdns.com/ https://www.statdns.com/ Notice the shape of the histograms. Things are not exactly going up and to the left, are they?
tick_tock_tick 3y ago
At what percent adoption will you give up? It's been marching up non stop and with the inclusion of DNSSEC in FedRAMP requirements any hope of it being a "failure" has long since past.
- tptacek 3y ago
  It's been a FedRAMP requirement for something like a decade (when Trump took office, one of the first OMB actions rescinded it, though its current status as a federal IT requirement is uncertain; notably: CLOUD.GOV doesn't do DNSSEC, or didn't last I checked). The corresponding period is one in which .COM lost signed domains. It is very much a failure.

pornel 3y ago

DNSSEC struggles to justify its existence, because it's mostly useless without transport security, and for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC. This leaves only few scenarios where DNSSEC makes a difference. The current Web's CAs system has obvious flaws, and periodic clown shows, but it gets just enough workarounds to maintain the status quo. DNSSEC would like to replace Web's CAs with its own (DANE), but that isn't a fundamental departure from trusting CAs, only a different arrangement of authorities.

aleph_minus_one 3y ago
> for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC There exist other application-layer protocols than HTTP.
tialaramex 3y ago
> for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC The Web PKI relies heavily on DNS, and thus without DNSSEC it's vulnerable to spoofing. Of course people like Thomas have worked very hard to get people not to enable DNSSEC, and so a great many domains can be spoofed. Are they? Maybe†. It's hard to tell, after all there would be no sign of a problem, everything looks fine, there's no validation step because you said you didn't want one... † At a previous employer in 2019 I looked into this. Military intelligence definitely perform attacks on foreign country Internet infrastructure, but at that time they mostly seemed to rely on the fact that users don't use TLS and/or dismiss dialogs saying the certificates didn't match. The UX got better since, so I'd expect today they routinely ask a CA to issue for these unvalidatable domains once they control the packet flow.
- tptacek 3y ago
  DNS transaction spoofing is not, in fact, a common cause of domain hijacking; generally, when domains are stolen and have certs misissued, it's through registrar phishing. DNSSEC does not in fact solve a real problem for the WebPKI, which is why virtually none of the Internet's most sensitive WebPKI users (for instance, Google Mail) use it.

troglodynellc 3y ago

The core problem with DNSSEC adoption has always been what happens when your ZSK/KSK expires, which it ought to for the same reason SSL certs expire. Rolling this over in an automated fashion is desirable, as if this just happens to slip your mind, too bad, NXDOMAIN This is obviously a non-starter for most people; otherwise this would just be automagic like letsencrypt is now. CDS and CDNSKEY records basically solve this problem, but last I checked only a tiny minority of registrars implement them. Even then, some of them require things like 3-day windows in which the CDS/CDNSKEY must not change before they obey. It's basically a recipe for raising your blood pressure 10mmHg. So, everyone ignores it for this very good reason. As long as it's essentially installing a landmine in your office chair nobody will touch it.

xz53 3y ago
> The core problem with DNSSEC adoption has always been what happens when your ZSK/KSK expires, which it ought to for the same reason SSL certs expire. For most users there's really no reason for a ZSK/KSK split or rolling keys, much the same as there's no need for rolling SSH keys for most users.