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.
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.
(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.
I never claimed you did. But they are, from my perspective, misleading.
> registrars that automatically sign domains for customers
Like I wrote the very last time I posted my comment two years ago:
Registrars can’t “auto-sign” domains. Only DNS server operators can do that, if they have the cooperation of the registrar. And the DNS server operators is the only workable definition of “owners of the zones”, so they do own their keys. It can’t work any other way.
In fact, the new CDS and CDNSKEY DNS records allow it to work the other way around; DNS server operators can auto-sign domains, and the registrars need not be involved at all.
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.
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!)
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.
You've misunderstood the point. I'm not claiming that DNSSEC doesn't allow you to manage your own keys! I'm saying that the hundreds of thousands of auto-signed zones at registrars that just enable DNSSEC by default don't have end-user managed keys.
> 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.
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.
> 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:
Is there any use case that's actively deployed, where DANE is being used? I tried to look up use cases that exist today, and it seems like it's "people who run their own postfix/exim servers", 2 niche email providers, and... GPG?
I don't follow DANE but I think support among the mail community is wider than you suggest unless Microsoft Exchange Online is one of the niche email providers you're referring to.
IIRC, there have been recent years where the deployment count in .COM went down.
It's pretty much a dead letter.