I've implemented DNSSEC twice now, I've also implemented IPv6 several times - at various levels of the stack (including directly at layer 3) and have had a hand in two different SSL/TLS implementations. Having implemented each, I don't think that DNSSEC is particularly difficult or error-prone compared to IPv6 or SSL - it's probably far less complicated than both. The trickiest part of DNSSEC to get right is probably NSEC3 (on both the authoritative side and the validating side) and it's not so bad if you brush up on trees and hashing.
But DNSSEC can still be very difficult to implement, not so much because of its inherent complexity, but because of a mismatch between assumptions the designers made and what real-world implementors require. Here's a simple example; many DNS implementations for large service support "m of n" answers. E.g. you might have 100 IP addresses for a service, and the DNS implementation would choose say 8 IP addresses to hand-out. The dogma of DNSSEC is that answers should be signed-offline, which is great for security, but it means that in cases like this that we'd have to deal with a combinatorial explosion and sign all 186 billion potential answers. We could also sign online, but doing expensive crypto in response to a DNS request isn't very smart if you'd like to survive DDOS attacks. So implementers have to make trade-offs and add complexity to make things work.
DNS is also commonly used as a routing mechanism - but DNSSEC does nothing to validate that this routing is being handled correctly. Signed answers are replayable - so the answer that says "You should go to the Dublin node" can be fed to resolvers/clients that should really be routed to a different node. This can aid attacks higher up the protocol stack that depend on routing traffic along a path it can observed. Similarly, because DNSSEC queries happen in the plain, intermediaries can easily filter and drop particular queries which they don't like.
Most bizarrely perhaps, is that DNSSEC provides no end-to-end security. Your browser or OS still communicates with your resolver using regular queries, relying on a single unauthenticated bit to "request" validation. It's as if LAN/wifi-level abuse wasn't a concern at all, or that public resolvers (like OpenDNS and Google Public DNS) didn't exist.
End-to-end security of the channel isn't necessary. DNS is public. There are clues that DNS is broken in those situations that, as with SSL, ultimately your browser would have to present to you. Local validation is all you can count on. E.g. http://www.bortzmeyer.org/dns-swisscom.html
Personally, I'm now twice as interested in relying on DNSSEC and running my own DNS resolution rather than relying on third-parties. Not least because Google's DNS doesn't always give me the closest servers for CDNs that provide different answers. Frankly, the biggest problem DNSSEC solves is securing that first HSTS response, but every bit counts. That DNS services on open WiFi stop lying... That might never happen. But perhaps future async DNS resolution baked into browsers will warn about DNS as much as SSL for those that care.
End-to-end security isn't the same thing as encryption or privacy. The goal of DNSSEC seems to be to authenticate that DNS answers are correct. In an end-to-end security model, then as you suggest - your browser should be involved, and I'd say that your browser should be performing the validation - it would need to have a recursive nameserver built in.
But that's not the DNSSEC model. The DNSSEC model is to implicitly trust your resolver, which is usually hosted remotely, accessed via an unauthenticated channel, and to ask it to perform the validation for you. If the validation fails, all your browser gets is "SERVFAIL" :
So it doesn't have the capacity to report a meaningful error.
Solving the wifi-lying problem is tricky too. A wifi network could always falsely-claim that the root zone is not signed, or fake the keys, and take things from there. Unless you keep all resolution on your laptop/tablet/phone, and synchronize the root public keys periodically (a problem equivalent to getting up-to-date root CA certs) - there's nothing to build trust on. Even more simply; the wifi network can just block DNS and disable dnssec resolution on its own resolver.
> it would need to have a recursive nameserver built in. But that's not the DNSSEC model. The DNSSEC model is to implicitly trust your resolver, which is usually hosted remotely, accessed via an unauthenticated channel, and to ask it to perform the validation for you.
If you do not wish your upstream resolver to do validation then set the CD flag - you will get an RR set that you can validate locally.
dig +cd +qr +dnssec dnssec-failed.org @8.8.8.8
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59002
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; AUTHORITY SECTION:
dnssec-failed.org. 1799 IN SOA dns101.comcast.org. dnsadmin.comcast.net. 2010101624 900 180 604800 7200
dnssec-failed.org. 21599 IN RRSIG SOA 5 2 86400 20140324165107 20140317134607 28833 dnssec-failed.org. R/stn+84i0qDGa7mMcJn00+/L1z/aj4kfCg1DiUPxokd8HK/FTwIfQcy 8oh+wsSFSYAvem3H3zZ8iVlwIHqmESEPwnkoGolI5BtnEPs7cT3kO1/i CA9DT18r4fdbJrXavWz5Z991gUOhfkpIPi1TmRC4/iZcNFwgBVhZsDEO uAc=
dnssec-failed.org. 7199 IN NSEC www.dnssec- failed.org. NS SOA RRSIG NSEC DNSKEY
dnssec-failed.org. 7199 IN RRSIG NSEC 5 2 7200 20140324165107 20140317134607 28833 dnssec-failed.org. P0s0825v9FxTYoLYqYrJMLmqfuiDvBOGhYbT2ZmypZN1GKwWfEX7TaoJ TE5RB70HNUWFE4Moi+hfRP9wye61tupT75p7Szqn53pBQ58kO73YiYiz MBWB1RreRABRbSwInvWNR9DNsVwBr/6z6/h3fDpGz5O+m8+E64xWv2T8 OgE=
But DNSSEC can still be very difficult to implement, not so much because of its inherent complexity, but because of a mismatch between assumptions the designers made and what real-world implementors require. Here's a simple example; many DNS implementations for large service support "m of n" answers. E.g. you might have 100 IP addresses for a service, and the DNS implementation would choose say 8 IP addresses to hand-out. The dogma of DNSSEC is that answers should be signed-offline, which is great for security, but it means that in cases like this that we'd have to deal with a combinatorial explosion and sign all 186 billion potential answers. We could also sign online, but doing expensive crypto in response to a DNS request isn't very smart if you'd like to survive DDOS attacks. So implementers have to make trade-offs and add complexity to make things work.
DNS is also commonly used as a routing mechanism - but DNSSEC does nothing to validate that this routing is being handled correctly. Signed answers are replayable - so the answer that says "You should go to the Dublin node" can be fed to resolvers/clients that should really be routed to a different node. This can aid attacks higher up the protocol stack that depend on routing traffic along a path it can observed. Similarly, because DNSSEC queries happen in the plain, intermediaries can easily filter and drop particular queries which they don't like.
Most bizarrely perhaps, is that DNSSEC provides no end-to-end security. Your browser or OS still communicates with your resolver using regular queries, relying on a single unauthenticated bit to "request" validation. It's as if LAN/wifi-level abuse wasn't a concern at all, or that public resolvers (like OpenDNS and Google Public DNS) didn't exist.