I'm not sure if the author really understands just how irrelevant DNSSEC is as of right now.
This is a legitimate observation. When I saw the submission title, I momentarily thought "Huh? Did DNSSEC finally take off?".
Spoiler: The answer is no. There are more effective ways to deal with security at the higher layers of the OSI model (such as relying on TLS encryption/identity).
It's one of the lowest layers in the Internet, if you can hijack DNS, then all connections the client is routed to can be used to exploit higher level security features like TLS. Yes, things like pinning of certificates can reduce this, but all a bad actor needs to do is get access to a poorly managed x509 trusted cert.
DNSSec does offer a layer of trust that most people lack today.
Attempts to solve. I don't trust identities just because the US government tells me to do so.
I believe certificate transparency + ubiquitous TLS + RFC 7858 (or DNSCurve/DNSCrypt) is a better cocktail.
A comforting 1024bit RSA blanket.
DNSSEC was hijacked --- by old-school Unix people in the IETF who loathe X.509 on aesthetic grounds and by the USG, which attempted to mandate DNSSEC --- to integrate with and replace X.509 CAs.
You write as if DNSSEC could be deployed alongside the X.509 CA hierarchy. No.
On the real-world Internet, browser trust validation has to work for everyone, or it doesn't work at all. Common-sense workarounds, like "we'll do DANE for the people who can do DANE, and then fall back to CA validation" fall apart when confronted with adversaries. Anything you "fall back" to becomes the default for purposes of security, because attackers will launch downgrade attacks to make that happen.
Don't take my word for this:
https://www.imperialviolet.org/2015/01/17/notdane.html
The net result is: DANE doesn't collapse Internet trust down to a single point; rather, it provides us with a 1036th CA. One that just happens to be run by world governments.
New DNS record types not being returned, yes this sucks, it means there are a lot of firewalls and resolvers that need to be fixed. But IPv6 has the same upward battle in terms of router support, finally making a lot of headway. As people start demanding DNSSec, anything that is blocking that will need to be fixed.
RSA 1024 keys should be replaced, but again, we should be working to fix this, should we not?
> it provides us with a 1036th CA. One that just happens to be run by world governments.
Validating a different set of data though. On top of that, TLD's can start to be ranked based on their reputation.
Just because things don't look good right now, doesn't mean that we can't work to fix them and make them better. Similarly we need to start pushing for BGP to get secured, as attacks on that network are significantly on the rise. I don't think we should just ignore the lower stacks of the network.
Obviously, DNSSEC should provide query secrecy. Obviously, every DNSSEC transaction should be encrypted. That's functionality not present in DNSSEC that must be before the protocol can be taken seriously. Resolver-server encrypted transactions also solve the problem of endpoint signature validation (because there's no weak link between servers and clients anymore).
Daniel Bernstein, among others, was smart enough to realize that if you encrypt the connection between a resolver and a server, you don't really even need signatures anymore: if every link in the resolution chain is encrypted, there's no straightforward place to launch spoofing attacks anymore. DNSSEC advocates will point out that this doesn't make injecting fake DNS records 100% impossible. But it makes it so difficult that it's not worth it to any plausible attacker.
There's nothing you can do about the fact that DNS is a hierarchical PKI controlled by governments. DANE simply can't be made to work: DNS has no business holding TLS certificates.
> the protocol should be redesigned to assume online signers, taking advantage of cryptography in every transaction.
When you say online signers, do you mean not actively storing RRSIG records for RR sets at all? Or do you mean dynamically resigning the zone after any update? I think there is a benefit to these records in validating they originate with zone from which they claim to be. The biggest concern I have right now with the protocol is that having multiple nodes being responsible for managing a zone is difficult because each has to be signed by the parent zone, though with the necessary automated support, this shouldn't be hard to overcome (i.e. makes HA harder).
> Resolver-server encrypted transactions also solve the problem of endpoint signature validation (because there's no weak link between servers and clients anymore)
Do you have any thoughts on DNS over TLS vs DNSCrypt? I got halfway through implementing DNSCrypt, but I have some concerns about it being easily exploitable for DOS attacks. And am switching to DNS over TLS for now.
> Daniel Bernstein, among others, was smart enough to realize that if you encrypt the connection between a resolver and a server, you don't really even need signatures anymore...
Yes, this is true, but the concerns I've had with this are 1) ability to cache data and 2) ability to add nodes to the network. While I completely agree with this, we need to come up with a method that allows new nodes to be added to the graph, which might be cumbersome from a resolver perspective. In terms of zone authorities it should be relatively straightforward though. With the current DNSSec design, it allows for trusted data to be stored on untrusted nodes in the graph, making cached data straightforward.
If you don't mind, I'd love your feedback on a project I've been working on for the last year: https://github.com/bluejekyll/trust-dns
I want to try and deal with many of these aspects of the protocol, from the slant of making it easier to setup and operate. I currently don't have a lot of documentation around operations, as I'm still focused on implementing some things like DNS over TLS. I'd love to bake some of these concepts into the software, so if you have any feedback that would be awesome.
Recurring pattern, just like the author of the article it's rather likely that due to it's irrelevancy the downvoters just don't know what DNSSEC actually does.
It sounds like a cool security feature for DNS until you look at what it actually does and realise that it doesn't work.