This doesn't really answer the argument that the parent comment made. You can say DNSSEC "works" in the presence of a caching resolver the same way you can say the TLS Heartbeat extension "works"; sure, it's there, and it's doing stuff that the RFC says it should do, but that begs the question: why is it there? There are really no meaningful use cases left for DNSSEC.
DNS-over-TLS is only intended for stub resolver - recursive resolver traffic (check the introduction sections of the relevant RFCs). We're still lacking a protocol to provide confidentiality between the recursive resolver and authoritative servers. DNSCurve would offer that.
Which makes sense, because there is (in general) not much point in protecting traffic between recursive and auth. servers if you don't protect the stub resolver.
At the same time traffic between stub resolver and recursive resolver is much more privacy sensitive.
So it makes sense to first get TLS between stub and recursive up and running. And that proves already hard enough.
Technically stub resolvers and recursive resolvers are the same thing (one is an inherent part of the other). So all is needed is recursive resolvers to communicate securely with authoritative servers. Tunnels to third party recursive resolvers do nothing but leak private data to them.
But traffic to a recursive resolver can already be protected by other means, e.g. a tunnel to one that you control. There are zero options for contacting the authoritative ones.
I don't have the DHS "emergency directive" (referenced in the article) handy at the moment (and it's been a couple months since I read it) but I don't recall ANY recommendation (or "directive") by DHS for the government agencies to implement DNSSEC.
In fact, if memory serves, DNSSEC was not mentioned AT ALL in the DHS document.
That's somewhat telling, IMO.
I'm not sure what ICANN's motivations are in pushing DNSSEC so hard -- all of these "hijackings" were due to compromised accounts (at DNS providers, registrars, etc.).
Instead of requiring government agencies to implement DNSSEEC, DHS instead directed them to rotate/secure their accounts/passwords at the DNS providers, registrars, etc.
I don't understand what's the point of DNSSEC. Literally the only attack scenario that DNSSEC protects from is when someone is MITMing your ISP, which, I believe, is something that practically never happens.
It doesn't do anything about the most common attack scenarios, such as MITM between the client and the last mile DNS server or hackers stealing your domain registrar credentials.
To be honest, it seems to me that the real purpose of this protocol is to make people/enterprises feel safer without actually doing anything useful.
DNSSEC fully supports DNSSEC validation on the host. So the main reason you have to trust your ISP's recursive resolvers is that software vendors, in particular browser vendors, don't want to do DNSSEC validation.
Of course you can run your own local validating resolver.
An attacker that controls routing can bypass the DNS entirely, so it's hard to see how protecting the DNS from that attacker serves any meaningful purpose.
> Literally the only attack scenario that DNSSEC protects from is when someone is MITMing your ISP, which, I believe, is something that practically never happens.
It also helps when your ISP is MITMing your attempts to get accurate DNS information. That happens all the time, though most of it is just sending you to advertisements when you're supposed to get NXDOMAIN.
Yeah. It's extremely disappointing that AWS hasn't implemented DNSSEC in Route 53. Even more so, since they have actually been a target of an attack on Route 53, that would have been ineffective if DNSSEC had been enabled.
If you are buying a domain through Route 53, there is a good chance the purchase is actually being handled by Gandi[0]. Gandi supports DNSSEC[1] (it's literally a check box in the options, very simple) so you may as well skip buying the domain through Route 53 and get it directly from Gandi.
No affiliation with either company, just a happy customer of both.
I feel like HN is getting to the point where, if I'm 24 hours late to a DNSSEC story, other people will have gotten the main points I'd have made first, and those points will be voted high on the page. You're all grown up, now, HN.
Instead of passively waiting why not encourage him to comment with a note such as "Finally! DNSSEC will solve most internet problems! No need for CAs!"
> “Some of the attacks target the DNS, in which unauthorized changes to the delegation structure of domain names are made, replacing the addresses of intended servers with addresses of machines controlled by the attackers. This particular type of attack, which targets the DNS, only works when DNSSEC is not in use,” ICANN stated.
Isn't that a bald-faced lie? The attacks in question are "someone stole my credentials and told my DNS provider to change the records to point elsewhere", as I understand them. DNSSEC merely protects against DNS spoofing on the internet backbone (not everywhere, because you're not supposed to turn out in when querying your ISP's DNS server, so the last mile isn't protected).
The argument seems to be that if your attacker is stupid enough to only change your NS records and doesn't know about DS records, then DNSSEC will provide some protection.
It is not clear with ICANN mentions this, because somebody hacking your registry account (or somebody hacking your registry or the registrar) are attacks DNSSEC cannot protect against.
A threat model where the attacker is assumed to be stupid is a very weak threat model. Better to assume that the attacker is at least as knowledgeable as you are.
> “However, most implementations are incompatible with modern DNS requirements, including redundant DNS setups or dynamic responses from DNS-based traffic-management features,” Beevers said. “Legacy DNSSEC implementations break even basic functions, such as geo-routing, and is hard to implement across multiple vendors, which means poor performance and reduced availability for end users.”
Does anyone have more information related to the above quote? I’d like to understand better what they’re referring to.
I can field this one. DNSSEC was conceived with support for a traditional zone transfer process. When you edit the zone, you sign it once (potentially offline) and send it via zone transfer to all your authoritative servers. In that context, the authoritative servers can't do things like serve the best A or whatever record given the recursive resolver contacting them and global state. Instead, you generally end up with your keys online on all the authoritative servers. Which means if your DNS account is hacked, chances are, the hackers are in a position to change your records. If your registrar account is hacked, the hackers are certainly able to remove or replace the DS records at the registry, so DNSSEC doesn't help there either (good auth at the registry and registrar and maybe registry lock help there).
DNSSEC might help with MITM, if you only communicate with recursive resolvers you trust to properly implement it and not sneak in any garbage, but it doesn't help against account compromise.
Well, you have to serve them all and let the client decide what to use, like with MX or SRV. Too bad HTTP is stuck in time and can't get any proper functionality.
And yes, I mean it is literally too bad. Why can HTTP hold 3 current standards at the same time, but still fail to work with basic internet infrastructure?
Are we at the point of desperation in the death gasps of DNSSEC where its advocates are now blaming other protocols for not rearchitecting the way they use the DNS to make it DNSSEC more viable? Because: nobody was ever going to do that.
I sometimes wonder that too. There are tons of simple things HTTP and web browsers could implement to make everyone's life better and easier. Make redundancy built-in, for example, or a primitive peer-to-peer content delivery for stuff like videos. But then I remember that megacorps always want to keep competition out, make everyone invest a lot into crappy traditional infrastructure to compete. They can't allow a competing alternative to work on many orders of magnitude cheaper infrastructure, they are only interested in increasing that cost for everyone and at such pace that nobody can keep up.
I think it means 'if you have a hacked DNS server that has all kinds of custom code to talk to databases, or other resources, then you will find that off the self DNS servers with DNSSEC will not support your hacks'.
Note that DNSSEC implementations started out with offline signing, both for performance and security.
I guess you can do geo-routing with offline signing as well. But some people find it easier to complain about new technology then to spend some effort making it work.
There are now also DNS servers that do online DNSSEC signing.
Essentially all non-toy real-world deployments of DNSSEC (perhaps outside of the DNSSEC root and TLD infrastructure itself) requires online signers, not just for basic operational reasons but because online signing is how defense against zone dumping (NSEC+"whitelies") works. So, yes, there are definitely servers that do online signing.
But then you're left wondering: why would we deploy a protocol that took profound tradeoffs to facilitate offline signing, when it turns out most of the real-world use cases were going to be online? If the protocol had been designed for online signers in the first place, it would be cleaner and more powerful in a bunch of different ways.
Instead, DNSSEC advocates propose that --- despite the fact that the industry has essentially not meaningfully deployed the protocol yet, after 25 years of standardization effort --- we just say "fuck it" and deploy this 90s protocol anyways. Something must be done! This is something!
Edit: To offer more constructive criticism: I'd rather see DNSCurve http://dnscurve.org/ see wide adoption.