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

Andrew Sullivan <ajs@shinkuro.com> Wed, 16 February 2011 17:39 UTC

Return-Path: <ajs@shinkuro.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 B18433A6EC4 for <dnsext@core3.amsl.com>; Wed, 16 Feb 2011 09:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.432
X-Spam-Level:
X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 dUTb95bbWTmi for <dnsext@core3.amsl.com>; Wed, 16 Feb 2011 09:39:46 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D8BBA3A6E6B for <dnsext@ietf.org>; Wed, 16 Feb 2011 09:39:45 -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 0C7E11ECB420 for <dnsext@ietf.org>; Wed, 16 Feb 2011 17:40:13 +0000 (UTC)
Date: Wed, 16 Feb 2011 12:40:12 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsext@ietf.org
Message-ID: <20110216174011.GZ96213@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk>
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>
X-List-Received-Date: Wed, 16 Feb 2011 17:39:47 -0000

On Wed, Feb 16, 2011 at 05:23:33PM +0000, Lawrence Conroy wrote:

> Almost all registries will have rules on bundling and mapping.

I just want to be clear what you mean by "registries" there.  Remember
that, formally, every zone cut comes with a registry responsible for
it.

If what you mean is "big TLD registries", then I'll concede the point.
But we're not the DNS Extensions for TLDs WG.  We're responsible for
the protocol all the way down.

I fully agree that we're not required to solve _every_ case: we can't.
But we do have to solve enough of a problem to really make a
difference.

This is why the SMTP and web server issues are such a big deal.  If we
solve the problem that you only have to maintain one tree in the DNS,
and everything else "just works", that is a completely meaningless
victory if you nevertheless have to maintain all your SMTP and web
servers by hand and keep them up to date about the aliases.  The work
to keep the DNS in sync here is trivial compared to everything else.

> If I can count the number of "shadows" with my fingers, that seems to ME to be a tad
> different from millions of potential domains.

So how many shadows is the right number?  The final sigma case is
trivial. But the tonos case is not; it requires a large number of
alternatives.  We heard "tens of alternatives".  But of course, that's
tens of alternatives _in every level_.  If you have four levels deep
and 10 each, then that's 40 possible alternatives for one FQDN.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.