Problems with bind9 caching too long

[Mark Andrews]

> 
> --S/ewHz4E8nbJzUsO
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Mar 15, 2005 at 09:00:01AM +1100, Mark Andrews wrote:
> >=20
> > 	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.
> >=20
> > 	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.
> >=20
> > 	At all times the nameservers for the zone serve the *same* zone
> > 	content modulo differences while the zone is waiting to be transfered.
> >=20
> > 	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.
> 
> 
> I understand that, and it works if I control the subdomain as well as the r=
> oot
> domain.... but it doesn't follow with the idea of *delegation* (though
> maybe it's not supposed to...). For example, at USC we delegate www.usc.edu=
>  to
> UltraDNS, as a subdomain. We control all of our own DNS, except www.usc.edu
> which we delegate to them for their sitebacker service.
> 
> Lets say tomorrow I convince management that's a bad idea (or someone else
> does), and I need to revoke that delegation. I change those NS records (that
> provide the delegation) to A records.
> 
> But UltraDNS doesn't clean up their zone for 3 months - let's say they have=
>  a
> 3-month removal policy. Yeah, sure, UltraDNS would be doing things wrong, b=
> ut
> it doesn't matter, they should have no ability to hurt my zones once I choo=
> se
> not to delegate to them anymore - or so I'd like to think...
> 
> Or - lets say we'd done this with a newer company, or ultradns when they we=
> re
> new... but then they started doing questionable things... so we pull their
> delegation. Except that despite _owning_ usc.edu, I can't exert any control
> over www.usc.edu once I've delegated it - even to revoke that delegation. T=
> his
> doesn't follow, at least in my mind.
> 
> But looking at the RFC, they don't seem really clear on this part...
> 
> Just my comments/thoughts/2 cents. I'm not saying you're wrong...

	Then you have a contract issue that you should be enforcing
	as you would any other contract issue.
 
	Note this is all theoretical as we have no intention of
	removing the code.

> Phil Dibowitz
> Systems Architect and Administrator
> Enterprise Infrastructure / ISD / USC
> UCC 174 - 213-821-5427
> 
> 
> --S/ewHz4E8nbJzUsO
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQFCNkc17lkZ1Iyv898RArdeAJ9XkBX1BzuJPbbEZNUIJisaMr6l7ACdHAqo
> thDmrD1Tv30jZEi27earLrU=
> =jvzB
> -----END PGP SIGNATURE-----
> 
> --S/ewHz4E8nbJzUsO--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org