Re: [dnsext] Possible DNSSECbis clarifications
Michael Graff <mgraff@isc.org> Mon, 28 March 2011 14:51 UTC
Return-Path: <mgraff@isc.org>
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 629833A6A1E for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 07:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 L+CAsWEcmy6Z for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 07:51:45 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 7FB743A6989 for <dnsext@ietf.org>; Mon, 28 Mar 2011 07:51:45 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 0A26DC941E for <dnsext@ietf.org>; Mon, 28 Mar 2011 14:53:20 +0000 (UTC) (envelope-from mgraff@isc.org)
Received: from dhcp-5329.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:61e:64ff:fef5:5604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E7FE6216C33 for <dnsext@ietf.org>; Mon, 28 Mar 2011 14:53:18 +0000 (UTC) (envelope-from mgraff@isc.org)
Message-ID: <4D90A0D4.2080002@isc.org>
Date: Mon, 28 Mar 2011 16:53:08 +0200
From: Michael Graff <mgraff@isc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: dnsext@ietf.org
References: <4D9042DA.30002@ogud.com> <00a701cbed28$64d1b1d0$2e751570$@lampo@eurid.eu> <EBB9E54E-15F1-46B0-81CB-4B2C7B47D598@hopcount.ca> <018401cbed48$0b8a6ac0$229f4040$@lampo@eurid.eu> <22FD4CD1-4EFB-412A-A307-485DEBE815CE@hopcount.ca> <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu>
In-Reply-To: <01a901cbed53$e744b7e0$b5ce27a0$@lampo@eurid.eu>
X-Enigmail-Version: 1.1.1
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 14:51:47 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 4:19 PM, Marc Lampo wrote: > But then, how to link a RRSIG(SOA) with *its* SOA ? They are the same SOA in an AXFR. Identical in every way. In an IXFR, the delta change IS the data as well, with each section delimited by an SOA. So, you have the removed RRSIG(SOA) in the delete section and the new RRSIG(SIG) in the add section. There is no guarantee on record order in an AXFR other than the delimiters. You could receive: example.com SOA example.com A asdasd.example.com A example.com MX asdasd.example.com AAAA example.com SOA IMHO, the first SOA could be followed by its RRSIG(SOA), but this is not required. The final SOA cannot have any data after it, as per AXFR spec. Don't treat the RRSIG as special; for an AXFR or IXFR they are just records. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNkKDUAAoJEDRzoY2A7tzbahEH/R7oxD0WzxQmgH3pSwh3b3Fn MpZ0ItbN9bpTVUmYwTpXHFYYw9IZRIaymOnxIRIvnsWKEZEktfYdZp1dnlCBfexQ u/RUHC4tPYkAAHHVZj2Iecape0bFRBMoSku4Rd7BgJKGPTDWRY86ufqEK0f8bRR7 rW2W0EcjganyMe+4fK2tnUBCwhIefmrnL9MNHoWEYLcKDnzK7d5ZzArg30d7iARw vy/gYQUYwIX45aaPijOs3siDEBp1vOMeS5MsYASA0qu71bDNIPebNayt0bXs3fhH EirpaMDrJtwpEPe0P/WGhJx/mX724euXoQbRAi2PKlMiXwe3xu0vphle+CnxfyQ= =3uvB -----END PGP SIGNATURE-----
- Re: [dnsext] Possible DNSSECbis clarifications Marc Lampo
- [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 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