[dnsext] Possible DNSSECbis clarifications

Olafur Gudmundsson <ogud@ogud.com> Mon, 28 March 2011 08:10 UTC

Return-Path: <ogud@ogud.com>
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 E69A73A6893 for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 01:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.419
X-Spam-Level:
X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 rnXfw4Yx3b+f for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 01:10:40 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id CDF533A68E4 for <dnsext@ietf.org>; Mon, 28 Mar 2011 01:10:39 -0700 (PDT)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2S8CFiG048000 for <dnsext@ietf.org>; Mon, 28 Mar 2011 04:12:16 -0400 (EDT) (envelope-from ogud@ogud.com)
Message-ID: <4D9042DA.30002@ogud.com>
Date: Mon, 28 Mar 2011 04:12:10 -0400
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: dnsext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Subject: [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 08:10:41 -0000

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