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

Andrew Sullivan <ajs@shinkuro.com> Fri, 18 February 2011 22:29 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AA53A6D43; Fri, 18 Feb 2011 14:29:23 -0800 (PST)
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 335E43A6AAE for <dnsext@core3.amsl.com>; Fri, 18 Feb 2011 14:29:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level:
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 9JH36jbJdndS for <dnsext@core3.amsl.com>; Fri, 18 Feb 2011 14:29:18 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3D37C3A6DFD for <dnsext@ietf.org>; Fri, 18 Feb 2011 14:29:18 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 16EE61ECB420 for <dnsext@ietf.org>; Fri, 18 Feb 2011 22:29:52 +0000 (UTC)
Date: Fri, 18 Feb 2011 17:29:50 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsext@ietf.org
Message-ID: <20110218222950.GL74065@shinkuro.com>
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> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4D5EEE09.4080405@dougbarton.us>
User-Agent: Mutt/1.5.18 (2008-05-17)
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Fri, Feb 18, 2011 at 02:09:13PM -0800, Doug Barton wrote:

> Two comments ... First, just because we provide one or more solutions  
> doesn't mean that the registrants of the preferred names will chose to  
> use them. What generally happens with variants now is that either the  
> registry assigns them to the registrant by default, or they are given  
> the option to register them at an additional cost. At that point (for  
> the most part) they also have the option of whether to delegate the  
> variants or not. So IDN registrants are already dealing with these  
> questions, we're just giving them a different set of tools with which to  
> deal with them.

Well, yes and no.  Consider one of the favoured strategies in this
area: BNAME.

The reason some people are unhappy with DNAME is because a DNAME at
the parent side causes problems for (for instance) using email at the
DNAMEd domain.  The natural use of BNAME, then, would be on the parent
side (never mind whether it will work for email anyway, for now).

Now, today, people tend not to put DNAME on the parent side because it
doesn't redirect the name itself.  But if we create this tool, it
allows the parent side of the delegation effectively to _require_ that
two names both be active; or at least, to force the child side of the
delegation to handle the traffic from both "spellings". 

So if you want to run your mailserver at example.com, and your parent
decides that you ought also to handle otherexample.com, you're going
to get that traffic even if you don't want it.  And this, of course,
carries up the tree.

That's a tool with potentially significant changes to the operational
environment in which we have lived so far, and I don't want us to
forget it.

> harder (or impossible) to solve. But I think that we have to be careful  
> not to throw our hands up too early, particularly before we've even  
> tried to engage the people who are already dealing with these same  
> issues we're discussing in theory.

Yes.  I would keep at least a studied silence if I were throwing up my
hands.  I'm not trying to be argumentative for its own sake.  I just
want us to expose as many things as early as possible, while we're
still working out what the problems are.  I'd hate to learn all of
this in another year.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext