glue records in child zone

Mark Andrews Mark_Andrews at isc.org
Thu Oct 23 21:59:20 UTC 2008


In message <20081023155927.GV92276 at netch.kiev.ua>, Valentin Nechayev writes:
> Hi,
> this question seems to be almost FAQ, but I can't find answer to it.:(
> We have got strange reaction of newer BIND versions to glue records
> which point into child zone.
> 
> Consider domain "example.org" with glue record:
> 
> (in file of example.org)
> @               NS      ns1.hq
> ns1.hq          IN A    10.0.0.1
> 
> But hq.example.org is subzone with own NSes and zone description:
> 
> (in file of example.org)
> hq              NS      ns.hq
> ns.hq           IN A    10.0.0.2
> 
> (in file of hq.example.org)
> @               NS      ns
> ns1             IN A    10.0.0.1
> ns              IN A    10.0.0.2
> 
> Former versions accepted this and replied to query "-t ns example.org"
> with glue record in additional section. But named 9.4.2 rejects to answer
> with it totally (as result, additional section is empty). Named 9.3.5
> replied with appropriate content, but tcpdump shows that it resolved
> all glues using some external source (which is totally inappropriate
> in this situation because it asked parent zone NS instead of using its
> own authoritative source in the zone file).

	Except it isn't authoritative.  It is GLUE.

	When you query for a zone's NS RRset there is no need to
	return any additional records.

	The time when additional records are necessary is when there
	is a referral.  At all other time additional records are
	completely optional.
 
> The result is "clear" in sense that no other zone data or cache can affect
> it (recursion is disabled and this named instance carries only target zone
> and root hint list).
> 
> Here, my questions are:
> 
> 1. Is it result of official policy to reject any glue record which resides
> in another zone?
> 
> I know that named attempts to reject any glue record from another zone, but
> I supposed it should check only that the glue record is child of the zone
> in question, but not whether there is intermediate child zone.
> 
> 2. If this isn't policy decision, how can we fix it for fresh BIND versions
> (at least 9.4 and 9.5)?

	There is nothing to fix.  Minimizing the amount of glue
	floating around for possible promotion to answer is a good
	thing for the global health of the DNS.
 
> P.S.1. I know that there can be conflict between contents of the parent zone
> and the child zone, but this isn't our case (records are equal).
> 
> P.S.2. I can show real example, if it is nesessary to detect the problem
> origin.
> 
> 
> -netch-
> 
-- 
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 mailing list