Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

Mark Andrews <> Thu, 30 January 2014 00:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA6851A043F for <>; Wed, 29 Jan 2014 16:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.236
X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_HOME=2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3_beciNRFsTA for <>; Wed, 29 Jan 2014 16:45:48 -0800 (PST)
Received: from ( [IPv6:2001:4f8:0:2::2b]) by (Postfix) with ESMTP id 46DF91A0423 for <>; Wed, 29 Jan 2014 16:45:48 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 739E2C947F; Thu, 30 Jan 2014 00:45:31 +0000 (UTC) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim2012; t=1391042745; bh=GUBMFFmGykHiUeKxhyYg2AItWotPy8cS9p3C0aNKqXY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Zh0S8y8xaMQx/axOaspCcKEayddgIHq9ev0KDU0xVZk9SOr520B+ZcKJ6dK2Kc3pP RBlsxu2N/cTZQ5EmjHZRODLqiAHwvMF7Y8sNSiJ0uKl1qpN/bOxSJH5TaADC2B9PA9 Odh/2wFT9E69yrWmJnIi+d/LJv2/8AgctmMLhLC4=
Received: from ( []) by (Postfix) with ESMTP; Thu, 30 Jan 2014 00:45:31 +0000 (UTC) (envelope-from
Received: from (localhost []) by (Postfix) with ESMTP id A71CD160470; Thu, 30 Jan 2014 00:57:28 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 45926160389; Thu, 30 Jan 2014 00:57:28 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id C660CE086E0; Thu, 30 Jan 2014 11:45:30 +1100 (EST)
To: Ralf Weber <>
From: Mark Andrews <>
References: <20140129055438.2402.qmail@joyce.lan> <> <> <> <> <>
In-reply-to: Your message of "Wed, 29 Jan 2014 10:45:40 -0800." <>
Date: Thu, 30 Jan 2014 11:45:30 +1100
Message-Id: <>
X-DCC--Metrics:; whitelist
Cc: " WG" <>, Joe Abley <>, Paul Hoffman <>
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jan 2014 00:45:50 -0000

In message <>, Ralf Weber writes:
> Moin!
> On 29 Jan 2014, at 10:07, Joe Abley <> wrote:
> > A risk to the Internet as a whole is that a fragmented namespace (.LAN mean
> s something different in John's office than it does at the cafe next door; .H
> OME meaning something different to the thirty million subscribers of ISP X th
> an it does to others) will restrict communication by name between endpoints o
> n the Internet, and changes the fundamental assumptions on which protocols an
> d applications rely to an extent that is potentially unbounded.
> 1. The fragmented name space is a reality and has been for some time (dns spl
> it horizon search on google reveals 500k pages)

And there is a difference between fragmenting namespace that you
control and fragmenting namespace that others control.

I have split horizon namespace ( but I control the
contents of all versions of that namespace.  Any leaks get answered
by nameservers configured for that zone.

It doesn't have to cost you anything (other than time to setup the
registration) to get a namespace that you have control over.  There
are infrastructure zones which still do free registrations on best
effort basis.

This is about fragmented namespaces where the control is not under
a single party.  This is about pollution of / squatting on the
common namespace ".".

The squatted tld's used by software .onion, .bit etc could be
migrated to a new namespaces.  Just issue new software that looks
/ recognises in the new namespace first then in the old one for X
years.  After X years stop looking in / recognising the old namespace.
Set X to about 10 years and there will be very little old code left
when you turn off support for the namespace.  Set and compile in
the drop dead date.

> 2. If endpoints use proper globally registered DNS names they will be able to
>  communicate. If they use something else the behaviour is undefined.
> I think there is more value in thinking about how we can integrate local and 
> global naming than in trying to protect people by not allowing something to n
> ot be registered in the global name space.
> > This is the end-to-end principle wearing a DNS t-shirt (the IP t-shirt was 
> all cut up by a hundred million NATs, and is no good when it's cold out).
> I don't think the DNS t-shirt looks better.
> > The trouble here is not recognising that namespace collisions are bad; it's
>  (a) deciding where to draw the line between "bad" and "good enough" and (b) 
> dealing with the political headaches of "use it, measure it, reserve it at th
> e IETF" which costs $0 and "follow the ICANN new gTLD applicant guidebook" wh
> ich costs substantially more.
> I do recognise them. The data that we have shows that they exists. I just thi
> nk that it is nothing the IETF should invest time in. While the IETF cost is 
> significant lower than the ICANN cost I doubt that RFCs will get lawyers out 
> of ICANNs back. I think the ship has sailed and it now is a political (layer 
> 9) problem who can register what in the global DNS name space.
> So long
> -Ralf
> _______________________________________________
> DNSOP mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: