Re: Update of RFC 2606 based on the recent ICANN changes ?

Keith Moore <> Tue, 08 July 2008 18:17 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 334B428C220; Tue, 8 Jul 2008 11:17:53 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E73F28C220 for <>; Tue, 8 Jul 2008 11:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lJOksy7i66GN for <>; Tue, 8 Jul 2008 11:17:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C72728C21B for <>; Tue, 8 Jul 2008 11:17:51 -0700 (PDT)
Received: from ( [] (may be forged)) by (MOS 3.8.4-GA) with ESMTP id AWI77470 (AUTH for; Tue, 8 Jul 2008 11:17:59 -0700 (PDT)
Message-ID: <>
Date: Tue, 08 Jul 2008 14:17:57 -0400
From: Keith Moore <>
User-Agent: Thunderbird (Macintosh/20080421)
MIME-Version: 1.0
To: Ted Faber <faber@ISI.EDU>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
References: <> <> <> <> <>
In-Reply-To: <>
Cc: Mark Andrews <>, Theodore Tso <tytso@MIT.EDU>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Ted Faber wrote:
> On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote:
>>> The site-dependent interpretation of the name is determined not by the
>>> presence of dot within the name but its absence from the end. 
>> not so.  in many contexts the trailing dot is not valid syntax.
> Let me be precise.  The resolver treats those names differently because
> it was handed a name that did or did not end in a dot - the resolver's
> syntax for absolute vs. relative pathname.  I understand that may
> conflict with application syntax.  Applications that do not support an
> explicit notation for absolute domain names will not be able to look
> them up when those names are masked by site-dependent resolution of
> relative names. 

It's more likely that the application (as specified) simply expects 
(implicitly or explicitly) absolute domain names.  If and when relative 
domain names "work", it's either by accident or a result of sloppy coding.

Few applications are specified in such a way that relative DNS names 
make sense and there is a clear way to distinguish relative names from 
absolute DNS names.  (Note that "make sense" generally includes 
converting relative names to absolute names in the context of whoever 
typed in the relative name - and dealing with the potential for skew 
over time between the relative name and absolute equivalent.  in other 
words, this is not an easy thing to do well.)

The problem is worsened because most APIs for name lookup are poorly 
designed in several ways.  One of their problems is that they tend to do 
"relative" lookups by default even though often that's not desirable. 
Another problem is that they tend to do other kinds of lookups by 
default in addition to DNS (perhaps as a fallback) even in contexts 
where DNS lookups are required for interoperability.  Applications may 
or may not work around these API problems, and to the extent they do, 
they probably don't do so consistently from one implementation to the next.

> I understand that such maskings are more intuitive with short names like
> "hk", but that limitation of the application interface applies to any
> relative domain name.

I'm not sure what "intuitive" means in this context.  But the 
probability of collision is certainly larger for short names than for 
longer ones.  I suspect it's also larger for single-label names than for 
multiple-label names, where each label is assigned by a different entity.

And a higher probability of collision definitely translates to a lower 
degree of reliability.

>> there are also protocol specifications that expect DNS names to have 
>> dots in them.
> One could argue that such protocols are not able to express all valid
> domain names, which may be a feature. :-)

The notion of a single-label fully-qualified DNS name being "valid" is 
an odd one.   DNS, as far as I can tell, was always intended to be 
federated, both in assignment and lookup.  The notion of having terminal 
(basically, non NS) records at the root seems contraindicated by several 
of the DNS design goals.

For example, at the time DNS was established, single label names like 
CMUA or MIT-AI were the norm.  But those names were not incorporated 
into the root (even during a transition), nor were TLDs created for 
those zones - because DNS was not intended to work that way.  The whole 
idea was to federate the name space, not to provide another way to look 
up single-label names.  (Instead, the names were incorporated into the 
.ARPA TLD for a time, with CNAMEs pointing to the real names.)

So I persist in thinking that single-label DNS names are not valid, and 
that to the extent they work at all, they work only by accident or as a 
result of poor specification or sloppy implementation.

And given the recent interest in vanity TLDs and ICANN's apparent lack 
of willingness to run the DNS for the benefit of all, maybe it's time 
for IETF to remind people that single label TLDs are not actually 
supposed to work.

Ietf mailing list