But what is common for you will usually be cached already in your own server as well, so most requests will still be cache hits--and all those hits avoid the ~

But what is common for you will usually be cached already in your own server as well, so most requests will still be cache hits--and all those hits avoid the ~ 20 to 100 ms round trip to the internet. Take news.ycombinator.com, for example: The A record has a TTL of 300 seconds. So, after the first visit, which probably will take a bit longer than asking Google/CF, for every request in the next five minutes, you will have a reduced lookup latency. Then, after five minutes, the next lookup will go out to the authoritative server. But mind you that the NS records for ycombinator.com have a TTL of two days, so those are still cached, and the refresh is indeed a single request to the authoritative server--which more often than not takes about as long as a cache hit from the recursive Google/CF resolvers (it's also one round trip to the internet ...). And then, there is stuff like BIND's prefetch mechanism which will start the refresh of an expiring record when it sees a query for that record shortly before its expiry: That query is answered immediately from the cache, and a refresh is started in the background, so that the refreshed record should arrive in the cache before the old version expires ... thus completely eliminating the lookup latency for often-used records. Though you might need to tune it to trigger earlier for your personal use than in the default configuration ...