accelerated TTL decrement

Nate Duehr nate at natetech.com
Fri Apr 13 07:22:09 UTC 2001


Not sure if this is related but...

On one of my nameservers, every few [three to be exact] days I lose the
ability to find any records in the wellogix.com zone.

I think this may be similar because the gtld-server names do not match
the names of the NS records they actually have in their zonefile.

BIND 8.2.3-REL... of course.  :)

Here's some digs... anyone see anything blatently wrong with this?

This isn't my zone, but we monitor some equipment for them and we do it
by FQDN in the monitoring system... it's not real happy when the
nameserver stops responding for the zone, obviously... :-)

 dig @a.gtld-servers.net wellogix.com soa 

 ; <<>> DiG 9.1.0 <<>> @a.gtld-servers.net wellogix.com soa
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57199
 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

 ;; QUESTION SECTION:
 ;wellogix.com.			IN	SOA

 ;; AUTHORITY SECTION:
 wellogix.com.		172800	IN	NS	NS2.wellogix.com.
 wellogix.com.		172800	IN	NS	NS3.wellogix.com.

 ;; ADDITIONAL SECTION:
 NS2.wellogix.com.	172800	IN	A	63.224.68.250
 NS3.wellogix.com.	172800	IN	A	208.146.252.243

 ;; Query time: 116 msec
 ;; SERVER: 192.5.6.30#53(a.gtld-servers.net)
 ;; WHEN: Fri Apr 13 01:16:17 2001
 ;; MSG SIZE  rcvd: 98
 

 dig @telluride.natetech.com wellogix.com soa

 ; <<>> DiG 9.1.0 <<>> @telluride.natetech.com wellogix.com soa
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25837
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

 ;; QUESTION SECTION:
 ;wellogix.com.			IN	SOA

 ;; ANSWER SECTION:
 wellogix.com.		2512	IN	SOA	a.ns.wellogix.com.
 hostmaster.wellogix.com. 986999119 16384 2048 1048576 2560

 ;; AUTHORITY SECTION:
 wellogix.com.		259152	IN	NS	a.ns.wellogix.com.
 wellogix.com.		259152	IN	NS	b.ns.wellogix.com.

 ;; ADDITIONAL SECTION:
 a.ns.wellogix.com.	259152	IN	A	208.146.252.243
 b.ns.wellogix.com.	259152	IN	A	63.224.68.250

 ;; Query time: 27 msec
 ;; SERVER: 216.233.182.148#53(telluride.natetech.com)
 ;; WHEN: Fri Apr 13 01:15:26 2001
 ;; MSG SIZE  rcvd: 144
 
Do they need to change something here?  It *looks* like it should work
if you follow their A records, but it keeps disappearing on my
nameserver.

On Thu, Apr 12, 2001 at 04:16:15PM -0700, Ahmon Dancy wrote:
> 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.
> 

-- 
Nate Duehr <nate at natetech.com>

GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61 77C5 7ECE C1D2
Public Key available upon request, or at wwwkeys.pgp.net and others.


More information about the bind-users mailing list