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

From: Klaus Malorny <[email-masked]>
Date: Thu, 19 May 2011 10:04:11 +0200

Hi,

it would be great if any of the experts here could do me a favour and help me on 
the following question, as I did not find a satisfying answer on my research in 
the relevant RFCs.

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.

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.

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

Regards,

Klaus

---

From: Florian Weimer <[email-masked]>
Date: Thu, 19 May 2011 10:57:06 +0000

* Klaus Malorny:

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

You should send unusual records only in response to DO=1 queries.
Otherwise, you risk that the client cannot interpret them.  (The risk
with DNSSEC-capable clients is still there, of course, but it seems
less.)

There is no precedent for copying NS records to the additional section,
AFAIK.  Given the amount of work put into reducing response sizes, it's
also unlikely that such a feature would be a win for all parties
involved.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 19 May 2011 15:53:20 +0200

> with DNSSEC-capable clients is still there, of course, but it seems

That statement makes me wonder how robust the resolvers are ;-)

> also unlikely that such a feature would be a win for all parties

Yes, but the idea was that if the NS records in the authority section are of any 
use (while only the use as alternative name servers comes to my mind), then the 
additional NS records would allow to omit an extra query to the tld. name servers.

While in the meantime I more or less managed to cope with the complexity of 
authoritative name servers (esp. in conjunction with DNSSEC), resolvers are 
still somewhat secret and magical to me. So I probably will stay away from that 
idea for the sake of stability and reliability.

Regards,

Klaus

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 May 2011 10:10:10 -0400

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

>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 +1-571-434-5468

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