Problems with bind9 caching too long

[Mark Andrews]

> 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.
> 
> -- 
> Phil Dibowitz
> Systems Architect and Administrator
> Enterprise Infrastructure / ISD / USC
> UCC 174 - 213-821-5427
> 

	Upgrade aludra.usc.edu.  It clearly is not running an up to date
	version of named which has had its cache detuned to handle this
	sort of mismanagement by the zone administator.

	The old servers for nakos.net should have been configured to serve
	the new zone content then decommissioned once all the old references
	to the them have expires or been decommissioned immediately rather
	than being abandoned.  The first of these allows for a orderly
	transition from one set of servers to the next.

1429.   [bug]           Prevent the cache getting locked to old servers.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org