Re: Services and top-level DNS names (was: Re: Update of RFC 2606

John C Klensin <john-ietf@jck.com> Sat, 05 July 2008 23:38 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 5FF183A68C9; Sat, 5 Jul 2008 16:38:54 -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 6C9EA3A68C9 for <ietf@core3.amsl.com>; Sat, 5 Jul 2008 16:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.201
X-Spam-Level: *
X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_47=0.6]
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 IWmV+5fi9kTy for <ietf@core3.amsl.com>; Sat, 5 Jul 2008 16:38:52 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 22F243A6872 for <ietf@ietf.org>; Sat, 5 Jul 2008 16:38:52 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KFHKl-0009wf-0V; Sat, 05 Jul 2008 19:38:27 -0400
Date: Sat, 05 Jul 2008 19:38:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, John Levine <johnl@iecc.com>
Subject: Re: Services and top-level DNS names (was: Re: Update of RFC 2606
Message-ID: <6FFAE38E2C307D326E5E6527@p3.JCK.COM>
In-Reply-To: <486FE8EA.5030207@gmail.com>
References: <200807050500.m6550DRW062767@drugs.dv.isc.org> <alpine.BSF.1.10.0807050837350.57756@simone.iecc.com> <486FE8EA.5030207@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Mark Andrews <Mark_Andrews@isc.org>, 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Historical note...

--On Sunday, 06 July, 2008 09:34 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

>> Beats me, but since there are several hundred TLDs, it seems
>> to me that the chances are pretty low that everyone in the
>> world has managed to avoid using them as host names.
> 
> Back in the early days, when Czechoslovakia existed, and cs.
> was active, I recall cs.ucl.ac.uk causing great difficulty. Of
> course, the difficulty was due to email systems doing
> pragmatic things about JANET formats, before MX records were
> in use. We also had great difficulty, I remember, with
> uk.oracle.com.

Part of the problem in that case was that, because JANET used
little-endian names internally, the big-endian foo.ucl.ac.uk (in
DNS order) had to be be mapped into uk.ac.uck.foo (in JANET
order) and vice versa.  That mapping was trivial as long as one
could run a simplistic "whichever end the TLD was on had to be
the big side" test.  When "CS" was introduced, blew up that
simple test.  In the JANET case, it failed since there were
strings that could be TLDs at both ends of the string, i.e., in
principle, cs.ucl.ac.uk could have been a string that was
already in JANET order and that would appear in the DNS order as
uk.ac.ucl.cs.  While other heuristics could disambiguate that
one (as long as the Czech TLD didn't do deliberately
pathological things), uk.oracle.com illustrates a case in which
none of the heuristics worked -- the string was simply ambiguous
and one had to know, via out-of-band info, whether it was a
JANET or DNS name.

The introduction of "cs" caused more general problems, unrelated
to name ordering, because there were systems all over the
network in computer science departments with FQDNs like
host.cs.someuniversity.edu.  It was common in many of those
institutions to set up university-wide search rules so that a
reference to host.cs would do the right thing, just like
host.physics, host.philosophy, and so on.  When "CS" was
introduced as a TLD, "host.cs" suddenly became ambiguous (or at
least dependent on exactly how the search rules were set up) as
to whether it represented "host.cs." or
"host.cs.someuniversity.edu.".

And, that, if my memory is correct, was the beginning of our
understanding that search rules needed to be used with great
care, if at all, and that incomplete domain names should not be
sent on the wire as part of protocols.

Note that MX had little or nothing to do with any of this unless
MX records were probed as part of trying to disambiguate the
names.

As an aside, we are at some risk of reinventing the "can't quite
figure out which order the label of this domain name are in" as
we introduce IDNs that contain labels in right to left scripts.
Those who are interested in that issue should pay very careful
attention to the IRI spec and to draft-ietf-idnabis-bidi.

     john

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