Cache strangeness

[Robert Weber]

--------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 
> > > 
> > > > 
> > > > This is not a function that we wish to support, can this be turned off?
> > > 
> > > 	Do you really know the impact of turning this off?
> > > 
> > > 	The root servers are currently spend the vast majority of
> > > 	there time (> 90%) repeatedly answering negative queries
> > > 	that could have been avoided if the clients supported
> > > 	negative caching.
> > > 
> > > 	Yes, you can tune it but don't turn it off.  You are doing
> > > 	a disservice to everyone if you do so.
> > > 
> > 
> > Ok, I'm starting to see the rational behind this now.  I guess the major
> > problem in my case was that the domain in question had such a high ttl that
> > this problem came up.  Normally with 3 hours I doubt that this would be an
> > issue, but the question I have now, is why did it appear to cache longer
> > than the default?
>  
> 	You said that the master for the reverse died.  The slave
> 	continued to hand NXDOMAIN until it was able to update the
> 	zone from the master.
> 
> 	Mark
> 

Yes, but I reloaded my nameserver and things started working even though
their primary is still down.  It almost seems like bind tried harder the
first time and got the correct info from one of their other nameservers.  I
guess I could just tack this up to the "not my problem" board, but I'd like
to know if there is a good way to work around it in the future.


- --
						Robert Weber
<!-- |**|begin egp html banner/			UnixOps/ITS
> Thank you for registering There is no catch.	University of Colorado  
> this e-mail blah blah confidential and yadda yadda legally privileged   

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPcmx4TcQbVPfkR0TEQKMbQCfbXviT9jpvyWXW6UPDWJJCWpSJfAAoKMv
GZmLTTExj/XH23/qtD49cMPl
=ywkc
-----END PGP SIGNATURE-----