> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
(DNSSEC's, and thus) DANE's security can break down at every parent DNS zone. For bit.ly the parent zones are the .ly top level domain and the root zone. Each of them (but only these two) can forge valid DNSSEC records. With the current X.509 certificate infrastructure there are more than a hundred root CAs who can issue malicious certificates for use with TLS. Even though I certainly dislike the centralized nature of DNSSEC, it is hard to argue that reducing the attack surface from over a hundred institutions to two or three doesn't constitute a marked improvement. Specifically, domains like tumblr.com whose domain path is completely US hosted will no longer have to worry about "obscure" foreign CAs like "Unizeto Certum".
> In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
DNSSEC is decidedly not a server-to-server protocol. The signatures are created offline and can be verified by any party, even when they come out of a cache. In contrast, DNSCurve is a server-to-server protocol, which only secures the transport layer, but not the data itself. The post refers to the aspect, that stub resolvers (those software parts of your OS that look up the query at your ISP caching DNS server) where not envisioned by the designers of DNSSEC to verify the DNSSEC entries themselves. Nonetheless, there is nothing that hinders them from doing so and I would expect that feature to be included once DNSSEC is spread enough to justify the effort. In fact, you can already check how this would work using the dig request `dig @8.8.8.8 +dnssec example.com` which replies with the A record and the signature on the A record (you still need to get and verify the zone key of example.com though).
> DNSSEC changes all of that. It adds two new failure cases: the requestor could be (but probably isn’t) under attack, or everything is fine with the name except that its configuration has expired. Virtually no network software is equipped to handle those cases. Trouble is, software must handle those cases.
I'm curious about why software would have to handle these cases. For the end-user a binary "lookup went well, here is the result" / "there were some errors during the lookup, sorry I can't or won't give you a result" should be totally sufficient. Firefox should not confuse the user with detailed difference between "I can't verify this record, even though the parent zone says it is DNSSEC enabled" and "I can't resolve the name at all", so why does Firefox need this information?