Option to eliminate cross-zone glue in authoritative server responses
Description
BIND in all currently-supported versions will return any cross-zone or out-of zone glue that it happens to have in its possession in its referral responses to clients.
There are three scenarios when it might do this:
a) The zone administrators added the out-of-zone glue to the zone when adding a delegation NS RRset and associated A/AAAA RRs. This out-of-zone glue is loaded by BIND anyway, isn't returned if queried-for directly (obviously - the server isn't auth for the zone), but it will be returned as glue in referrals to delegated zones whose out-of-zone RRs "need" it.
b) The authoritative server is serving multiple zones (e.g. Verisign serve both .com and .net) and thus quite often the cross-zone glue is available authoritatively.
c) The authoritative server is delegating e.g. bar.com and foo.com where some of foo.com's servers are in the bar.com domain and are also authoritative for bar.com, therefore are included (legitimately) as bar.com's glue.
There are situations where returning out-of-zone glue is undesirable (see references below).
The scenario a) can be mitigated by the zone administrator manually (remove the out-of-zone glue from the zone).
Scenarios b) and c) are currently unavoidable - named returns the out of zone glue regardless.
Request
In its simplest form, just stop adding out-of-zone glue to referral query responses for delegated subdomains.
There is a more complex discussion however. The DNS RFCs currently don't forbid the following scenario:
foo.com.au. IN NS ns1.bar.com.
bar.com.au. IN NS ns1.foo.com.
ns1.foo.com. IN A 1.2.3.4
ns1.bar.com. IN A 1.2.3.5Because each of the delegated subdomains is dependent on the other one, the glue is required. And that's just a very simple delegation dependency chain - it's possible to make more complicated ones.
So either we need a mechanism for signalling (on a per zone basis) that out-of-zone glue if available should be served. Or, we need to clarify whether or not this scenarios is permissible in the DNS (RFC update - feed the camel..?)
References: https://support.isc.org/Ticket/Display.html?id=13434 https://indico.dns-oarc.net/event/29/contributions/660/attachments/630/1013/2018-10-OARC-Verisign-TLDs.pdf