In message <>, 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 "" with glue record:
> (in file of
> @ NS ns1.hq
> ns1.hq IN A
> But is subzone with own NSes and zone description:
> (in file of
> hq NS ns.hq
> ns.hq IN A
> (in file of
> @ NS ns
> ns1 IN A
> ns IN A
> Former versions accepted this and replied to query "-t ns"
> 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: