Greg Freemyer said the following on 01/03/2014 10:20 AM:
On Fri, Jan 3, 2014 at 10:13 AM, James Knott
wrote: Anton Aylward wrote:
From my POV having an old or tiny box dedicated to DNS with a couple of gigs of memory[1] with a -ing cache and a -ing long timeout will 'outperform' all of the above after a couple of days, provided I don't turn it off at night.
Actually, the time to live value in the returned DNS reply will limit any caching. I just did one test for Yahoo and it showed 34 seconds. Another one showed 3 min 2 sec, so upstream caches will return a varying TTL depending on when they obtained the record. Those times are nowhere near "overnight".
I had no idea TTLs were so short these days. When I was admin'ing DNS 15+ years ago, a week was a very common TTL (time-to-live).
+1. My Albitz&Liu talks of a default of 85400 seconds, which is 24 hours which *IS* overnight! Why should a site have such short TTL? The only justification I can think of is that they are implementing Round Robin DNS that way. Think about it: how often are major sites such as yahoo, Google and the big news agencies, government departments and so forth going to change their network addresses for soemthing radically differnet? But organizations such as Yahoo will have huge server farms and DO want to do load balancing. Balancing by hardware internally still requires the single external address, and that's not what they want. A test for yahoo using DIG returns ;; QUESTION SECTION: ;yahoo.com. IN A ;; ANSWER SECTION: yahoo.com. 1800 IN A 206.190.36.45 yahoo.com. 1800 IN A 98.139.183.24 yahoo.com. 1800 IN A 98.138.253.109 ;; AUTHORITY SECTION: yahoo.com. 75033 IN NS ns6.yahoo.com. yahoo.com. 75033 IN NS ns5.yahoo.com. yahoo.com. 75033 IN NS ns2.yahoo.com. yahoo.com. 75033 IN NS ns4.yahoo.com. yahoo.com. 75033 IN NS ns1.yahoo.com. yahoo.com. 75033 IN NS ns3.yahoo.com. yahoo.com. 75033 IN NS ns8.yahoo.com. ;; ADDITIONAL SECTION: ns1.yahoo.com. 74847 IN A 68.180.131.16 ns2.yahoo.com. 74847 IN A 68.142.255.16 ns3.yahoo.com. 74847 IN A 203.84.221.53 ns4.yahoo.com. 74847 IN A 98.138.11.157 ns5.yahoo.com. 74847 IN A 119.160.247.124 ns6.yahoo.com. 75036 IN A 202.43.223.170 ns8.yahoo.com. 75037 IN A 202.165.104.22 1800 sec = 30 min 75033 sec = 20.8425 hours 74847 sec = 20.790833 hours So the name servers at least will stay in my cache overnight :-) Google.com is even more interesting and dramatic ;; ANSWER SECTION: google.com. 300 IN A 74.125.226.128 google.com. 300 IN A 74.125.226.132 google.com. 300 IN A 74.125.226.129 google.com. 300 IN A 74.125.226.134 google.com. 300 IN A 74.125.226.131 google.com. 300 IN A 74.125.226.136 google.com. 300 IN A 74.125.226.142 google.com. 300 IN A 74.125.226.130 google.com. 300 IN A 74.125.226.133 google.com. 300 IN A 74.125.226.135 google.com. 300 IN A 74.125.226.137 ;; AUTHORITY SECTION: google.com. 74246 IN NS ns1.google.com. google.com. 74246 IN NS ns4.google.com. google.com. 74246 IN NS ns2.google.com. google.com. 74246 IN NS ns3.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 247046 IN A 216.239.32.10 ns2.google.com. 247046 IN A 216.239.34.10 ns3.google.com. 247046 IN A 216.239.36.10 ns4.google.com. 247046 IN A 216.239.38.10 300 sec = 5 min 74246 sec = 20.623889 hours 247046 sec = 68.623889 hours At this point I suggest a re-read of how the resolver works when presented with a number of "answers" such as the above. I have no doubt that google.com is returning a value that matches "geographically". My resolver sees all of "74.125.226.x" as being 'electrically' equidistant so it going to do a RR on them. The likelyhood that I'd hit google.com a second time in 5 minutes is about 50/50. The first time I hit a google page there are well over 100 additional references back to google for ... stuff. If there wasn't caching, be it DNS or be in in my browser, it would take ages for the page to load. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org