In message <20081023155927.GV92276@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@isc.org