Hacker News new | ask | show | jobs
by wsfull 3703 days ago
If you are using your own DNS cache listening on a loopback interface, then the risks of "DNS cache poisoning" are not what they are when you use a third party cache like your ISP's, OpenDNS, Google or the ones in the CSV file at the github page referenced in this blog entry.

Unless you are sharing your loopback with the network somehow, one could argue that with a localhost cache the risk is nonexistent.

According to this blog entry the reason for using DNSSEC is to "prevent DNS posioning".

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?

If there are other reasons, like making centralized control (censorship?) of DNS easier for ICANN, etc., then this blog post has omitted them. Does that imply they are insignificant?

2 comments

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

Connecting to the remote service and validating the ssl cert.
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.

Where does your local DNS cache gets the record from ? Unless you can verify the information is legit it actually aggravates the problem. Now any MITM can poison your computer for the duration of the cache TTL whereas before they had to maintain the MITM or poison upstream for the same effect.