Re: [dnsext] does making names the same NEED protocol changes at all?

Michael Graff <mgraff@isc.org> Fri, 25 February 2011 18:12 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 B0B643A67F4 for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 10:12:18 -0800 (PST)
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 lYl+qHxO5xyk for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 10:12:17 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 7BA6B3A67F2 for <dnsext@ietf.org>; Fri, 25 Feb 2011 10:12:17 -0800 (PST)
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.ams1.isc.org (Postfix) with ESMTPS id B6E6D5F98B6 for <dnsext@ietf.org>; Fri, 25 Feb 2011 18:12:55 +0000 (UTC) (envelope-from mgraff@isc.org)
Received: from bigmac.home.flame.org (unknown [IPv6:2001:470:b8d7:13:21d:4fff:fe47:6790]) (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 99F89216C33 for <dnsext@ietf.org>; Fri, 25 Feb 2011 18:12:53 +0000 (UTC) (envelope-from mgraff@isc.org)
Message-ID: <4D67F124.7080801@isc.org>
Date: Fri, 25 Feb 2011 12:12:52 -0600
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.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <8657EF4A-A08D-46E5-8917-553AE377CAD8@ICSI.Berkeley.EDU> <AANLkTikHm62x=+xWpSRyERw2cB31yZZhVkTT-90dgFjk@mail.gmail.com> <39EBBA76-22F1-4935-9300-B0078B229793@ICSI.Berkeley.EDU> <5A100E65-FB09-4556-AA5A-BF9FE0468DDA@ICSI.Berkeley.EDU> <AANLkTikECGtJm5WyDnX=s8zTERu89qLbFDebf8R1y4Pa@mail.gmail.com> <6AD400292B2C771C7FE70E8F@Ximines.local> <20110225143043.GB74938@shinkuro.com> <AANLkTimfhfsj65Vec61-_Q18+RoC1144Zf1E2bQhvt18@mail.gmail.com> <alpine.LSU.2.00.1102251653290.5244@hermes-1.csi.cam.ac.uk> <AANLkTinvqqGTGPeMXUcAv5iY1KGn_=LwfGr3debWo_GE@mail.gmail.com> <20110225174623.GP74938@shinkuro.com> <alpine.LSU.2.00.1102251802350.5244@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1102251802350.5244@hermes-1.csi.cam.ac.uk>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] does making names the same NEED protocol changes at all?
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: Fri, 25 Feb 2011 18:12:18 -0000

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

On 2011-02-25 12:06 PM, Tony Finch wrote:

> So far as I can tell the main question is, what is the question and is
> BNAME the answer?

I'd ask this differently.  "Is BNAME the only answer?" or perhaps "the
BEST answer?"

No matter how I travel down the path, from reading all the email to
date, I still maintain in my own thoughts that BNAME is one possible
solution, but that the cost of pushing a protocol change down to the
clients is painful in light of DNSSEC deployment and the breakage that
BNAME will create there.

The solution I've heard is that we roll the DNSSEC algorithm numbers.
This is a non-scalable solution and means we have other, bigger issues
to contend with.  We can't continue to use DNSSEC algorithm numbers as a
DNS version number like we did to some extent for NSEC3.

No matter how I approach this problem, I see the solution in my mind.
This solution is that no protocol changes are needed for this, and that
it all comes down to an improvement in the configuration and publication
of delegation points, and zone file contents.

- --Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1n8SQACgkQLdqv0r6eD6aYygCdHuV06JOVx1zrckqDSGKEZ8Ok
OvsAoItxcAzwAQc1VZxujFb0F2ElmBRh
=aQ99
-----END PGP SIGNATURE-----