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 ?
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>, but the details given have not changed substantially.)
i looked up global stats. world map + tables about current validating resolver queries: https://stats.labs.apnic.net/dnssec. and this is the graph over time of for the world: 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.
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.
Yes, but this isn't a replacement for the WebPKI because it would allow the recursive to impersonate any site, which is obviously unacceptable.
> 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.
A year or so ago we took some measurements of DNSSEC success rates with Firefox on known-good domains that we controlled and the results were very bad. I don't have the data to hand right at the moment, but requiring DNSSEC validation would have produced unacceptably high failure rates.
Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.
If even the PGP enthusiasts can't be bothered to use the approach, it must be well and truly dead.
isn't that similar to providers managing/having access to the tls keys? well, dns is a bit more essential. but plain dns isn't more secure. ideally we can all only access our own keys, but that doesn't seem to be the standard.
i have been wondering how common it is for dns operators to just serve (the signed) zones that get sent in by domain owners. and if that has technical hurdles for the operators (i'm sure the reason for many domain owners is they want to outsource responsibility).
> DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed
seems like it for browsers. it seems dane for mail has a future. the alternative to dane, pki-based mta-sts, has downsides like tofu for policies and needing long-lived cachable policies, especially not great given the decentralized nature. currently, many domains have no protection for deliveries (unverified mx records & tls certs).
found this just now, interesting: https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.p... mentions tls with dane records inside. but not necessarily hopeful for dnssec, it is hard to change infrastructure. i always wonder to what extent new protocols are lobbied and their rollout preplanned vs hoping for the best.
> you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure.
i often wonder why not more "signals" about how to connect are in dns. perhaps lack of dnssec. with dnssec that becomes an option, preventing a downgrade. probably bad middleboxes that don't let certain dns requests through (a reason to encrypt). the trend seems to be https on a subdomain that serves a policy.
> Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT.
i should update my knowledge exactly on the good/bad about the dnssec trust roots. if there are good docs out there, i'm interested.
> Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.
true, it doesn't seem like we're in bad position with LE. and they keep getting better (shorter-lived certs). though perhaps we're getting a little bit reliant on this one CA.
Yes. Cloudflare-like solutions has access to all the TLS keys. In addition, any cloud solution with with anycast will have partners that has access to all keys, and there is no validation that all partners will respond with the exact same information. The only non-security theater is self hosting of everything with hardware and software under the user's full control.
> i have been wondering how common it is for DNS operators to just serve (the signed) zones that get sent in by domain owners.
Very common. As a service it is usually called slave zone or hidden master. Practically all DNS providers have this as a product. The solution for public key roll over varies between providers, and some TLDs have started to use CDS/CSYNC which removes the registrar from the whole chain. CDS/CSYNC is however a bit more rare so the more common method is to either use long lived keys or a registrar API for uploading new keys.
Actually, you do have to make proper counter-arguments. That is how a debate works. Simply declaring your opponent's arguments as "risible" is not cool.
If you please, explain how DNSSEC adoption is different from HTTPS adoption. They seem to have quite close analogs: In the usual case, both are done by the server operators (authoritative DNS server and web server, respectively), not by the end customers themselves, and the server operators also handle and hold all related public and private keys.
You seem to be arguing upthread that DNSSEC adoption somehow does not count since the end customer does not hold the keys themselves. But the same is the case for typical web hosting. So how is this different?
I don't think you're experiencing me being evasive so much as that I simply don't accept your premises.
I disagree with this ludicrous assertion, but you are answering a different question, so I will not pursue this question at this time, in favor of the issue at hand:
Upthread, you wrote that with “DNS providers managing DNSSEC”, “none of this counts as "adoption”. Why not? You also wrote that “providers managing and custodying keys for their customers […] is security theater”. How is this different from HTTPS keys? Why are HTTPS keys not “security theater”, but DNSSEC keys are?
Remember when you're thinking about this that most (virtually all, really) of the largest and/or most important organizations on the Internet don't use DNSSEC, so it wouldn't make any difference at all to them. And, in case this needs saying, it doesn't really count (in the spirit of this thought experiment) if the entity you think of is, like, a DNSSEC provider; stipulate, DNSSEC providers themselves would freak out. But who else would?
Now, to my question? Again: it seems like a very broad, very easily falsified argument. Who, other than DNSSEC providers themselves, would need to be paged if the DNSSEC root keys ended up on Pastebin? Be specific, if you can? Seems like this should be easy to answer!
What? No, most people do not run their own web server. Most people have their web site on a web host, and lets the web hoster manage it, including the TLS keys. Just like with DNS and the DNSSEC keys.
> Who, other than DNSSEC providers themselves, would need to be paged if the DNSSEC root keys ended up on Pastebin?
I freely admit that I don’t know. Beside ICANN, I’m guessing all the TLD operators, since their records can now be spoofed with impunity. But, I guess you could also ask: What would happen if, say, the keys for the X.509 certificates for google.com was leaked?
• <https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...>
• <https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and...>
Please, make your arguments yourself instead of telling us how your dad is the boss of Xbox or whatever.
I'll also note that you dismissed my references as being by "randos", without any further argument or even reading them.
If you insist on dismissing arguments outright from persons whom you do not consider authoritative, consider Geoff Huston, a person you referred to before: <https://www.potaroo.net/ispcol/2023-02/dnssec.html>.
Now, have you read my reference, and can you argue against it?
That's as far as I feel like I have to go on this very old, very dead thread.
Submit either of them to HN as a new story, and if they hit the front page, you can be quite sure of getting a take from me on them.
DANE? New? It's at least ten years old.
Maybe the registry side views things a lot differently than the end user side.
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>
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?
Here's one:
https://rick.eng.br/dnssecstat/
Here's another:
Notice the shape of the histograms. Things are not exactly going up and to the left, are they?
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.
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.
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.
There exist other application-layer protocols than HTTP.
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.
If he wants to correct me on this, he should be probably do so more clearly and less evasively? I'm being pretty specific and making claims that I think are pretty easy to falsify.
CAs are deterred from misissuing by CA/B forum and CT logs. This is actually stronger than DNSSEC where browsers have no power to catch and punish malicious/incompetent CAs.
Web PKI is vulnerable to DNS spoofing when issuing domain-validated certificates, and this is kinda crapshoot. It is getting "patched" with things like querying from multiple vantage points, push for RPKI to make BGP attacks harder, and certificate transparency to catch spoofing after the fact. This is a weakness, but somehow TLS hasn't collapsed yet because of that.