Re: [dnsext] NS/NSEC/NSEC3 records in the Additional section

[Edward Lewis <[e-mail]>]

At 10:04 +0200 5/19/11, Klaus Malorny wrote:

>I am wondering whether the Additional section may contain NS records, and,
>if so, whether the respective NSEC/NSEC3 record to prove the non-existence
>of the DS record for this delegation shall be placed also in the
>Additional section or in the Authority section instead.

I cannot think of any situation in which an NS set would appear in 
the additional section of a response (specifically a message with 
OPCODE=query, QR=1).

NS records will appear in the answer section if and only if they type 
NS matches the QTYPE (NS, ANY, AXFR, IXFR if I'm not mistaken).

NS records will appear in the authority section for a number of 
reasons, one is to direct the next iterative query to another set of 
servers (a referral), to establish the source as the authority for 
what is in the question and answer sections, and maybe some other 
situation I'm not thinking of right now.

Presence or (proof of) absence of DS records, when germane, will 
appear in the authority section.  (Again, unless DS matches the 
QTYPE.)

>If I have the following zone,
>
>tld.                SOA ...
>tld.                NS     ns1.sld.tld.
>
>sld.tld.            NS     ns2.other.
>sld.tld.            NS     ns3.other.
>
>I think it would make sense to include the NS records of sld.tld. (and DS
>records if signed) in the Additional section if the NS records of tld.
>are included in the Authority section, as this information is available
>anyway and should be useful for the resolver. This is, however, contrary
>to the behaviour of BIND, which I consider as a reference.

Responding to that suggestion begins with this question - what is the 
query you have in mind?  If the response would include the NS set of 
tld. in the authority, then the message means that the answer lies in 
the tld zone, therefore, there's no need to go to the sld.tld. 
servers.

If you are thinking that a query like "shinkuro.us/IN/DS" directed to 
an authoritative server should have the DS in the answer, the NS of 
US in the authority and NS of shinkuro.us in the additional, there 
are a two reasons not to do this.  One is that the shinkuro.us 
records here have a very low trustworthy rating (see RFC 2181 for 
that).  Two, it is unlikely a validator would ask for the DS record 
unless the data "below" it that is being validated was already in 
hand - hence the NS set is already in hand (or perhaps TTL'd out).

When we were designing DNSSEC we were more generous in including 
extra information until we discovered that often times the extra 
records (in additional) were unneeded because the cache already had 
them and hence represented unneeded bytes in the message.  In the 
90's our concern was bandwidth, now is it is message size 
(fragmentation, firewalls that don't know EDNS0, etc.).

>Also, in the case that tld. is signed and sld.tld. not, the question is
>whether the respective NSEC/NSEC3 record shall be also in the Additional
>section. RFCs 403x and 5155 mention only the Authority section, but
>the described case does not occur at all in these RFCs (unless I missed it).

DNSSEC is supposed to be consumed in data flows internal to the DNS. 
As such, DS records and NSEC/NSEC3 records and others would never be 
part of other helpful records that are what is put into the 
additional.  E.g., the A/AAAA record matching the RDATA names of MX 
records are counter examples.  DNSSEC isn't meant to be helpful to 
the answer, it is meant to make sure the answer meets certain 
security properties.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?