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

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.