> I'll start by saying there may be some nuance of the RFC that I'm not
> grasping, and I'm sure Mark or someone will pipe up if I get this wrong...
> that said...
> I belive your problem is that, once you have a zone cut in place (a
> delegation to a subzone) then the parent zone is no longer authoritative
> for anything below that cut. In your example, the parent zone
> (example.org) delegates authority for hq.example.org, and so it is not
> authoritative for anything at or below that domain.. which means that it
> can't give an authoritative answer for ns1.hq.example.org.

Yes, this is exactly what I suppose as problem source. BTW, setting
"noaaonly" as query flag doesn't change the response for 9.4.2 - it still
responds with empty additional section.

I missed to tell there is real example of such situation working in world DNS:

net. 71243 IN NS g.gtld-servers.net.
net. 71243 IN NS h.gtld-servers.net.
net. 71243 IN NS i.gtld-servers.net.
a.gtld-servers.net. 70962 IN A
a.gtld-servers.net. 70962 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 70962 IN A
b.gtld-servers.net. 70962 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 70962 IN A

At the same time, gtld-servers.net. is child zone of net.:

gtld-servers.net. 70913 IN NS h2.nstld.com.
gtld-servers.net. 70913 IN NS l2.nstld.com.
gtld-servers.net. 70913 IN NS a2.nstld.com.

Some root servers (e.g. f.root-servers.net, c.root-servers.net) has
the same version as mine (9.4.2) and still respond with full list of
glue records. So, it is possible for these versions, isn't it?

> It can provide glue for ns.hq.example.org because that is necessary for the
> delegation to work, but that glue is actually passed as non-authoritative
> data.
> If you really want to use a host in the subzone as the name server for the
> parent zone, then you should remove the ns1.hq.example.org host from the
> example.org zone. I don't recommend this, however.. even if it's
> technically permissible, it seems likely this could cause some problems
> higher up the delegation chain. My recommendation would be to make sure
> that the authoritative servers for the example.com zone are within that
> zone, not within some subzone.

This is already planned, but there are administrative problems with such
delegation and I'm investigating how we can postpone this change.