Re: [dnsext] Possible DNSSECbis clarifications

Antoin Verschuren <antoin.verschuren@sidn.nl> Mon, 28 March 2011 09:33 UTC

Return-Path: <Antoin.Verschuren@sidn.nl>
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 4A6A43A6A36 for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 02:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.504
X-Spam-Level:
X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4]
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 mB2U-D17t9Ys for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 02:33:07 -0700 (PDT)
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id 7E3EC3A6A3E for <dnsext@ietf.org>; Mon, 28 Mar 2011 02:32:59 -0700 (PDT)
Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p2S9YaLn025505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for <dnsext@ietf.org>; Mon, 28 Mar 2011 11:34:36 +0200
Received: from [192.168.192.222] (192.168.192.222) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Mon, 28 Mar 2011 11:34:35 +0200
Message-ID: <4D90564A.8010001@sidn.nl>
Date: Mon, 28 Mar 2011 11:35:06 +0200
From: Antoin Verschuren <antoin.verschuren@sidn.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: dnsext@ietf.org
References: <4D9042DA.30002@ogud.com> <20110328092847.02E5BD97013@drugs.dv.isc.org>
In-Reply-To: <20110328092847.02E5BD97013@drugs.dv.isc.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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:33:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nice thought:
Should an SOA record be signed anyway ?
The SOA is only a signaling record, and the result is never going to be
used by any application.
The header (including the ad bit) is also not signed, and the DNSKEY
record does not need to be signed with a ZSK.


On 28-03-11 11:28, Mark Andrews wrote:
> 
> In message <4D9042DA.30002@ogud.com>, Olafur Gudmundsson writes:
>>
>> 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.
> 
> All records with the exception of the SOA should appear once but
> multiple should be handled. This is covered in AXFR clarify. The
> record should be between the SOA records.  The SOA records bookend
> the zone transfer.
>  
>> 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.
> 
> IXFR contains sets of deltas which consist of the *records* that
> have changed in the zone.  Assuming a properly signed zone you
> will have the final SOA, the starting SOA, RRSIGs of the starting SOA + any
> other changes, the next (possibly final) SOA, the RRSIGs of the SOA
> that apply to that and any other changes,  possibly the next delta,
> .... then the final SOA.
> 
>> Is there need put this information in dnssec-bis (the answer to the AXFR 
>> question may update RFC5936) and in IXFR-bis document ?
> 
> No.
>  
>> 	Olafur
>>
>> _______________________________________________
>> dnsext mailing list
>> dnsext@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsext


- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:antoin.verschuren@sidn.nl  xmpp:antoin@jabber.sidn.nl
http://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNkFY/AAoJEDqHrM883Agn8BoH/0b2dC+h7H6rMJaYqv7NabEv
jC61tUM41XCBN9K71H1ZTT0JUkMGjpLdqbSrqRNoGQSPqRR9ZlUg+pSe44v1t6X4
0ZvyPtXfVA/9AESwmzS+HztOwShsvhYyp2fWvlAkFcnP/8mNHkHCuuzAi8LFubx+
8QdE1bqRSeiByTn4GZ1vaSRTxt2aKcHM5CJ6VrgERTCjt6hEd7xxrIqUqxOiR4+Q
ecRbX5D+i0x3GEal1W4Xgqa5jLwQfaNN1Euog4ftNWBIpFa+e+/pgjXTbDVGz8Zv
1hSzXdyguIAsICu0WKdEd8J11TNj5XYKitO2JXXjUKAQmsFN75s6ETTQIYZv4Ps=
=SEF+
-----END PGP SIGNATURE-----