[wtallis]

> If that is true, and that is what I would expect, and we've minimized the risk of cache poisoning by using a localhost cache exlcusively (no third party caches), then why use DNSSEC?

How have you authenticated that your ISP isn't intercepting DNS requests and serving them out of their own cache that lies?

[regularfry]

Connecting to the remote service and validating the ssl cert.

[wsfull]

Yes.

As yet, there's still no foolproof way to verify/authenticate an endpoint on the internet. Not to mention the issue of so-called "host security".

Checking for a file on the remote host, e.g., a cert or a key a la ssh, seems to me a more sensible approach than relying solely on the promises of a "trusted third party" (CA's, ICANN, registrars, etc.) that you have never met.

Fears of ISP's intercepting port 53 traffic was not the reason why DNSSEC was revived from the failed protocol graveyard. ISP's do not have to go through the trouble. Most of their customers have the ISP's resolver addresses in their DNS settings, not a loopback address.

And although the software is available almost no ISP customers are encrypting their DNS packets.

DNS data for the public www is public information like the telephone book. It is easy to obtain. And once you have it, not only can you monitor changes, but there's little need to even run a cache.

You can just pluck out the names you need and plug them into your own authoritative server. Edit resolv.conf to point to it and you're done.

Easy way to speed up your www browsing and still very effective at blocking ads, apps phoning home, etc.