Problems with bind9 caching too long

Kevin Darcy kcd at daimlerchrysler.com
Sat Mar 12 00:37:56 UTC 2005


No, that's not a BIND bug. You've left the old version of the zone 
running on ns1.pbi.net and ns2.pbi.net, and they'll keep on giving out 
the stale NS records in response to queries. Other caching nameservers 
such as aludra.usc.edu which had the NS records cached from prior to the 
switchover will keep on using those nameservers to resolve nakos.net 
names, and therefore keep seeing regurgitations of the stale NS records, 
and the cycle will repeat until those caching nameservers are restarted 
or those particular records in their caches expire or are purged out, or 
until the pbi.net nameservers stop answering with stale NS records for 
the zone (i.e. the zone is removed from them or is replaced by a more 
up-to-date version).

                                                                         
                                                   - Kevin

Phil Dibowitz wrote:

>Folks,
>I've been having problems with Bind 9 caching too long. I finally have a nice
>concrete example, and I can't find a good reason, so I'm coming here.
>
>nakos.net's whois record was changed over a month ago to change is NS servers
>from ns1.pbi.net. and ns2.pbi.net. to ns1.iswest.net. and ns2.iswest.net.
>
>[phil at metallica tmp]$ dig @aludra.usc.edu nakos.net
>
>; <<>> DiG 9.2.4rc6 <<>> @aludra.usc.edu nakos.net
>;; global options:  printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58363
>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;nakos.net.                     IN      A
>
>;; ANSWER SECTION:
>nakos.net.              6709    IN      A       207.104.230.50
>
>;; AUTHORITY SECTION:
>nakos.net.              172309  IN      NS      ns1.pbi.net.
>nakos.net.              172309  IN      NS      ns2.pbi.net.
>
>;; Query time: 1 msec
>;; SERVER: 128.125.5.231#53(aludra.usc.edu)
>;; WHEN: Fri Mar 11 11:42:19 2005
>;; MSG SIZE  rcvd: 83
>
>[phil at metallica tmp]$ 
>
>
>But if I do a +trace, I get the proper information.
>
>...
>net.                    172800  IN      NS      H.GTLD-SERVERS.net.
>net.                    172800  IN      NS      I.GTLD-SERVERS.net.
>net.                    172800  IN      NS      J.GTLD-SERVERS.net.
>;; Received 512 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 10 ms
>
>nakos.net.              172800  IN      NS      ns1.iswest.net.
>nakos.net.              172800  IN      NS      ns2.iswest.net.
>;; Received 102 bytes from 192.52.178.30#53(K.GTLD-SERVERS.net) in 144 ms
>
>nakos.net.              28800   IN      A       207.178.244.194
>nakos.net.              28800   IN      NS      ns1.iswest.net.
>nakos.net.              28800   IN      NS      ns2.iswest.net.
>;; Received 118 bytes from 207.178.128.20#53(ns1.iswest.net) in 4 ms
>
>
>The TTL for nakos.net from the root server is 48 hours, and this was changed
>over a month ago (or so I'm told - I don't control this domain, but I've had
>many similar reports recently).
>
>
>I don't see why the cache is living so long....
>
>
>Any help would be appreciated. Thanks.
>
>  
>




More information about the bind-users mailing list