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

Keith Moore <moore@network-heretics.com> Tue, 08 July 2008 16:23 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACAE3A690D; Tue, 8 Jul 2008 09:23:36 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5E23A690D for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 09:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2]
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 LwEUPriF6Lcc for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 09:23:34 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 5BA7F3A6810 for <ietf@ietf.org>; Tue, 8 Jul 2008 09:23:34 -0700 (PDT)
Received: from lust.indecency.org (mail.fiveman.com [72.242.14.234] (may be forged)) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AWI63518 (AUTH admin@network-heretics.com) for ietf@ietf.org; Tue, 8 Jul 2008 09:23:42 -0700 (PDT)
Message-ID: <4873948A.2040904@network-heretics.com>
Date: Tue, 08 Jul 2008 12:23:38 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.14 (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: <20080708020228.GC10677@zod.isi.edu> <200807080254.m682sG2Q007427@drugs.dv.isc.org> <20080708161335.GB2519@zod.isi.edu>
In-Reply-To: <20080708161335.GB2519@zod.isi.edu>
Cc: Mark Andrews <Mark_Andrews@isc.org>, Theodore Tso <tytso@MIT.EDU>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Ted Faber wrote:
> On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
>> 	"hk." is not a syntactically valid hostname (RFC 952).
>> 	"hk." is not a syntactically valid mail domain.
>> 	Periods at the end are not legal.
>>
>> 	RFC 1035 has *nothing* to do with defining what is legal
>> 	as a hostname.
> 
> Fair enough. 
> 
> By RFC952 standards "hk" is a perfectly fine hostname.
> 
> By RFC1035 standards, if you look it or any other DNS name up using the
> DNS resolver, that resolver will treat the name as relative unless it
> ends with a dot.   Arguing that hk is an unreliable hostname if you
> look it up as a relative pathname is pretty much the same as arguing
> that www.isi.deterlab.net is an unreliable hostname.  Both of them are
> subject to the search path without that trailing dot.

RFC1035 may recognize the trailing dot, but (for better or worse) many 
applications do not recognize it, and some explicitly forbid it.

> So far, the only distinction between the two is that hk is short.
> 
> I understand the assumption that getting a collision in the search path
> with a 2-letter name is higher than getting one with a 20-letter name.
> I believe that the 2-letter collisions are no harder to avoid in
> principle than the 20-letter ones, and no harder to create should an
> admin want to do so (e.g., to create local aliases).  I think you
> believe that search path collisions for short names are inherently
> harder to avoid (and might rule out using the trailing dot notation in
> applications to avoid them).
> 
> Is that basically what we disagree about?

No.  There's more to this than just the possibility of name collisions 
caused by the lookup using a search path.

For instance, there are also applications that try to distinguish 
between an absolute DNS name and some other kind of name (DNS name 
relative to the search path, or a name in /etc/hosts, NetBIOS, NIS, ...) 
by checking to see whether the name contains a '.'.  So for instance, if 
the domain name contains a '.', the "search path" function might be 
turned off during name lookup.

This behavior isn't necessarily prescribed in any specification, but 
it's a useful heuristic - especially for an application (like email 
addresses or URLs) where it's important that domain names be unambiguous 
and location-independent.

Keith
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf