Interesting subdomain question.

[Mark_Andrews at iengines.com]

> In article <199911240007.LAA27920 at bsdi.dv.isc.org>,
>  <Mark_Andrews at iengines.com> wrote:
> >	Actually this is a bug but one that is impossible to correct
> >	in BIND 4/8 due to internal data structures.
> >
> >	BIND 9 will correct this in that the zone transfer will
> >	contain the contents of z.com with nothing mixed in from the
> >	child zones.
> >
> >	As to why it works.  The NS records from the parent zone are
> >	thrown away when the server serves both the parent and child
> >	zones.  Because of this we cannot see the difference between
> >	a parent zone that had NS records at bottom of zone and one
> >	that didn't.  Outgoing zone transfers just use the NS RRset
> >	from the child zone.
> 
> Why is this considered to be a bug?
	
	Because when you perform a axfr/ixfr you don't get what you put
	in.

> Isn't the child domain zone file considered "more authoritative" than
> the parent zone file?
	
	The server will still hand out the child's NS rrset in ordinary
	(non ixfr/axfr) answers in preference to those from the parent.

> Aren't "stub"
> zones a special case of this, where the parent server does a zone transfer
> and just incorporates the NS records into the parent zone?

	Stub zones are a way for the parent server to hand out the
	delegation information learnt from the child without
	requiring the entire child zone.

	BIND 9 will hand out referrals for glue records it holds
	(NS/A/A6/AAAA) rather than giving them as answers directly. 
	The referrals will contain the answers (glue) in the authority
	and additional sections.  This gets the RRsets tagged with the
	correct creadability.  It will also hand out learnt answers
	in preference to glue.

> 
> About the only reason I can think of to do this is that there are many DNS
> administrators who don't realize they need to add explicit NS records into
> their zones.  They use MS DNS, which automatically creates an NS record for
> the master server itself, and don't bother adding more.  Our servers are
> authoritative for the reverse zone for our netblock, and slaves for the
> customer's reverse zone that's delegated to them.  We list all the servers
> in the delegation records, but I frequently have to remind customers that
> they must also add them to their zones or they won't be effective.

	It is a continual education exercise isn't it.

	Mark
> 
> -- 
> Barry Margolin, barmar at bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the grou
> p.
> 
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com