accelerated TTL decrement

[Ahmon Dancy]

Now that I think about it, the 5% acceleration on the TTL decrement
really doesn't matter.  This scenario will always occur once the TTL
hits zero when one of the nameservers isn't up.

>> 
>> Now... that someone does a zillion lookups for the address of
>> ns2.domain.com.  It gets answers back because named has them cached.
>> But, according to Barry, since the address of ns2.domain.com was
>> originally returned as a glue record from the root nameservers, the
>> TTL is decreased by 5% during each lookup.  This means that the TTL
>> will head to zero very quickly.  Soon, the 'A' record for
>> ns2.domain.com will expire and be removed from the cache.  This leaves
>> named in the following situation:
>> 
>> It still has the 'NS' records for domain.com:
>>   NS ns1.domain.com
>>   NS ns2.domain.com
>> It still knows the address of (inaccessible) ns1.domain.com.  
>> 
>> 
>> Now the user does one final lookup for www.domain.com.  We'll assume
>> that the old entry for www.domain.com has expired and is not in the
>> cache anymore.  Now named needs to talk to one of the nameservers for
>> domain.com.  It knows who they are.. but it only has the address for
>> ns1.. .so it tries to contact ns1... which doesn't answer.  It never
>> tries to contact ns2 which is happily waiting to provide information.
>> 
>> At this point named needs to be restarted in order to get information
>> for domain.com.
>> 
>> This leads me back to my quick question above.  If the purposes of
>> secondary nameservers is to provide fault tolerance (which is what I
>> always felt they were mainly for), this behavior of named works
>> against that goal.