[dns-operations] data origin for the additional section [Re: Concerns regarding the ICANN/IANA DNS vulnerability checker]

[Peter Koch]

Mohsen,

> Recalling that the NS's in question are for actually within the domain
> queried for (so they cannot be ignored by caches), and assuming that

you're saying that the address information won't be ignored because
the ns[1234].nic.example. servers' name is within the example TLD?

> Is the behavior I mentioned deemed a bad one?

For most TLDs this would practically not matter much, because they are
"delegation centric".  Except for direct NS queries, which are not supposed
to happen during normal resolution, there is almost no reason for the
TLD NS RRSet (and thus the corresponding addresses) to be added to the
response.  Referrals will have the delegation in the authority section and
NXDOMAIN responses will only carry the SOA RR in the authority section
(TYPE 2 response in RFC 2308).  This is different with DNSSEC, where
DNSKEY queries for the zone apex will result in positive responses,
usually with an NS RRSet in the authority section.

> serve in additional section. However, this may lead to other issues
> such as glue inconsistency across zone cuts (this issue was recently

There is no reason for placing glue records into example. for
ns[1234].nic.example unless these servers are also authoritative
for nic.example (or any other domain under example. if that TLD applies
a wide glue policy).  [Strictly speaking, if example. and nic.example.
are served by the same set of name servers, there isn't any need for glue,
either, but getting that exception into the policy might be challenging.]

-Peter