Hacker News Reader

Comment by kybernetyk | Hacker News Reader

If DNS latency is such a limiting factor wouldn't it be better if you ran a caching DNS server on your local network?

Unbound is particularly good for this because you can configure it to populate your cache with responses before you even ask for them (kind of).

Essentially if you do a DNS lookup and the result is in the cache, it returns the cached result straight away. It will then check to see if the response is due to expire from the cache soon, and if it is, then it will refetch it at that point. So if you visit a site regularly, it should always be in your cache.

How useful is prepopulating a DNS cache on a home network? How often do you expect OP is going to reboot the caching dns box?

DNS records contain an expiry, unbound will go update the record so that the expiration never reaches 0.

This can be very handy even on a home network, as you avoid the whole WAN trip to fetch records for sites you visit often, such as Google and others.

That would be mostly redundant as the user's machine will do a lot of internal caching.

Re: the root comment of this thread, it's usually optimal to use your ISP's DNS resolvers as they're right there on your same ISP network which means your requests don't have to go out to the broader internet and are thus faster (99% of the time anyway if the hostname requested is cached on those resolvers). Using a more external resolver like Google or what-have-you means your requests have to leave your local network, leave the ISP network, and travel some distance across the internet to wherever that resolver resides.

Edit: IP anycast can allow for many resolvers to respond to one IP (such as 8.8.8.8) so it's not as if the request will have to travel the world to get an answer, but it's still generally faster to key off a resolver you know is within your same ISP.

It would be mostly redundant if the user has only one machine on the local network. Otherwise it's a pretty decisive win, as you now have the results cached locally and that's useful for all devices on the LAN.

The OS DNS cache is usually crap. Caching on your own network often results in significantly lower latency than your ISP. This is due to several factors:

1. You can use multiple name servers on multiple networks and generally the first to respond wins. 2. The local caching resolver can be configured to be more aggressive, lookup more efficiently in parallel and keep more records for an extended period of time. 3. Not all DNS requests are cached by the OS, but by providing your own caching resolver, you can cache all requests used by any application on your network. 4. You can provide your own ranges and domains for internal hosts so that resolving names for private IPs reduces resolution time in local apps. 5. You can control negative caching and TTLs. 6. You can prevent unscrupulous DNS providers from redirecting NX lookups to internal [ad-supported] services. 7. You can actually implement proper DNSSEC validating resolution, if you care about that sort of thing. 8. DNSRBLs can speed up resolution of pages by ignoring advertisement and malware domains.

Of course. That's what I'm running (configured to use the ISPs DNS if it doesn't have valid data in its cache).

But the first request of the OS within the TTL of the record in question is likely still much faster served by a DNS server used by more people than just me because the server might already have answered a query before me.

Reply on news.ycombinator.com