[FX.php List] [OFF] Question about DNS TTL (time-to-live)

Tue Oct 11 06:23:11 MDT 2011

Bob

I suspect that this is where William and I will diverge in our thinking.

In my understanding of how DNS TTL functions, the only TTL which matters is that set on the authoritative name server, i.e. the one which you manage. If you set that to (say) 300 seconds (5 min) when someone attempts to access one of the domain names, their DNS server will look in cache and see if it has an IP address for that domain name. If it does, then it will give that IP address. If not, it will (should) go looking for an authoritative name server (i.e yours) to retrieve an IP address. It will hold that for as long as the TTL you set lives on.

Now, if in the past you have had a very high TTL (say 7 days), then the remote DNS server will hold onto that IP address until seven days after that DNS server fetched the IP address from your DNS server… so… if you've been switching things back and forth, and at some point had a high TTL then I would recommend not making any changes until however long that TTL was after you changed it to something very low (like 300)… i.e. if it was seven days, then wait to make any changes until seven days after you changed it to 300.

William's correct that it's technically possible for this to be extended if DNS servers incorrectly cache (and redistribute) non-authoritative DNS records. This might happen if, say, a visitor to your site asks their DNS server for an IP address for a domain name. That DNS server requests the IP from the ISP DNS server. It may have a valid record in cache, which has a TTL of (say) 7 days. It should respond with the IP address from cache, and a say at the time that it is non-authoritative. The client DNS server should then pass on the valid IP address, but should not cache it. If it does cache that IP address, then it will have a TTL of seven days… now if it received that record on day 6.9 of seven, it will incorrectly hold on to that record for an additional seven days… you can see how this could rapidly expand…

So… best bet, set your TTL really low, as soon as possible, and leave it that way for as long as possible before you make changes to servers…

Cheers
Steve

> Guys,
> 
> Thanks for the clarification; that's almost what I figured. 
> 
> So here's my question, and you'll understand why I'm asking:
> 
> Last Saturday night I moved my server network to a new set of T1 lines (4 of them bonded), only to find that half of them didn't work. I tried everything to fix it, but to make matters worse, I couldn't see the *missing* servers in Remote Desktop, so I had to connect a monitor to each of them in order to see its settings.
> 
> After 15 hours, during which I moved everything BACK to the old T1 lines, a tech (the 5th I'd spoken to) told me that the subnet mask I had been sent was not the right one. ARGHHHHH.
> 
> So Satuday night I'm going to do this all again.
> 
> Is there ANY way for me to force other servers to come back to my DNS servers for a refresh, faster than whatever their own settings dictate? I'm thinking the answer is no, but one can always hope.
> 
> Thanks,
> 
> Bob Patin
> Longterm Solutions LLC
> bob at longtermsolutions.com
> 615-333-6858
> http://www.longtermsolutions.com
> FileMaker 9, 10 & 11 Certified Developer
> Member of FileMaker Business Alliance and FileMaker TechNet
> --
> Twitter: bobpatin
> Google+: http://www.longtermsolutions.com/plus
> AIM: longterm1954
> iChat: bobpatin
> --
> Expert FileMaker Consulting 
> FileMaker Hosting for all versions of FileMaker
> 
> On Oct 11, 2011, at 12:40 AM, Malcolm Fitzgerald wrote:
> 
>> Steady on Bob,
>> 
>> Adjusting your TTL settings did not make you boss of the internet. TTL is simply the equivalent of a "Best Before" date on your milk carton.
>> 
>> What you have done is said to the other servers that come knocking, "Here is the information you need. Take it and don't come back for 5 minutes". Which is as good as saying you will warranty the reliability of your DNS settings for 5 mins, after that you don't guarantee the results. 
>> 
>> I suspect that a good number of other DNS servers haven't ever knocked on your door and those that have done so run on a longer schedule TTL themselves so they may just decide to keep to their own timetable.
>> 
>> Malcolm
>> 
>> 
>> On 10/10/2011, at 9:31 AM, Bob Patin wrote:
>> 
>>> My understanding is that time-to-live in DNS settings determines how long DNS servers will cache a domain name's record before going back to the name servers to check the IP address.
>>> 
>>> I set a DNS TTL to 300 seconds for a domain name, but it didn't update worldwide in 5 minutes. In fact, it's been 6 hours and I'm still waiting.
>>> 
>>> From what I've read, it was my understanding that the TTL setting tells all the upstream DNS servers how long to cache the domain info; am I missing something?
>>> 
>>> Thanks,
>>> 
>>> Bob Patin
>>> Longterm Solutions LLC
>>> P.O. Box 3408
>>> Brentwood, TN 37024
>>> bob at longtermsolutions.com
>>> 615-333-6858
>>> http://www.longtermsolutions.com
>>> iChat: bobpatin
>>> AIM: longterm1954
>>> Twitter: bobpatin
>>> Google+: http://www.longtermsolutions.com/plus
>>> --
>>> FileMaker 9, 10 & 11 Certified Developer
>>> Member of FileMaker Business Alliance and FileMaker TechNet
>>> --
>>> FileMaker hosting and consulting for all versions of FileMaker
>>> PHP • Full email services • Free DNS hosting • Colocation • Consulting_______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>> 
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list

Steve Winter
+44 777 852 4776
steve at bluecrocodile.co.nz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20111011/6207fe96/attachment.html