Problems with bind9 caching too long
Mark_Andrews at isc.org
Tue Mar 15 02:42:05 UTC 2005
> 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:
> > 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.
> I understand that, and it works if I control the subdomain as well as the r=
> 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=
> 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=
> 3-month removal policy. Yeah, sure, UltraDNS would be doing things wrong, b=
> it doesn't matter, they should have no ability to hurt my zones once I choo=
> 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=
> 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=
> 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
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> -----END PGP SIGNATURE-----
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users