glue records in child zone

[Valentin Nechayev]

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).

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)?

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-