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

Ted Faber <faber@ISI.EDU> Tue, 08 July 2008 17:27 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 24FF328C0E5; Tue, 8 Jul 2008 10:27:49 -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 F16C53A6952 for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 10:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.494
X-Spam-Level:
X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=1.105, 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 er24eH-PjDBS for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 10:27:46 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BC13A3A692D for <ietf@ietf.org>; Tue, 8 Jul 2008 10:27:46 -0700 (PDT)
Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m68HR8L1013015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jul 2008 10:27:09 -0700 (PDT)
Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m68HR8Re033981; Tue, 8 Jul 2008 10:27:08 -0700 (PDT) (envelope-from faber)
Date: Tue, 8 Jul 2008 10:27:08 -0700
From: Ted Faber <faber@ISI.EDU>
To: Keith Moore <moore@network-heretics.com>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <20080708172708.GC2519@zod.isi.edu>
References: <20080707211347.GB2222@zod.isi.edu> <200807080018.m680IPi1016117@drugs.dv.isc.org> <20080708013242.GB10677@zod.isi.edu> <4872DEC5.9040707@network-heretics.com>
Mime-Version: 1.0
In-Reply-To: <4872DEC5.9040707@network-heretics.com>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@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-Type: multipart/mixed; boundary="===============0148593528=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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.  Both "hk" and "www.isi.deterlab.net" are relative
names and subject to masking.

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 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. 
> 
> search path isn't the only factor here.

Understood.  It was the objection I was responding to, though.

> 
> 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. :-)

That's probably a longer discussion than I want to have though, so I
agree that this is a stumbling block.

> 
> there are also software implementations that use the presence/absence of 
> a dot to distinguish a DNS name from some other kind of name.  in any 
> context where both a DNS name and something else can appear, it's useful 
> to be able to distinguish the two - and the presence/absence of a dot is 
> about the only test that works.

I'm sure that there are plenty of apps that break here, and certainly
some protocols that have been specified that way, and I feel the pain of
backward compatibility.  If I were running the website at hk, I'd
publicize the conventional DNS names and not hk.  

I really didn't intend to get as deeply into this as I did.  I was
honestly intrigued by a 2-letter hostname and wanted to see if it really
worked, as I could see no reason it wouldn't.  For me it did.

I understand that your resolver, server, and application may all prevent
it.  I also understand that using such names may sow confusion among
those who don't care to examine the workings of their DNS set-up.  And
that any confusion about computers is set upon by the unscrupulous to
gather money.  Encouraging TLD hostnames as a matter of policy is more
complex than noting that the DNS specifications allow such a thing.

But it was pretty cool. :-)

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf