RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)

John C Klensin <> Fri, 04 July 2008 23:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 848313A6B0F; Fri, 4 Jul 2008 16:49:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C1C23A6AF0 for <>; Fri, 4 Jul 2008 16:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EMFhF1T6ZgzQ for <>; Fri, 4 Jul 2008 16:49:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E5563A6B0F for <>; Fri, 4 Jul 2008 16:49:30 -0700 (PDT)
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1KEv1x-0001bc-Ny; Fri, 04 Jul 2008 19:49:34 -0400
Date: Fri, 04 Jul 2008 19:49:32 -0400
From: John C Klensin <>
To: Bernard Aboba <>, Mark Andrews <>
Subject: RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Message-ID: <6DF6CD2370AAF383D8F9172F@p3.JCK.COM>
In-Reply-To: <BLU137-W4119825EB30C448D9C87B7939B0@phx.gbl>
References: <> <E709066D4201B0B9202841FC@p3.JCK.COM> <BLU137-W50030593690ADECA1032C7939B0@phx.gbl> <795604F9E96F8D31B307B8E1@p3.JCK.COM> <BLU137-W4119825EB30C448D9C87B7939B0@phx.gbl>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc:, Lyman Chapin <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


I'm going to try to respond to both your note and Mark's, using
yours as a base because it better reflects my perspective.

Before I go on, I think the three of us are in agreement about
the situation.  The question is what can (or should) be done
about it.

--On Friday, 04 July, 2008 13:52 -0700 Bernard Aboba
<> wrote:

>> Not really.  ICANN isn't "selling" single-label domains.  They
>> are selling (and I believe "selling" is probably now the
>> correct term) plain, ordinary, TLD delegations.  If I get one
>> of those and populate the TLD zone only with delegation
>> records, there are no problems with what ICANN has done at
>> all, whether you describe it as a property right or in some
>> other way.  
> Agreed. 
>> On the other hand, if they delegate one and the enterprise
>> that buys it chooses to populate the zone with service
>> records, then ICANN's position will certainly be that any
>> inability to use those service records isn't ICANN's problem
>> -- any more than difficulties using .museum or .aero were
>> ICANN's problem when those to whom those domains were
>> delegated discovered that a lot of applications software
>> thought that the one TLD label of more than three characters
>> was "ARPA".
> Is generic "buyer beware" disclaimer really sufficient here? 
> The problem isn't just "inability to use" -- it's that other
> parties exist  who may claim the usage right, and provide
> citations to RFCs to back up their claim.
> For example, typing http://brooklynbridgepark/ into a browser
> utilizing a resolver compliant with RFC 1536 will bring you to
> the web site of  Brooklyn Bridge Park Conservancy, assuming
> that .org is in your searchlist.

We agree so far, but let me note that 1536 is an informational
document.  We generally don't claim that systems are expected to
be compliant with those.
> If ICANN sells the brooklynbridgepark TLD delegation to
> another party who populates the zone with service records,
> should that party expect that http://brooklynbridgepark/  
> will now resolve to their site?  RFC 1536 says "no".  
> Similar problems will occur when the party purchasing the
> brooklynbridgepark TLD  attempts to use the single-label name
> "brooklynbridgepark" for other uses, such as network access.

Yes.  And what I fear is that some applications and
implementations will support services on "brooklynbridgepark" as
a TLD and others will start searching.   Yes, that goes well
beyond "buyer beware".

>> And _that_ situation has a lot more to do about "buyer beware"
>> and understanding of conflicting expectations about use than
>> it does about ownership. 
> Today there is a distinction between types of property rights
> - surface, subsurface, or rights to the air above a property.
> As noted at 
> this was not always the case: 
>       If we go back in time to the days before drilling and
> mining, real estate transactions were fee simple
> transfers.  However, once  subsurface mineral production
> possible, the ways in which people own property became
> much more complex.

Sure.  But I know who to call --title insurance companies,
lawyers, judges, etc.-- when your mineral rights intrude on my
surface building rights or vice versa.

> If the analogy holds (and I'm not a lawyer, so I have no idea
> if it does), then we could be talking about a "fee simple"
> transfer in a situation where sub-rights may  be claimed to
> belong to someone else.  

But this gets back exactly to both the rude comments I've been
making about ICANN and the example I tried to construct (not
carefully enough) about a Microsoft TLD.

Let's take the second one first.  Suppose that Microsoft, at a
high corporate level, decided that they wanted to have a TLD
called "microsoft" and that they wanted to attach services to
it.  You would advise against that.  I would advise against
that.  So would others.  We would cite 1535, a number of other
RFCs, and general bad taste.  My assumption is that Microsoft
would give it up -- even if they wanted the domain, they
wouldn't expect to locate services at the top level.  But
suppose some marketing force took over and overwhelmed those
arguments.  The thing that makes Microsoft relevant to this
example is that the company distributes a very popular browser
and a couple of very popular email clients.  Were a corporate
decision to be made to support services on a TLD, at least
services on that one special-case TLD, than that decision could
extend to modifications to those application programs that would
permit access to those services.  

Again, I don't expect that to happen, but it carries over
directly into the main point I'm trying to make, which is that
"property rights" are a relevant metaphor for this situation
only if there is some basis or authority for enforcing those
rights.  As I've pointed out in other contexts recently, the
last few times I've tried to call the Protocol Police, they
didn't answer.

Ultimately, I'm concerned about what the IETF can usefully do
about this situation.   I'm fairly depressed about that because
there is little evidence that ICANN is seeking out in-depth
technical advice and acting on it.  Certainly this set of issues
are not reflected in the list Lyman circulated (and which John
Leslie recently cited in a different form).   If I were actively
involved with the Brooklyn Bridge Park Conservancy and I noticed
that ICANN was considering allocating "brooklynbridgepark" as a
TLD, I would protest and offer to sue ICANN on the grounds that
attempts to use that domain would interfere with the quiet
enjoyment of by my members and visitors,
but I don't think we can depend on that in the general case.

I think we could do the following, but given the track ICANN
seems to be on and the rate at which they seem to be trying to
speed down that track, we had better do them soon:

(1)  Get RFC 1536, probably RFC 1535, any pieces of 1591 we
still care about, and perhaps some other documents promoted from
Informational to BCP (or generate revisions/ updates to them and
publish those at BCP).

(2) Generate a good "use of these sorts of names would really be
a bad idea" document and move it into BCP.  Note that this
document is very different from reserving more names for IETF,
documentation, or similar uses in some form of 2606bis (see the
postscript below).

(3) Review BCP17/RFC2219, be sure that we still believe it (I
see several names that are not on the list in Section 3 of that
document that probably should be), update it as needed, and then
call ICANN's attention to that list and suggest that its entries
be added to their prohibited lists for TLDs.

(4) Tell ICANN that a condition of safe allocation of a large
collection of new TLDs is that they require, as a contractual
matter, that the holders of any new delegations explicitly agree
to not install anything but delegation and glue records in their
TLD zones and to caution people against trying to use glue
records to support services (or whatever rule is actually
correct -- I'm not sure that is it).   Whether they would do
that or not might be an interesting test of how much they are
really concerned about the continued usability and
predictability of the DNS.


p.s. I started on a "bad idea to use these names, or use them in
these ways" document fairly early in these discussions, before
they went off in directions I could not have predicted.  I have
neither the time nor the resources to finish it and especially
not to try to steer it through dnsops and the Applications Area.
But, if anyone else is contemplating doing such a document and
would like a partially-completed version with the needed
references, etc., filled in as a starting point, I'd be happy to
send what I have along.

Ietf mailing list