Re: [dnsext] Some thoughts on the updated aliasing draft

Ted Hardie <> Sun, 27 March 2011 09:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 484C528C0F0 for <>; Sun, 27 Mar 2011 02:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.543
X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OdSaQUhbSBQr for <>; Sun, 27 Mar 2011 02:34:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3DEC83A68F4 for <>; Sun, 27 Mar 2011 02:34:23 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2359041iwn.31 for <>; Sun, 27 Mar 2011 02:35:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4nzrBAUW9ziWRmieeQRAIG2bUEJJxjlsAJuze8GdQM4=; b=Jeqn2VI9Ih4ueTQVfV1h7aT4yeqJ6eEl1WSDvhfAXZgvzyDZn73uviU1ysYlQGUfrN vymDV8F3D1wsP5qtQGhYY+SnBbfARHmYRzd1tzZF6JsX6wkx8HSnKiJThjXKJhpmCed0 CHzAG0gYv94WGtEGcXEwRTI1x5ANNdAgQpbFY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tKGoZ9lc52g7DRL9ErA68BTGvcXLWXhe/2UuDaRCangCzHNR0eDbMbwE7EoFG0yiKB pVd5U63oPpgzd+KX8waQ9TtZQcbrWNSfDVqIhvAyPxMGzg4eUimG8qasAnvgyVsIL6XV SRnvw6EeI9XiEaO5vC+fCp9q2EprnyMJrvBl4=
MIME-Version: 1.0
Received: by with SMTP id s1mr2807401ibh.120.1301218559855; Sun, 27 Mar 2011 02:35:59 -0700 (PDT)
Received: by with HTTP; Sun, 27 Mar 2011 02:35:59 -0700 (PDT)
In-Reply-To: <>
References: <20110326203336.44885.qmail@joyce.lan> <> <>
Date: Sun, 27 Mar 2011 11:35:59 +0200
Message-ID: <>
From: Ted Hardie <>
To: Suzanne Woolf <>
Content-Type: multipart/alternative; boundary="001517741202090cbf049f738e48"
Subject: Re: [dnsext] Some thoughts on the updated aliasing draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Mar 2011 09:34:25 -0000

On Sun, Mar 27, 2011 at 11:14 AM, Suzanne Woolf <> wrote:

> On Sun, Mar 27, 2011 at 05:29:52AM +0000, Paul Vixie wrote:
> > > Date: 26 Mar 2011 20:33:36 -0000
> > > From: "John Levine" <>
> > >
> > > ...  In particular, it's quite possible for the DNS to have one
> > > canonical record with everything else pointing to it, but at the
> > > application level all the names look the same.  If I were hacking on
> > > my web or mail servers to handle this stuff, a simple way to do the
> > > configuration would be to configure in the canonical name, and then
> > > set a flag saying also to handle all of the aliases.
> In terms of where we are with the problem statement: I think we've
> determined that we can assume a canonical or base name, with others
> pointing to it, is not only OK but the only practical approach, since
> a more complete isomorphism is hard to describe and may be impossible
> in the current DNS.
> Where we still have some thinking to do (IMHO, but as doc editor) is
> in chracterizing the need, if any, for some property of "sameness" or
> "aliases-of" amongst a group of names such that the application
> doesn't just get what it would have gotten if the alias was the
> canonical name in the first place.
I thought I was with you until this.  Presumably what it gets at the alias
is a pointer to the canonical name, rather than what it would have gotten if
the alias *was* the canonical name.  The advantage of this synthesized
CNAME-style approach is that the client libraries learn that what they
originally handed the DNS was a pointer.  In the ideal case, they can use
that information to update their handling as well (within limits, of course)

> From the registry provisioning side, what seems to be wanted is "the
> applicaton can get an identical result but for less work on the part
> of the provisioning registry/registries (and maybe more work on the
> part of the API/resolver) to simply provisioning all of the names in
> parallel."
To put this another way, you don't have to provision everything to provide a
complete set of pointers, as the first pointer tells the client how to
synthesize them.

> This may also be what applications want, but it doesn't include
> visibility to the application of other associated names, or the fact
> that there are any. Creating such a property and giving the applicaton
> access to it is a different requirement, and at the moment is hard to
> see clearly as an application issue, an API/interface issue, or a DNS
> protocol issue (in any combination).
So, just to restate this for my own jet-lagged benefit:  the client hands a
name to the DNS and gets back the information that it's a pointer to a
canonical name, along with the data required to synthesize other names ("You
asked for "  All names under and including are cannonically at or under").  So
the application could get back "Here's the data for; the requested you handed me returned a pointer to
here".  If it doesn't understand that , it gets the data at the record
stored at

Does this match what you're thinking?


> > if we're allowed by the people asking for this to require dns client
> > libraries and applications to have to be changed to handle a new kind
> > of canonicalization before they'll be able to handle the new definition
> > of "sameness" then this is a practical approach.
> >
> > 'dns client libraries and applications' means the whole internet, so i
> > naturally assumed that this approach was out of scope.
> It would be useful to document where we think this line is. Send text.

> thx,
> Suzanne
> _______________________________________________
> dnsext mailing list