Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

Matthew Pounsett <matt@conundrum.com> Wed, 09 March 2011 15:47 UTC

Return-Path: <matt@conundrum.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 77A0D3A6A1A for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 07:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 8D5G2ydy3qaz for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 07:47:24 -0800 (PST)
Received: from bawls.conundrum.com (unknown [216.235.8.92]) by core3.amsl.com (Postfix) with ESMTP id 9FBF13A696D for <dnsext@ietf.org>; Wed, 9 Mar 2011 07:47:24 -0800 (PST)
Received: from [216.235.10.34] ([216.235.10.34]) (authenticated bits=0) by bawls.conundrum.com (8.14.3/8.14.3) with ESMTP id p29Fl659000271; Wed, 9 Mar 2011 10:47:08 -0500 (EST) (envelope-from matt@conundrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Matthew Pounsett <matt@conundrum.com>
In-Reply-To: <20110309133017.GA19809@odin.mars.sol>
Date: Wed, 9 Mar 2011 10:47:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1189F82-8266-4984-97FF-980E4BA57DBF@conundrum.com>
References: <C99C3502.72B1%roy@nominet.org.uk> <alpine.LSU.2.00.1103082030190.5244@hermes-1.csi.cam.ac.uk> <20110309133017.GA19809@odin.mars.sol>
To: Scott Schmit <i.grok@comcast.net>
X-Mailer: Apple Mail (2.1082)
Cc: dnsext@ietf.org
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
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: Wed, 09 Mar 2011 15:47:25 -0000

On 2011/03/09, at 08:30, Scott Schmit wrote:

> I'm inclined to agree with this, but even if it's decided that the
> DNSKEY RRs aren't sufficient, why not just use DS on the client side? I
> see that RFC 3658 forbids it, but I'm not sure I understand why.

In addition to the reasons given by others for not reworking a decision already made, I'll note a difference you've overlooked in your post.  The NS set in the parent zone is non-authoritative data which the NS set at the apex of the child zone overwrites in a cache.  The DS set in the parent zone is authoritative, and the child zone may not also claim authority for those records.