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

Klaus Malorny <Klaus.Malorny@knipp.de> Thu, 19 May 2011 08:04 UTC

Return-Path: <Klaus.Malorny@knipp.de>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4277DE068C for <dnsext@ietfa.amsl.com>; Thu, 19 May 2011 01:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fuwojTyO0eC for <dnsext@ietfa.amsl.com>; Thu, 19 May 2011 01:04:26 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3c-eth0-0.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA48E067C for <dnsext@ietf.org>; Thu, 19 May 2011 01:04:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 5D75733; Thu, 19 May 2011 10:04:18 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id gkRRXPKGjhtm; Thu, 19 May 2011 10:04:12 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id CB05732; Thu, 19 May 2011 10:04:12 +0200 (MESZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id p4J84C4L006233; Thu, 19 May 2011 10:04:12 +0200 (MESZ)
Message-ID: <4DD4CEFB.3050702@knipp.de>
Date: Thu, 19 May 2011 10:04:11 +0200
From: Klaus Malorny <Klaus.Malorny@knipp.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110518 Thunderbird/3.3a4pre
MIME-Version: 1.0
To: dnsext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [dnsext] NS/NSEC/NSEC3 records in the Additional section
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2011 08:04:27 -0000

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