Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment

Paul Vixie <vixie@isc.org> Fri, 18 February 2011 16:26 UTC

Return-Path: <vixie@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 9977D3A6C8D for <dnsext@core3.amsl.com>; Fri, 18 Feb 2011 08:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 mMIk7EJDrI0K for <dnsext@core3.amsl.com>; Fri, 18 Feb 2011 08:26:42 -0800 (PST)
Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id 8C8753A6CA1 for <dnsext@ietf.org>; Fri, 18 Feb 2011 08:26:42 -0800 (PST)
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 736AEA1059 for <dnsext@ietf.org>; Fri, 18 Feb 2011 16:27:13 +0000 (UTC) (envelope-from vixie@isc.org)
From: Paul Vixie <vixie@isc.org>
To: dnsext@ietf.org
In-Reply-To: Your message of "Fri, 18 Feb 2011 14:36:53 GMT." <20110218143653.GC84482@bikeshed.isc.org>
References: <4D5B5E81.1050602@necom830.hpcl.titech.ac.jp> <20110216073338.7251.qmail@joyce.lan> <F21692535B1A478F95D9E3AA048E8037@ics.forth.gr> <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org>
X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22)
Date: Fri, 18 Feb 2011 16:27:13 +0000
Message-ID: <10710.1298046433@nsa.vix.com>
Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment
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, 18 Feb 2011 16:26:43 -0000

> Date: Fri, 18 Feb 2011 14:36:53 +0000
> From: Suzanne Woolf <woolf@isc.org>
> ...
> I *think* Andrew's text above says no, we can't reasonably help
> registry operators if we leave applications with the same problem they
> have now (knowing for themselves that string $x needs to map to string
> $y). But rather than argue with something he may not have actually
> said, I'm looking for further comments on this point.

registry operators (and those who govern) asked about name sameness and
it's fair to answer them with a cost-benefit analysis, such as:

"1. dns provides aliases but these are application-visible and many
   protocols forbid their use, for example MX -> alias -> {A|AAAA}
   so these may not be suitable for your proposed use.

"2. services are name-aware, so any dns sameness whether based on
   existing alias technology or on some imaginable new technology
   would still require service config changes, for example to postfix
   and apache configs on all servers which were going to become
   multinamed.  even if we add new dns technology to support some
   kind of automation in that area, it will still require a global
   upgrade of server side technology, and the failure mode for clients
   contacting non-upgraded servers could be unpredictable/unsettling.
   so, adding new sameness will have a high cost and a long tail.

"3. some existing dns data elements are harmonized around the idea of
   a "canonical name" (for example, {A|AAAA} and PTR) and applications
   often enforce this.  the dns and all applications would have to be
   changed to either remove assumptions about canonical names, or to
   change the definition of a canonical name from a scalar to a vector.
   this has the same high costs and long tail as described for #2 above.

"please choose a tradeoff and give us appropriate marching orders.  thanks."