> 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: ;; ANSWER SECTION: net. 71243 IN NS g.gtld-servers.net. net. 71243 IN NS h.gtld-servers.net. net. 71243 IN NS i.gtld-servers.net. [...] ;; ADDITIONAL SECTION: a.gtld-servers.net. 70962 IN A 192.5.6.30 a.gtld-servers.net. 70962 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 70962 IN A 192.33.14.30 b.gtld-servers.net. 70962 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 70962 IN A 192.26.92.30 At the same time, gtld-servers.net. is child zone of net.: ;; ANSWER SECTION: 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. -netch-
