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

Ted Faber <faber@ISI.EDU> Tue, 08 July 2008 01:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 10BBC3A6BA8; Mon, 7 Jul 2008 18:34:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EF6528C39E for <>; Mon, 7 Jul 2008 18:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.275
X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eKDL-rIFznd1 for <>; Mon, 7 Jul 2008 18:34:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 853713A6B9F for <>; Mon, 7 Jul 2008 18:34:11 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m681WgoA025785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Jul 2008 18:32:43 -0700 (PDT)
Received: (from faber@localhost) by (8.14.2/8.14.2/Submit) id m681Wgmm014057; Mon, 7 Jul 2008 18:32:42 -0700 (PDT) (envelope-from faber)
Date: Mon, 7 Jul 2008 18:32:42 -0700
From: Ted Faber <faber@ISI.EDU>
To: Mark Andrews <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <>
References: <> <>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: 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-Type: multipart/mixed; boundary="===============0486306658=="

On Tue, Jul 08, 2008 at 10:18:25AM +1000, Mark Andrews wrote:
> > That's at least as reliable as my (multi-dotted) home domain. :-)
> > 
> > I'm not sure what's not to like here.  But then again, I may be blind.
> 	The point is that it is NOT reliable.  Whether it works
> 	depends apon what names are matched in the search list.  It
> 	does work for some people some of the time.  It does not
> 	work for all of the world all of the time.  "hk" is not
> 	globally unique.

That statement is also true for,,, or any
other relative DNS name.

The site-dependent interpretation of the name is determined not by the
presence of dot within the name but its absence from the end.  "hk." is
as global as "" with respect to the search list; "hk" and
"" are both relative names and their resolution is resolver

I don't buy "unreliable" as a diagnosis for that state of affairs.  "hk"
operates exactly as any other DNS name with respect to search path.  An
incautious user or clever DNS administrator can create a confusing state
of affairs with or without the interior dot.

(As Bill Manning hinted, there may be other parts of the resolution code
that are less reliable for names without a dot in them.  That I might
buy as an argument for unreliability). 

If you'd like to argue something more subjective like "confusing" or
even "misleading," you'll find no resistance from me.

Ted Faber           PGP:
Unexpected attachment on this mail? See
Ietf mailing list