ICANN urges adopting DNSSEC now
networkworld.com
networkworld.com
Edit: To offer more constructive criticism: I'd rather see DNSCurve http://dnscurve.org/ see wide adoption.
DNSSEC has the feature that it works even in the presence of caching (recursive) resolvers.
DNSSEC only solves half of the problems. That's why you use DNS-over-TLS (or DNS-over-HTTPS) for the other half.
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.
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.
That makes much more sense to me.
Later
Yep. It was rescinded in 2018. There is no longer a mandate for DNSSEC in federal government IT that I'm aware of.
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.
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.
In theory the client can validate them but, for various reasons, pretty much none of the implementations do that.
"If you want to configure DNSSEC for a domain that is registered with Route 53, you must use another DNS service provider"
No affiliation with either company, just a happy customer of both.
[0]https://aws.amazon.com/route53/domain-registration-agreement/
[1]https://docs.gandi.net/en/domain_names/advanced_users/dnssec.htmlIsn'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).
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.
Does anyone have more information related to the above quote? I’d like to understand better what they’re referring to.
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?
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.
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!