7 ms·

Weird that they don't even mention that Google's public DNS performs DNSSEC validation. It does, and that's the ultimate defense against cache poisoning attacks

Weird that they don't even mention that Google's public DNS performs DNSSEC validation. It does, and that's the ultimate defense against cache poisoning attacks.

tptacek 3y ago
No, it obviously isn't, because less than 5% of zones are signed, and an even smaller fraction of important zones (the Moz 500, the Tranco list) are. That's why they don't mention DNSSEC: because it isn't a significant security mechanism for Internet DNS. It's also why they do mention ADoT: because it is. I think this is also why DNSSEC advocates are so fixated on DANE, which is (necessarily) an even harder lift than getting DNSSEC deployed: because the attacks DNSSEC were ostensibly designed to address are now solved problems. Note also that if ADoT rolls out all the way --- it's already significantly more available than DNSSEC! --- there won't even be a real architectural argument for DNSSEC anymore, because we'll have end-to-end cryptographic security for the DNS. Thanks for calling this out! That Google feels case randomization is more important than DNSSEC is indeed telling.
- tialaramex 3y ago
  > the attacks DNSSEC were ostensibly designed to address are now solved problems. Maybe you can help figure out where you went wrong here by explaining what - in your understanding - were the problems that DNSSEC was "ostensibly designed to address" ? > because we'll have end-to-end cryptographic security for the DNS. In 1995 a researcher who was annoyed about people snooping his passwords over telnet invented a protocol (and gave away a free Unix program) which I guess you'd say delivers "end-to-end cryptographic security" for the remote shell. Now, when you go into a startup and you find they've set up a bunch of ad hoc SSH servers and their people are just agreeing to all the "Are you sure you want to continue ..?" messages, do you think "That's fine, it's end-to-end cryptographic security" ? Or do you immediately put that on the Must Do list for basic security because it's an obvious vulnerability ?
- Hazelnut2465 3y ago
  > there won't even be a real architectural argument for DNSSEC anymore ADoT relies on NS records to be DNSSEC signed. The TLS certificates that ADoT relies on need to be hashed into TLSA records (DANE, DNSSEC).
  - tptacek 3y ago
    https://educatedguesswork.org/posts/dns-security-adox/ https://educatedguesswork.org/posts/dns-security-adox/
    - Hazelnut2465 3y ago
      And? The IETF RFC draft for ADoT still specifies that it relies on DNSSEC. https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/ https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...
      - tptacek 3y ago
        Check out the DPRIVE working group (ekr's comments in particular) for some of the backstory. DNSSEC isn't happening either way, but I think ADOX might.
        Hazelnut2465 3y ago
        I think this is a bit of an apples and oranges moment. While I agree transport confidentiality is important, that is not what DNSSEC solves, nor should you see people saying that it does solve confidentiality. DNSSEC protects the transport integrity of DNS responses. DNSSEC enabled zones 100% defeat on-path cache poisoning attacks to recursive resolvers that are DNSSEC enabled. Full stop. ADo"X" protects the transport confidentiality of DNS responses. I suppose this "weakly" protects the transport integrity of DNS responses, but, again, the primary purpose is confidentiality. After reading RFC 9539, it's clearly stated that it's opportunistic encryption. An on-path attacker will find it trivial to disable encryption and start poisoning caches. The RFC states in multiple places that if TLS setup fails, fall back to plaintext DNS. If DNSSEC fails, an on-path attacker has no similar recourse. A properly configured recursive resolver will SERVFAIL and _never_ send back a potentially poisoned response to clients for DNSSEC signed zones.
- teddyh 3y ago
  Many years ago, when HTTPS adoption was in the 5% range, if someone would have said “HTTPS is the ultimate defense against web page spoofing”, would you have argued that it was false, just because the adoption was so low? DNSSEC is the ultimate defense against cache poisoning attacks, no matter the adoption percentage.
  - tptacek 3y ago
    You should go tell Google that.
    - teddyh 3y ago
      The needs and risk profiles of Google are vastly different than basically every other organization on Earth. (I also note that you didn’t answer my question, and instead opted for a rhetorical cheap shot reply to my second paragraph only.)
      - tptacek 3y ago
        Never mind. It's OK. I don't think we're speaking the same language, so to say.
        teddyh 3y ago
        I think your posting style of making confident statements, but responding to counter-arguments with rhetorical cheap shots and condescending non-answers, is unsuitable for HN.
        tptacek 3y ago
        I don't think personal attacks are helping your case, Teddy.
        teddyh 3y ago
        Criticizing specific behavior as being unsuitable for HN is not a personal attack.
LinuxBender 3y ago
Just guessing but it could be the lack of adoption. Despite having climbed rapidly in the last few years [0] the percentage is still very low. [1] [0] - https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml https://www.verisign.com/en_US/company-information/verisign-... [1] - https://www.statdns.com/ https://www.statdns.com/
- omoikane 3y ago
  The low adoption of DNSSEC might be due to posts like these: https://news.ycombinator.com/item?id=36171696 https://news.ycombinator.com/item?id=36171696 - Calling time on DNSSEC: The costs exceed the benefits (2023) And also many news regarding validation failures: https://hn.algolia.com/?q=dnssec https://hn.algolia.com/?q=dnssec
  - tptacek 3y ago
    The rabbit hole on people gradually pulling up stakes on DNSSEC goes deeper than that; I'd say the canary in the coal mine is probably Geoff Huston switching from "of course we're going to DNSSEC everything" to "are we going to DNSSEC anything?": https://www.potaroo.net/ispcol/2023-02/dnssec.html https://www.potaroo.net/ispcol/2023-02/dnssec.html (Geoff Huston is an Internet infrastructure giant.) But really it all just boils down to the fact that the DNS zones that matter --- the ones at the busy end of the fat tail of lookups --- just aren't signed, despite 25 years of work on the standard. IPv6 is gradually mainstreaming; in countries where registrars auto-sign zones, DNSSEC is growing too, but very notably in countries where people have a choice, DNSSEC deployment is stubbornly stuck in the low single digit percentages, and the zones that are getting signed are disproportionately not in the top 10,000 of the Tranco list.
    - teddyh 3y ago
      I urge everyone to actually read the blog post by Geoff Huston. From what I can tell, it does not say what tptacek says it does. Some other counterpoints to general DNSSEC doomsayers: • <https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...> • <https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and-dnssec.html https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and...>
8organicbits 3y ago
For end users, TLS is the key protection. I don't care if my DNS is poisoned, MITMed, or malicious: if the IP address I connect to can't present a valid TLS cert, then I don't proceed. If you can't securely authenticate your server (as HTTPS/TLS does) you have other problems too.
- singpolyma3 3y ago
  Unfortunately it's quite easy for some actors to get a valid TLS cert https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/
  - tsimionescu 3y ago
    Quite astonishing that someone managed to get valid certs from Let's Encrypt for domains that they didn't own. Has Let's Encrypt issued any statements about how this might have happened, and how those specific certificates were validated by them? Still, good to see that monitoring the CT logs would have caught this problem much sooner.
    - Vorh 3y ago
      As far as I remember from when I last read that article, it was a police-requested MiTM by the hosting provider. LetsEncrypt did a standard challenge (requesting http://webroot/.well-known/something http://webroot/.well-known/something) and the MiTM responded appropriately. This isn't really a problem with LE - if you can control the http response to all outside servers, it's fair to say that you control the domain and should have the cert. Bad on the hosting provider for doing so? Maybe, but there is no way for LE to know.
phicoh 3y ago
DNS is where the web would have been if browsers basically didn't force websites to support HTTPS. The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed. At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important. If all DNS client software would drop UDP source port randomization and randomized IDs, then lots of people would be very upset. Because DNS security was more important than claimed. DNS cookies are also an interesting case. They can stop most cache poisoning attacks. But from the google article, big DNS authoritatives do not deploy them.
- tptacek 3y ago
  The key thing to note is that anti-poisoning countermeasures deployed at major authority servers scale to provide value without incurring cost for every (serverside) Internet "user", and DNSSEC doesn't. A lot of these thing seem like (really, are) half-measures, but their cost/benefit ratio is drastically different, which is why they get rolled out so quickly compared to DNSSEC, which is more akin to a forklift upgrade.
  - phicoh 3y ago
    There is no quickly in the Google article. It took them ages to roll out 0x20. Cookies are not very well supported. And then the elephant in the room is the connection between the stub resolver and the public DNS resolvers. The interesting thing is what happens when BGP is used to redirect traffic to DNS servers: https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bgp-hijack https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bg...
    - tptacek 3y ago
      Did it take 25 years? That's the baseline. :)
- throwaway458864 3y ago
  If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store. The weird irony is it's the old "worse is better" winning again. HTTP and TLS are fairly bad protocols, in their own ways. But put them together and they're better than whatever else exists. It's just too bad we didn't keep them and ditch the browser.

Weird that they don't even mention that Google's public DNS performs DNSSEC validation. It does, and that's the ultimate defense against cache poisoning attacks.

tptacek 3y ago

No, it obviously isn't, because less than 5% of zones are signed, and an even smaller fraction of important zones (the Moz 500, the Tranco list) are. That's why they don't mention DNSSEC: because it isn't a significant security mechanism for Internet DNS. It's also why they do mention ADoT: because it is. I think this is also why DNSSEC advocates are so fixated on DANE, which is (necessarily) an even harder lift than getting DNSSEC deployed: because the attacks DNSSEC were ostensibly designed to address are now solved problems. Note also that if ADoT rolls out all the way --- it's already significantly more available than DNSSEC! --- there won't even be a real architectural argument for DNSSEC anymore, because we'll have end-to-end cryptographic security for the DNS. Thanks for calling this out! That Google feels case randomization is more important than DNSSEC is indeed telling.

tialaramex 3y ago
> the attacks DNSSEC were ostensibly designed to address are now solved problems. Maybe you can help figure out where you went wrong here by explaining what - in your understanding - were the problems that DNSSEC was "ostensibly designed to address" ? > because we'll have end-to-end cryptographic security for the DNS. In 1995 a researcher who was annoyed about people snooping his passwords over telnet invented a protocol (and gave away a free Unix program) which I guess you'd say delivers "end-to-end cryptographic security" for the remote shell. Now, when you go into a startup and you find they've set up a bunch of ad hoc SSH servers and their people are just agreeing to all the "Are you sure you want to continue ..?" messages, do you think "That's fine, it's end-to-end cryptographic security" ? Or do you immediately put that on the Must Do list for basic security because it's an obvious vulnerability ?
Hazelnut2465 3y ago
> there won't even be a real architectural argument for DNSSEC anymore ADoT relies on NS records to be DNSSEC signed. The TLS certificates that ADoT relies on need to be hashed into TLSA records (DANE, DNSSEC).
- tptacek 3y ago
  https://educatedguesswork.org/posts/dns-security-adox/ https://educatedguesswork.org/posts/dns-security-adox/
  - Hazelnut2465 3y ago
    And? The IETF RFC draft for ADoT still specifies that it relies on DNSSEC. https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/ https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-a...
    - tptacek 3y ago
      Check out the DPRIVE working group (ekr's comments in particular) for some of the backstory. DNSSEC isn't happening either way, but I think ADOX might.
      - Hazelnut2465 3y ago
        I think this is a bit of an apples and oranges moment. While I agree transport confidentiality is important, that is not what DNSSEC solves, nor should you see people saying that it does solve confidentiality. DNSSEC protects the transport integrity of DNS responses. DNSSEC enabled zones 100% defeat on-path cache poisoning attacks to recursive resolvers that are DNSSEC enabled. Full stop. ADo"X" protects the transport confidentiality of DNS responses. I suppose this "weakly" protects the transport integrity of DNS responses, but, again, the primary purpose is confidentiality. After reading RFC 9539, it's clearly stated that it's opportunistic encryption. An on-path attacker will find it trivial to disable encryption and start poisoning caches. The RFC states in multiple places that if TLS setup fails, fall back to plaintext DNS. If DNSSEC fails, an on-path attacker has no similar recourse. A properly configured recursive resolver will SERVFAIL and _never_ send back a potentially poisoned response to clients for DNSSEC signed zones.
teddyh 3y ago
Many years ago, when HTTPS adoption was in the 5% range, if someone would have said “HTTPS is the ultimate defense against web page spoofing”, would you have argued that it was false, just because the adoption was so low? DNSSEC is the ultimate defense against cache poisoning attacks, no matter the adoption percentage.
- tptacek 3y ago
  You should go tell Google that.
  - teddyh 3y ago
    The needs and risk profiles of Google are vastly different than basically every other organization on Earth. (I also note that you didn’t answer my question, and instead opted for a rhetorical cheap shot reply to my second paragraph only.)
    - tptacek 3y ago
      Never mind. It's OK. I don't think we're speaking the same language, so to say.
      - teddyh 3y ago
        I think your posting style of making confident statements, but responding to counter-arguments with rhetorical cheap shots and condescending non-answers, is unsuitable for HN.
        tptacek 3y ago
        I don't think personal attacks are helping your case, Teddy.
        teddyh 3y ago
        Criticizing specific behavior as being unsuitable for HN is not a personal attack.

LinuxBender 3y ago

Just guessing but it could be the lack of adoption. Despite having climbed rapidly in the last few years [0] the percentage is still very low. [1] [0] - https://www.verisign.com/en_US/company-information/verisign-labs/internet-security-tools/dnssec-scoreboard/index.xhtml https://www.verisign.com/en_US/company-information/verisign-... [1] - https://www.statdns.com/ https://www.statdns.com/

omoikane 3y ago
The low adoption of DNSSEC might be due to posts like these: https://news.ycombinator.com/item?id=36171696 https://news.ycombinator.com/item?id=36171696 - Calling time on DNSSEC: The costs exceed the benefits (2023) And also many news regarding validation failures: https://hn.algolia.com/?q=dnssec https://hn.algolia.com/?q=dnssec
- tptacek 3y ago
  The rabbit hole on people gradually pulling up stakes on DNSSEC goes deeper than that; I'd say the canary in the coal mine is probably Geoff Huston switching from "of course we're going to DNSSEC everything" to "are we going to DNSSEC anything?": https://www.potaroo.net/ispcol/2023-02/dnssec.html https://www.potaroo.net/ispcol/2023-02/dnssec.html (Geoff Huston is an Internet infrastructure giant.) But really it all just boils down to the fact that the DNS zones that matter --- the ones at the busy end of the fat tail of lookups --- just aren't signed, despite 25 years of work on the standard. IPv6 is gradually mainstreaming; in countries where registrars auto-sign zones, DNSSEC is growing too, but very notably in countries where people have a choice, DNSSEC deployment is stubbornly stuck in the low single digit percentages, and the zones that are getting signed are disproportionately not in the top 10,000 of the Tranco list.
  - teddyh 3y ago
    I urge everyone to actually read the blog post by Geoff Huston. From what I can tell, it does not say what tptacek says it does. Some other counterpoints to general DNSSEC doomsayers: • <https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...> • <https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and-dnssec.html https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and...>

8organicbits 3y ago

For end users, TLS is the key protection. I don't care if my DNS is poisoned, MITMed, or malicious: if the IP address I connect to can't present a valid TLS cert, then I don't proceed. If you can't securely authenticate your server (as HTTPS/TLS does) you have other problems too.

singpolyma3 3y ago
Unfortunately it's quite easy for some actors to get a valid TLS cert https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/
- tsimionescu 3y ago
  Quite astonishing that someone managed to get valid certs from Let's Encrypt for domains that they didn't own. Has Let's Encrypt issued any statements about how this might have happened, and how those specific certificates were validated by them? Still, good to see that monitoring the CT logs would have caught this problem much sooner.
  - Vorh 3y ago
    As far as I remember from when I last read that article, it was a police-requested MiTM by the hosting provider. LetsEncrypt did a standard challenge (requesting http://webroot/.well-known/something http://webroot/.well-known/something) and the MiTM responded appropriately. This isn't really a problem with LE - if you can control the http response to all outside servers, it's fair to say that you control the domain and should have the cert. Bad on the hosting provider for doing so? Maybe, but there is no way for LE to know.

phicoh 3y ago

DNS is where the web would have been if browsers basically didn't force websites to support HTTPS. The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed. At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important. If all DNS client software would drop UDP source port randomization and randomized IDs, then lots of people would be very upset. Because DNS security was more important than claimed. DNS cookies are also an interesting case. They can stop most cache poisoning attacks. But from the google article, big DNS authoritatives do not deploy them.

tptacek 3y ago
The key thing to note is that anti-poisoning countermeasures deployed at major authority servers scale to provide value without incurring cost for every (serverside) Internet "user", and DNSSEC doesn't. A lot of these thing seem like (really, are) half-measures, but their cost/benefit ratio is drastically different, which is why they get rolled out so quickly compared to DNSSEC, which is more akin to a forklift upgrade.
- phicoh 3y ago
  There is no quickly in the Google article. It took them ages to roll out 0x20. Cookies are not very well supported. And then the elephant in the room is the connection between the stub resolver and the public DNS resolvers. The interesting thing is what happens when BGP is used to redirect traffic to DNS servers: https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bgp-hijack https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bg...
  - tptacek 3y ago
    Did it take 25 years? That's the baseline. :)
throwaway458864 3y ago
If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store. The weird irony is it's the old "worse is better" winning again. HTTP and TLS are fairly bad protocols, in their own ways. But put them together and they're better than whatever else exists. It's just too bad we didn't keep them and ditch the browser.