Re: Primary also being secondary

[marka@isc.org]

> I'm not sure if this belongs here, but I am sure you'll redirect :-).
> 
> This is real life, although I've modified some names to make it a
> little less confusing.  SW is bind-8.1.2.
> 
> : chalmers.se.              IN NS ns1.chalmers.se.                 pri
> :                           IN NS ns2.chalmers.se.                 sec
> :
> : hemmet.s-hem.chalmers.se. IN NS glutus.hemmet.s-hem.chalmers.se. pri
> :                           IN NS ns1.chalmers.se.                 sec
> 
> So, this is a delegated subdomain, where the upper domain's primary is
> also secondary for the delegated domain. Straight forward. Between
> them they share NS(hemmet.s-hem.chalmers.se) info, and this is where
> my report/question comes in.
> 
> Now, the people at hemmet.s-hem.chalmers.se screwed up their NS info:
> 
> : hemmet.s-hem.chalmers.se.
> :     IN NS glutus.hemmet.s-hem.chalmers.se.hemmet.s-hem.chalmers.se.
> :     IN NS ns1.chalmers.se.hemmet.s-hem.chalmers.se.
> 
> We've all done this at least once...
> 
> ns1.chalmers.se noticed the higher version number and fetched the zone,
> including the erronous NS(hemmet.s-hem.chalmers.se). This did *not*
> change the SOA version for zone chalmers.se.
> 
> Later on, there were other changes made to zone chalmers.se and the
> SOA version was changed. ns2.chalmers.se noticed and fetched the data;
> and now got the erronous NS(hemmet.s-hem.chalmers.se) - the erronous
> one that ns1.chalmers.se fetched some time ago and obviously installed
> in zone chalmers.se.
> 
> The people at hemmet.s-hem.chalmers.se soon found the error, fixed it
> and incremented their SOA version. ns1.chalmers.se fetched again, with
> correct info this time. However, SOA(chalmers.se) was not updated, so
> ns2.chalmers.se did NOT fetch any new data; instead it was stuck with
> the erronous NS(hemmet.s-hem.chalmers.se) info.
> 
> My conclusion is that, at least in bind-8.1.2, the delegated zone's
> version of the shared NS-info gets precedence over the delegating
> zone's version (the config file). Although I can see cases where this
> may be good and useful I'm not sure this is generally so - the case
> above is one counter example. I've not found anything in the RFCs
> that tell which one is considered "correct" or even "better".

	When you delegate authority you delegate the authority for ALL
	record types (NXT is a special case).  The child zone is always
	correct.

	NOTE: If the rules about which copy of the NS rrset were reversed
	you can create the same error by switching the roles around.

> 
> My 1c is that this is wrong and that the data sent to a secondary,
> i.e. AXFR, should be the original data from the config file(s), and
> not be a "copy of a copy".
> 
> 	Gunnar Lindberg
> 
	BIND 8 is limited in that there is one big database.  BIND 9 will
	have seperate databases for each zone.  AXFR (and IXFR) will send
	the NS list from the parent zone but answer from the child zone
	when queried for the NS RRset.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org