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

John Levine <> Mon, 07 July 2008 19:44 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id EA7EB3A6983; Mon, 7 Jul 2008 12:44:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBE903A68F3 for <>; Mon, 7 Jul 2008 12:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.829
X-Spam-Status: No, score=-10.829 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CnCFPn4r9GIW for <>; Mon, 7 Jul 2008 12:44:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C137F3A6983 for <>; Mon, 7 Jul 2008 12:44:21 -0700 (PDT)
Received: (qmail 70449 invoked from network); 7 Jul 2008 19:44:27 -0000
Received: from ( by with QMQP; 7 Jul 2008 19:44:27 -0000
Received: from localhost (sendmail-bs@ by localhost with SMTP; 7 Jul 2008 19:44:27 -0000
Date: Mon, 7 Jul 2008 15:44:27 -0400 (EDT)
From: John Levine <>
To: Keith Moore <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 1.10 (BSF 962 2008-03-14)
Cleverness: None detected
MIME-Version: 1.0
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

>> Conversely, if root server traffic is an issue, getting networks to
>> clean up their DNS traffic would be much more effective than limiting
>> the number of TLDs.

> sounds good.  and why wouldn't "cleaning up DNS traffic" include 
> refusing to refer any single-label query (for any record type other than 
> NS, say) to an upstream server?

I have to congratulate you on one of the most subtle proposals to destroy 
the Internet that I have seen in a long time.  More on that in a moment.

As I recall from prior root server surveys, the invalid traffic is 
unambiguously bogus, e.g., queries from RFC1918 space (4% of all traffic 
at one server), repeated queries for the same nonexistent name, dynamic 
rDNS updates from misconfigured Windows boxes, stuff like that where thre 
is no question it's wrong.

But, wow, what a can of worms would be opened by making a subtle semantic 
change to root DNS resolution.  As I presume everyone knows, the DNS is 
managed via a Mexican standoff among the root server operators, ICANN, and 
national governments.  The root servers don't have to do what ICANN says, 
so ICANN has (to date at least) been very careful never to ask them to do 
anything they might not want to do.  Governments assert control over their 
ccTLDs, so ICANN has carefully run IANA as a purely clerical operation, 
with policy decisions limited to verifying that updates are indeed from 
the relevant governments, and the root operators have always accepted the 
ccTLD delegations forwarded by IANA.  Nobody knows exactly what authority 
various governments have over various root servers, which are located in 
many countries all over the world.

So now ICANN and/or the root servers say, we changed our mind, we're not 
going to resolve names without dots.  So who's going to explain to the 
Vatican that, sorry, pope@va doesn't work any more?  Or will the US take 
issue when addresses @as, which is part of the US, don't work?  Or France 
about @gp and @mq, which are as much part of France as Hawaii is part of 
the US?

What will Hong Kong or China do when the F and I roots in Hong Kong no 
longer resolve http://hk/?  The Philipines when the I root in Manila 
doesn't resolve http://ph/?

I'm impressed, it never occurred to me that one could cause this much 
damage with such an arcane change to name resolution.  That was really 

Ietf mailing list