IETF Logo Mail Archive

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

Ted Hardie <ted.ietf@gmail.com> Fri, 25 February 2011 21:07 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 B11B23A6A40; Fri, 25 Feb 2011 13:07:01 -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 6FBF33A6A40 for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 13:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.644
X-Spam-Level:
X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Seng+KRKkQ4O for <dnsext@core3.amsl.com>; Fri, 25 Feb 2011 13:06:59 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 398D03A6A4C for <dnsext@ietf.org>; Fri, 25 Feb 2011 13:06:59 -0800 (PST)
Received: by qyk7 with SMTP id 7so1630283qyk.10 for <dnsext@ietf.org>; Fri, 25 Feb 2011 13:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XDophiYpAnnxEkphtX1eKh99nUK87ByEgyEV19whlKo=; b=ETQleatcyB0f6q/2FhzutFl5EAcbNeI8aW7nob0NjvFklfUoLXxbygrw/AJOXCWmGC 2KOk1RiqyK+o8H8Zhqw3OgElXFff3gtdZmOgHPTHopaUcFGEdl9nM1Hz5y+5cbuJWz72 EVFgRL2gnM/yrJh/XN+kZ4MhDE9GBeLqepwvk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aZnUZZGCYbO1HawFSwZzn5w4A7O7ikTV1GRLrEiaVc+fKloXko4jShJe56M+0/NtiP FqBv9L/TMhwuC4elJNUE6z5zE1R1g68vPVvVjVj1nOBATtPyjh+9rK9T64XuYId6fp5x UPSLwcoSysPOLZU4U88bLQtL9WpL5OUIwxdIQ=
MIME-Version: 1.0
Received: by 10.229.86.7 with SMTP id q7mr2197120qcl.262.1298668072071; Fri, 25 Feb 2011 13:07:52 -0800 (PST)
Received: by 10.229.98.210 with HTTP; Fri, 25 Feb 2011 13:07:51 -0800 (PST)
In-Reply-To: <20110225192058.GU74938@shinkuro.com>
References: <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> <F87B152F-4941-4B6D-8DC1-4F7D60198DA7@icsi.berkeley.edu> <20110225184838.GS74938@shinkuro.com> <A6CD428C-2D90-44DE-B623-26E80828677B@icsi.berkeley.edu> <20110225192058.GU74938@shinkuro.com>
Date: Fri, 25 Feb 2011 13:07:51 -0800
Message-ID: <AANLkTikxgViZKKNNSKvR_J0RUp0_dYG8+6AiPpk=9Awj@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Andrew Sullivan <ajs@shinkuro.com>
Cc: dnsext@ietf.org
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Fri, Feb 25, 2011 at 11:20 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:

> But as you can see, we can discuss all of that without recourse to the
> specifics of the language, since the actual issue is that a zone
> administrator knows a label to label mapping of the items.
>
>

Dearly as I would love to agree with you, I fear I cannot.  The actual
issue is that humans interpolate well and canonicalize badly. We're
exploring how to mesh the untidy reality that colour/color, 中國／中国， and
a host of other examples are "the same" to those humans but not to an
exact much look-up protocol.

There are several classes of solutions we can envision.  On is a
referral from variants to canonical forms (like DNAME/CNAME and its
synthetic friends).  That works fine from a protocol perspective, but
it requires there to be a single "real" label and variants which only
point to it.  Some zones don't want that result, for both political
and practical reasons.

Another is one in which there is no DNS change at all, but zone
synchronization methods that ensure that the records at one label and
those at another are in sync.  This avoids declaring one to be "real",
but has a very large potential cost in terms of applications which
will not match them as the DNS is, in essence, declaring them to be
distinct.

Another is to create a "canonical + supported variants" approach.
That would involve both mapping variants to a single label and storing
at that label some information about what the zone maintainer
considered variants, so that applications and local caches could treat
them the same.  The security properties of this approach are, to put
it mildly, interesting, but for variants all within a single
administrative domain, it is possibly workable.  The operational
consequences are also pretty daunting unless the record stores a
pointer to some well-known representation of the normalization rules
rather the variants themselves.

This is a case where people want to treat DNS labels as human-friendly
strings.  They are asking us how far down that road we can go without
breaking fundamental bits of the DNS's design and deployment.  So far,
I hear "we can give you referrals to canonical forms, you can give
yourself synchronized zones, and we may be able to achieve a method
that stores variant information with a canonical form".  The label to
label mapping problem is pretty clearly solved somewhere in that set,
but it is not at all sure that the "humans interpolate well, but
canonicalize badly" problem is or can be.

Just my two cents,

Ted Hardie
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

v2.23.0 | Report a Bug | By Email