Re: [dnsext] Possible DNSSECbis clarifications
"Marc Lampo" <marc.lampo@eurid.eu> Mon, 28 March 2011 09:11 UTC
Return-Path: <marc.lampo@eurid.eu>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0393A690A for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 02:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUmft7c5o9tS for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 02:11:34 -0700 (PDT)
Received: from cuda.eurid.eu (mx.eurid.eu [77.67.53.136]) by core3.amsl.com (Postfix) with ESMTP id 497603A683D for <dnsext@ietf.org>; Mon, 28 Mar 2011 02:11:32 -0700 (PDT)
X-ASG-Debug-ID: 1301303583-46c953290001-uIE7UK
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id jZHwciYOTHwPyo2z; Mon, 28 Mar 2011 11:13:03 +0200 (CEST)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id C8150E407A; Mon, 28 Mar 2011 11:07:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GyowWM3WRoS; Mon, 28 Mar 2011 11:07:41 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id B53BFE4050; Mon, 28 Mar 2011 11:07:41 +0200 (CEST)
From: Marc Lampo <marc.lampo@eurid.eu>
To: 'Olafur Gudmundsson' <ogud@ogud.com>, dnsext@ietf.org
References: <4D9042DA.30002@ogud.com>
In-Reply-To: <4D9042DA.30002@ogud.com>
Date: Mon, 28 Mar 2011 11:07:41 +0200
X-ASG-Orig-Subj: RE: [dnsext] Possible DNSSECbis clarifications
Message-ID: <00a701cbed28$64d1b1d0$2e751570$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: AcvtH9X7xkzgbJN5S2CDk9IFp0cCAAAB5daw
Content-Language: en-za
X-Originating-IP: [172.20.5.39]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1301303583
X-Barracuda-URL: http://77.67.53.136:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Subject: Re: [dnsext] Possible DNSSECbis clarifications
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 28 Mar 2011 09:11:36 -0000
Hello, Only a feedback on Q2) # times the RRSIG(SOA) should appear in zone transfer. I think "b) both times". Motivation. While the second SOA might serve as an indicator of "end of zone transfer", it also indicates that the transferred zone was not changed (at sender side) during the time it took to send the zone file. Because, if it did change (at sender side) the serial number in the final SOA would change. Consequently, since there is a possibility that the second SOA might be different from the first SOA, it's RRSIG will be different as well : so, each SOA should be accompanied by its (own) RRSIG. Perhaps this brings an additional challenge : ? how to link a RRSIG(SOA) with the proper SOA record ? --> make it mandatory to have the RRSIG(SOA) immediately follow the SOA record it signs ? Kind regards, Marc Lampo -----Original Message----- From: Olafur Gudmundsson [mailto:ogud@ogud.com] Sent: 28 March 2011 10:12 AM To: dnsext@ietf.org Subject: [dnsext] Possible DNSSECbis clarifications Dear colleagues, The following is a result of a side conversation on the interpretation of RFC403x with number of DNS colleagues. Any mistakes in the questions are mine. The questions are: 1) What is the valid order of signed RRsets? 2) How many times SHOULD/MUST RRSIG(SOA) appear in an AXFR? 3) What RRSIG(SOA)'s MUST appear on the wire in an IXFR transaction? Q1) A: In RFC403x there is no order requirement on an signed RRset thus implementations should be ready to handle any combination Following Examples should be treated as the same RRset RR1 RR3 RRSIG2 RR2 RRSIG1 RR2 RR3 RR1 RR3 RRSIG1 RR2 RRSIG1 RRSIG2 RRSIG2 RR1 Q2) In AXFR the SOA record is used as a marker record to signal the beginning of a zone transfer and the end of the zone transfer. The open question is how many times should RRSIG(SOA) appear in the AXFR stream ? a) Only once b) Both times c) Does not matter both are ok. if the answer is a) then the question is when should it appear, i) in the beginning after the SOA ii) at any time in the AXFR iii) just before the final one. iv) after the final one. Q3) In IXFR there are multiple SOA records used as maker both on the overall transaction and on each delta. The questions here are: Which RRSIG(SOA) i.e. for each serial number, are needed ? a) All of them once b) all of them each time SOA appears b) only the final one, all the other ones are immaterial (open question is how often and where) c) The first and last one and each only once, the first one is needed to identify what to delete from the zone, the final one is what is going to be in the zone after the IXFR is applied. Is there need put this information in dnssec-bis (the answer to the AXFR question may update RFC5936) and in IXFR-bis document ? Olafur
- [dnsext] Possible DNSSECbis clarifications Olafur Gudmundsson
- Re: [dnsext] Possible DNSSECbis clarifications Masataka Ohta
- Re: [dnsext] Possible DNSSECbis clarifications George Barwood
- Re: [dnsext] Possible DNSSECbis clarifications Marc Lampo
- Re: [dnsext] Possible DNSSECbis clarifications Mark Andrews
- Re: [dnsext] Possible DNSSECbis clarifications Antoin Verschuren
- Re: [dnsext] Possible DNSSECbis clarifications Joe Abley
- Re: [dnsext] Possible DNSSECbis clarifications Joe Abley
- Re: [dnsext] Possible DNSSECbis clarifications Marc Lampo
- Re: [dnsext] Possible DNSSECbis clarifications Joe Abley
- Re: [dnsext] Possible DNSSECbis clarifications Michael Graff
- Re: [dnsext] Possible DNSSECbis clarifications Marc Lampo
- Re: [dnsext] Possible DNSSECbis clarifications Michael Graff
- Re: [dnsext] Possible DNSSECbis clarifications Joe Abley
- Re: [dnsext] Possible DNSSECbis clarifications Marc Lampo
- Re: [dnsext] Possible DNSSECbis clarifications Miek Gieben
- Re: [dnsext] Possible DNSSECbis clarifications Mark Andrews
- Re: [dnsext] Possible DNSSECbis clarifications Michael Graff