3 ms·

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 I

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.

andrewstuart2 12y ago
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.
peterwwillis 12y ago
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.

andrewstuart2 12y ago

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.

peterwwillis 12y ago

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.