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

[Mohsen Souissi]

Thanks Peter for your prompt answer. My answer and comments below inline.

 On 19 Aug, Peter Koch wrote:
 | 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?

==> Short answer: yes.

Long answer: yes, unless the rdns has already the aa in its cache
and/or it has received different data form a longer match in example
TLD (deeper in the tree), for instance if NS's of nic.example are
different from NS's of example.

Is that correct?

 | > 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.

==> Yes, I like this explanation. For instance, "fr" is
"delagation-only" I tend to think then that a.nic.fr is not "unsafe"
(recallig F.W. original comment on that, not specifically for fr, but
more generally for TLDs NS's behaving that way) :-)

 | > 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.]

==> I agree, there is no need (that reminds me of
http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-03). Yet,
in practice this seems to be done quite often (maybe just by
courtesy).

Thanks again,

Mohsen.