Problems with bind9 caching too long

[Mark Andrews]

> 
> --ByWDhVrfOLxO82cA
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Mar 15, 2005 at 08:00:00AM +1100, Mark Andrews wrote:
> >=20
> > > On Tue, Mar 15, 2005 at 05:49:12AM +1100, Mark Andrews wrote:
> > > >=20
> > > > 	Upgrade aludra.usc.edu.  It clearly is not running an up to dat
> e
> > > > 	version of named which has had its cache detuned to handle this
> > > > 	sort of mismanagement by the zone administator.
> > > >=20
> > > > 	The old servers for nakos.net should have been configured to se
> rve
> > > > 	the new zone content then decommissioned once all the old refer
> ences
> > > > 	to the them have expires or been decommissioned immediately rat
> her
> > > > 	than being abandoned.  The first of these allows for a orderly
> > > > 	transition from one set of servers to the next.
> > > >=20
> > > > 1429.   [bug]           Prevent the cache getting locked to old serve=
> rs.
> > > Aha! I suspected it wasn't the desired behavior. Thanks!
> >=20
> > 	If we could trust the administators of zones to do the correct
> > 	thing we would remove it.  The "fix" puts additional load on
> > 	the parent servers.
> 
> While I understand the load concern, it seems like the proper behavior. The
> delegation from the parent servers /has/ a TTL, that TTL specifically means
> (unless I greatly misunderstand the RFC) "this record shouldn't be trusted
> after X"... so after X, that record should be refreshed.

	Well the parent is NOT authoritative for the NS RRset at the zone
	cut.  The child is.  The NS RRset from the parent is replaced with
	that learnt from the child zone.  Normally these should be the same.

	When you add a nameserver you in order
	* configure it as a nameserver
	* add it to the NS RRset for the zone
	* add it to the parent's NS RRset.

	When you remove a nameserver you in order
	* remove the NS record from the zone
	* remove the NS record from the parent
	* when the TTL on both the NS RRsets in the child and parent zones
	  expire decomission it.

	At all times the nameservers for the zone serve the *same* zone
	content modulo differences while the zone is waiting to be transfered.

	The zone administators in this case deliberately caused there to
	be different zone content on two sets of servers.  They deliberately
	allowed stale information to be returned hoping that caches would
	somehow learn the correct information despite continually allowing
	stale information to be returned.
 
> Depending on people to the right thing is certainly nice to the parent
> servers, however, as far as I can tell, it's noncompliant - you're trusting=
>  a
> record after it's expired.

	The cache continued to trust a source that it had been told was
	authoritative for the zone.
 
> Or am I missing something?
> 
> --=20
> Phil Dibowitz
> Systems Architect and Administrator
> Enterprise Infrastructure / ISD / USC
> UCC 174 - 213-821-5427
> 
> 
> --ByWDhVrfOLxO82cA
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQFCNf357lkZ1Iyv898RAqVoAKDck07fcel09uP/duT9/uzhwVXBAQCghUew
> dMvfm3Kpr58ko44FEg5V/pY=
> =mB/O
> -----END PGP SIGNATURE-----
> 
> --ByWDhVrfOLxO82cA--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org