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-
