3 ms·

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 bro

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 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.

colmmacc 13y ago
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" : dig +qr +dnssec dnssec-failed.org @8.8.8.8 ; <<>> DiG 9.8.3-P1 <<>> +qr +dnssec dnssec-failed.org @8.8.8.8 ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6944 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssec-failed.org. IN A ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6944 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 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.
- ukj 13y ago
  > 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=

colmmacc 13y ago

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" : dig +qr +dnssec dnssec-failed.org @8.8.8.8 ; <<>> DiG 9.8.3-P1 <<>> +qr +dnssec dnssec-failed.org @8.8.8.8 ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6944 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssec-failed.org. IN A ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6944 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 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.

ukj 13y ago
> 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=