4 ms·

Cool! I had no idea this was a thing. Looks way more elegant than HSTS and all that mess. Whats the status on DNSSEC? Last I checked, it was a bit of a mess as

Cool! I had no idea this was a thing. Looks way more elegant than HSTS and all that mess. Whats the status on DNSSEC? Last I checked, it was a bit of a mess as far as protocols go.

tptacek 3y ago
It is deployed on less than 5% of .COM, and an even smaller fraction of "important" or "popular" zones (take any top 500, run it through a loop of `dig ds $domain +short`; try "microsoft.com" and "google.com", and then "uscis.dhs.gov" to see what a positive response looks like). IIRC, there have been recent years where the deployment count in .COM went down. It's pretty much a dead letter.
- teddyh 3y ago
  Almost every time anyone mentions DNSSEC here on HN, you pop up like a jack-in-the-box to claim that nobody is using it and that it is dead. And it’s always you, nobody else. Whereas, 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. You might have some valid criticism about the cryptography; I would not be able to judge that (except when you are basing it on wildly outdated information). I’m not an expert on the details; you could most assuredly argue circles around me when it comes to the cryptography, and possibly about the DNSSEC protocol details as well. But, 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. (Repost of 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
    (I vouched this comment, because I wanted to reply to it.) I'm not making the statistics up; you can just Google "DNSSEC deployment statistics" to see that I'm right about them, and I even provided a methodology in the comment you responded to for readers to verify for themselves. Where DNSSEC signatures are climbing, it's largely because of registrars that automatically sign domains for customers. That's security theater. Moreover, it's capturing the least interesting cohort of new DNS zones: random things people register. I own a bunch of them, including "atmosflat.org" and "paulgra-ham.com" (don't ask me, I don't remember). If I had registered them at an autosigning DNSSEC registrar, they too would count in the "steadily increasing" count to which you refer.
    - chrismorgan 3y ago
      Why/how is automatic signing of domains security theatre? As one not particularly involved, I’d have thought that was the goal, and certainly the only way you’re ever going to get anything but niche usage.
      - tptacek 3y ago
        The registrar controls your keys. Further: virtually all DNS hijacking happens via registrars, not the on- and off-path network attacks on the DNS that DNSSEC attempts to defend against. (I'm focused on the stats argument here, because I feel like 'teddyh was trying to imply that I was making them up --- he only ever sees me relating them, to which I'd respond "that's because nobody else cares about DNSSEC". I have, an, uh, pretty expansive case to make against DNSSEC, but here I was just sort of relying on context 'teddyh and I share. Sorry about that!)
        alwillis 3y ago
        > The registrar controls your keys. I've been managing domains with DNSSEC for several years and I've always had control of my keys. Clarification of who controls what keys [1]: The TLD zone's private keys are managed by the company operating it. For a Country Code Top-Level Domain (ccTLD), the government of the country will be managing the key. For popular TLDs like .COM or .NET, it will be the U.S. government through the operator Verisign. For popular ccTLD .IO, it is the government of British Indian Ocean Territory. The private keys for an individual domain name are managed by the domain owner either directly or via the DNS provider hosting their domain name. With DNSSEC, it is pretty clear who controls the private keys and also keeps the risks involved distributed. Which means while China holds private keys for .cn ccTLD, it can only sign domain names under it. [1]: 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-...
  - alwillis 3y ago
    > Almost every time anyone mentions DNSSEC here on HN, you pop up like a jack-in-the-box to claim that nobody is using it and that it is dead. And it’s always you, nobody else. Yup. > You might have some valid criticism about the cryptography; I would not be able to judge that (except when you are basing it on wildly outdated information). Yes—context matters. Unless someone knows the details of how DNSSEC works, they wouldn't necessarily recognize how disingenuous chronic DNSSEC detractors often are. In addition to DANE, I'd also add SSHFP [1], another protocol enabled by DNSSEC that addresses SSH's default trust on first use (TOFU) issue in a pretty straightforward way. Anyone new just has to read "For DNSSEC And Why DANE Is Needed" [2], where the author debunks the talking points that DNSSEC detractors often use. There's often a hint of truth to these talking points but the reality is more nuanced than they would lead you to believe. [1]: https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and-dnssec.html https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and... [2]: 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-...
    - tptacek 3y ago
      I can't think of a less compelling DNSSEC use-case than enrolling your own SSH servers, which strangers on the Internet never log into, into a global PKI. That's a complete mismatch of threat models. Why would you give the United States Government a say in whether you trust your own server? It's your own server! You don't have the problem DNSSEC tries to solve. I don't like trust-on-first-use either. Fortunately, it's easy to solve: just use an SSH CA, which is what most shops with significant numbers of servers do (because it's drastically easier to administer than individual keys). I've never seen this "technitium" blog before. It's very long. If you want to see me pick it apart, submit it tomorrow and see if you can get it on the front page. Very few people are reading this thread, so I'm definitely not going to close-read it just for this.
      - alwillis 3y ago
        > Fortunately, it's easy to solve: just use an SSH CA Sure, you could use SSH certificates, but that does mean deploying user certificates to your users and server certificates to your servers, etc. And for some use cases, this would be the right thing to do. Yes, a 10,000 person enterprise with dozens of servers should use SSH certificates. On the other hand, using SSHFP is also a viable solution, depending on the use case. In general, it's less work than creating a SSH CA, signing keys, distributing certificates, etc, especially when SSH certificates would be overkill. On the other hand, with SSHFP, you run ssh-keygen -r examplehost.example.org and add the records to the server's DNS configuration. On the client side, a user adds VerifyHostKeyDNS yes to their OpenSSH configuration and they're done. > Why would you give the United States Government a say in whether you trust your own server? It's your own server! SSHFP records are just the fingerprint of the server's public keys—no 3rd party has a say in the ssh-keygen command generating the records. I just made some SSHFP records—no government involved: SSHFP <KEY-ALGO> <HASH-TYPE> <FINGERPRINT> localhost IN SSHFP 1 1 78aefcdf726dfd71160c8dd9e31b385174da4189 localhost IN SSHFP 1 2 830313e0f1c70de6db7431f22f488e715f5882b7ad82a11bcb0b784fba618cfc localhost IN SSHFP 3 1 8140d1ed33ee45e0d078e1c0ef61df03332eac5c localhost IN SSHFP 3 2 748fdd9a6795626ec4c201cc41fb62c7407227db3e810e1a26d2e0b8cb82e896 localhost IN SSHFP 4 1 c75294aa5909c2dbfcd5606005bc4f2d1ec37ff6 localhost IN SSHFP 4 2 795480afe1777c3438f40bc269c25667cf366ef24c14f264456ff10844b818fb KEY-ALGO Algorithm 0 reserved 1 RSA 2 DSA 3 ECDSA 4 ED25519 5 unassigned 6 ED448 HASH-TYPE Algorithm 0 reserved 1 SHA1 2 SHA256 The role that DNSSEC plays is ensuring that when a SSH client does a DNS lookup, it can trust the DNS reply hasn't been tampered with.
jeroenhd 3y ago
DNSSEC is widely supported and used in some countries but practically unused in others (https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec) How easy it is to set up depends on where you host and bought your domain. In my experience, I needed to copy-paste two keys and it Just Worked. It's barely used in .COM though, so companies like Amazon took ages to implement even basic support for it, and their buggy services took down various websites. To top it all off, mistakes by badly managed TLDs caused downtimes for various TLDs over time, of "someone told the root servers to redirect .NZ to localhost for a week" severity. If whoever is managing your TLD cannot be trusted to maintain a TLD, don't enable DNSSEC. The protocol is Very 90s ("computers aren't fast enough to validate RSA signatures so let's centralise it"), but modern clients take all of the 90s bullcrap out of the picture. DNSSEC is in dire need of a v2 that fixes this, but I've never had much trouble with it in practice, other than when websites misconfigure their DNSSEC config.
- thayne 3y ago
  > other than when websites misconfigure their DNSSEC config One major problem with DNSSEC is that it is relatively easy to misconfigure it, especially in more complicated scenarios, and a misconfiguration can take you down for a long time.
  - bodgie 3y ago
    It can also be quite easy. Buggy complicated Route 53 and self-hosting with a buggy bespoke solution aren't the only options, but they are the only kinds of DNSSEC failures I've seen on the HN front page.
    - tptacek 3y ago
      The only failures you see on the HN front page are the ones that occur to gigantic companies we've all heard of, with huge networking teams and all the advantages you can ask for in getting DNSSEC working. When random small shops fall off the Internet because they broke DNSSEC, nobody cares; it never makes any front page anywhere.

Cool! I had no idea this was a thing. Looks way more elegant than HSTS and all that mess. Whats the status on DNSSEC? Last I checked, it was a bit of a mess as far as protocols go.

tptacek 3y ago

It is deployed on less than 5% of .COM, and an even smaller fraction of "important" or "popular" zones (take any top 500, run it through a loop of `dig ds $domain +short`; try "microsoft.com" and "google.com", and then "uscis.dhs.gov" to see what a positive response looks like). IIRC, there have been recent years where the deployment count in .COM went down. It's pretty much a dead letter.

teddyh 3y ago
Almost every time anyone mentions DNSSEC here on HN, you pop up like a jack-in-the-box to claim that nobody is using it and that it is dead. And it’s always you, nobody else. Whereas, 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. You might have some valid criticism about the cryptography; I would not be able to judge that (except when you are basing it on wildly outdated information). I’m not an expert on the details; you could most assuredly argue circles around me when it comes to the cryptography, and possibly about the DNSSEC protocol details as well. But, 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. (Repost of 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
  (I vouched this comment, because I wanted to reply to it.) I'm not making the statistics up; you can just Google "DNSSEC deployment statistics" to see that I'm right about them, and I even provided a methodology in the comment you responded to for readers to verify for themselves. Where DNSSEC signatures are climbing, it's largely because of registrars that automatically sign domains for customers. That's security theater. Moreover, it's capturing the least interesting cohort of new DNS zones: random things people register. I own a bunch of them, including "atmosflat.org" and "paulgra-ham.com" (don't ask me, I don't remember). If I had registered them at an autosigning DNSSEC registrar, they too would count in the "steadily increasing" count to which you refer.
  - chrismorgan 3y ago
    Why/how is automatic signing of domains security theatre? As one not particularly involved, I’d have thought that was the goal, and certainly the only way you’re ever going to get anything but niche usage.
    - tptacek 3y ago
      The registrar controls your keys. Further: virtually all DNS hijacking happens via registrars, not the on- and off-path network attacks on the DNS that DNSSEC attempts to defend against. (I'm focused on the stats argument here, because I feel like 'teddyh was trying to imply that I was making them up --- he only ever sees me relating them, to which I'd respond "that's because nobody else cares about DNSSEC". I have, an, uh, pretty expansive case to make against DNSSEC, but here I was just sort of relying on context 'teddyh and I share. Sorry about that!)
      - alwillis 3y ago
        > The registrar controls your keys. I've been managing domains with DNSSEC for several years and I've always had control of my keys. Clarification of who controls what keys [1]: The TLD zone's private keys are managed by the company operating it. For a Country Code Top-Level Domain (ccTLD), the government of the country will be managing the key. For popular TLDs like .COM or .NET, it will be the U.S. government through the operator Verisign. For popular ccTLD .IO, it is the government of British Indian Ocean Territory. The private keys for an individual domain name are managed by the domain owner either directly or via the DNS provider hosting their domain name. With DNSSEC, it is pretty clear who controls the private keys and also keeps the risks involved distributed. Which means while China holds private keys for .cn ccTLD, it can only sign domain names under it. [1]: 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-...
- alwillis 3y ago
  > Almost every time anyone mentions DNSSEC here on HN, you pop up like a jack-in-the-box to claim that nobody is using it and that it is dead. And it’s always you, nobody else. Yup. > You might have some valid criticism about the cryptography; I would not be able to judge that (except when you are basing it on wildly outdated information). Yes—context matters. Unless someone knows the details of how DNSSEC works, they wouldn't necessarily recognize how disingenuous chronic DNSSEC detractors often are. In addition to DANE, I'd also add SSHFP [1], another protocol enabled by DNSSEC that addresses SSH's default trust on first use (TOFU) issue in a pretty straightforward way. Anyone new just has to read "For DNSSEC And Why DANE Is Needed" [2], where the author debunks the talking points that DNSSEC detractors often use. There's often a hint of truth to these talking points but the reality is more nuanced than they would lead you to believe. [1]: https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and-dnssec.html https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and... [2]: 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-...
  - tptacek 3y ago
    I can't think of a less compelling DNSSEC use-case than enrolling your own SSH servers, which strangers on the Internet never log into, into a global PKI. That's a complete mismatch of threat models. Why would you give the United States Government a say in whether you trust your own server? It's your own server! You don't have the problem DNSSEC tries to solve. I don't like trust-on-first-use either. Fortunately, it's easy to solve: just use an SSH CA, which is what most shops with significant numbers of servers do (because it's drastically easier to administer than individual keys). I've never seen this "technitium" blog before. It's very long. If you want to see me pick it apart, submit it tomorrow and see if you can get it on the front page. Very few people are reading this thread, so I'm definitely not going to close-read it just for this.
    - alwillis 3y ago
      > Fortunately, it's easy to solve: just use an SSH CA Sure, you could use SSH certificates, but that does mean deploying user certificates to your users and server certificates to your servers, etc. And for some use cases, this would be the right thing to do. Yes, a 10,000 person enterprise with dozens of servers should use SSH certificates. On the other hand, using SSHFP is also a viable solution, depending on the use case. In general, it's less work than creating a SSH CA, signing keys, distributing certificates, etc, especially when SSH certificates would be overkill. On the other hand, with SSHFP, you run ssh-keygen -r examplehost.example.org and add the records to the server's DNS configuration. On the client side, a user adds VerifyHostKeyDNS yes to their OpenSSH configuration and they're done. > Why would you give the United States Government a say in whether you trust your own server? It's your own server! SSHFP records are just the fingerprint of the server's public keys—no 3rd party has a say in the ssh-keygen command generating the records. I just made some SSHFP records—no government involved: SSHFP <KEY-ALGO> <HASH-TYPE> <FINGERPRINT> localhost IN SSHFP 1 1 78aefcdf726dfd71160c8dd9e31b385174da4189 localhost IN SSHFP 1 2 830313e0f1c70de6db7431f22f488e715f5882b7ad82a11bcb0b784fba618cfc localhost IN SSHFP 3 1 8140d1ed33ee45e0d078e1c0ef61df03332eac5c localhost IN SSHFP 3 2 748fdd9a6795626ec4c201cc41fb62c7407227db3e810e1a26d2e0b8cb82e896 localhost IN SSHFP 4 1 c75294aa5909c2dbfcd5606005bc4f2d1ec37ff6 localhost IN SSHFP 4 2 795480afe1777c3438f40bc269c25667cf366ef24c14f264456ff10844b818fb KEY-ALGO Algorithm 0 reserved 1 RSA 2 DSA 3 ECDSA 4 ED25519 5 unassigned 6 ED448 HASH-TYPE Algorithm 0 reserved 1 SHA1 2 SHA256 The role that DNSSEC plays is ensuring that when a SSH client does a DNS lookup, it can trust the DNS reply hasn't been tampered with.

jeroenhd 3y ago

DNSSEC is widely supported and used in some countries but practically unused in others (https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec) How easy it is to set up depends on where you host and bought your domain. In my experience, I needed to copy-paste two keys and it Just Worked. It's barely used in .COM though, so companies like Amazon took ages to implement even basic support for it, and their buggy services took down various websites. To top it all off, mistakes by badly managed TLDs caused downtimes for various TLDs over time, of "someone told the root servers to redirect .NZ to localhost for a week" severity. If whoever is managing your TLD cannot be trusted to maintain a TLD, don't enable DNSSEC. The protocol is Very 90s ("computers aren't fast enough to validate RSA signatures so let's centralise it"), but modern clients take all of the 90s bullcrap out of the picture. DNSSEC is in dire need of a v2 that fixes this, but I've never had much trouble with it in practice, other than when websites misconfigure their DNSSEC config.

thayne 3y ago
> other than when websites misconfigure their DNSSEC config One major problem with DNSSEC is that it is relatively easy to misconfigure it, especially in more complicated scenarios, and a misconfiguration can take you down for a long time.
- bodgie 3y ago
  It can also be quite easy. Buggy complicated Route 53 and self-hosting with a buggy bespoke solution aren't the only options, but they are the only kinds of DNSSEC failures I've seen on the HN front page.
  - tptacek 3y ago
    The only failures you see on the HN front page are the ones that occur to gigantic companies we've all heard of, with huge networking teams and all the advantages you can ask for in getting DNSSEC working. When random small shops fall off the Internet because they broke DNSSEC, nobody cares; it never makes any front page anywhere.