Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01

"Guangqing Deng" <> Thu, 02 January 2014 06:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 089981AE2FA for <>; Wed, 1 Jan 2014 22:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.436
X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_NEW_HELO_USER=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pemRGdKtJmTe for <>; Wed, 1 Jan 2014 22:46:30 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B83A81AE2F9 for <>; Wed, 1 Jan 2014 22:46:28 -0800 (PST)
Received: from unknown127.0.0.1 (HELO user-think) ( by with SMTP; Thu, 02 Jan 2014 14:46:19 +0800
Date: Thu, 2 Jan 2014 14:46:19 +0800
From: "Guangqing Deng" <>
To: "Joe Abley" <>
References: <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 1, 3, 52[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart473422040536_=----"
Cc: dnsop <>
Subject: Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01
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, 02 Jan 2014 06:46:33 -0000

comments in-line.

Guangqing Deng

From: Joe Abley
Date: 2014-01-01 06:41
To: Christian Grothoff
CC: hellekin; IETF DNSOP WG; wachs; jacob; Andrew Sullivan
Subject: Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01

>On 2013-12-31, at 15:06, Christian Grothoff <> wrote:

>> And again, a key question for me is, if you really want to _encourage_
>> people to _first_ deploy at large scale and _then_ reserve the name.

>You can reserve a name for $10/year, no IETF process required. Less if you reserve under an existing domain name.

>The key question for me is, why do any of these uses necessarily require reservation of a TLD label, or something that looks like one?

>If (to take an example at random) Tor users could make use of names outside of the DNS that look like DNS names under a .ONION TLD, why could they not just as easily make use of >names that end in ONION.EFF.ORG?

Another factor may be the resolution delay, if real-time is really very important for those so called P2P applications. Usually in the hierachical  DNS system, the resolution delay of domain names like EXAMPLE.ONION is less than that of those like EXAMPLE.ONION.EFF.ORG. So maybe we should consider more about does the TLD (like .ONION) is really needed? 

>The general answer to this question (in the DNS world) is that names will appear in television ads and billboard posters, and hence need to be short and memorable. I'm not sure how >convincing that answer is (time will tell, I guess) but it seems less convincing for naming schemes that involve easily-typo'd, long hexadecimal strings as interior labels. These are >presumably not intended for direct entry by users. Where is the need for a pithy TLD?

>If the answer is "well, it wasn't done that way, and there's a huge deployed base" then I would take the time to consider migration strategies away from schemes that seem to involve top->level DNS labels towards schemes that don't. It's inevitable that these names will leak to the DNS, and those leaks will be easier to mitigate the further the names are from the DNS root.

>> I expect that this MAY happen, but if the draft is accepted, one
>> of our goals is to explicitly authorize DNS operators to prevent
>> this.  Right now, a well-configured, 100% RFC-compliant DNS resolver
>> MUST pass a request for ".onion" to the root.  With this draft, we
>> want to explicitly ALLOW 100% RFC-compliant DNS resolvers to instead
>> immediately return NXDOMAIN and thus avoid the security and performance
>> implications of leaking such queries to the root.

>The IETF is not the resolver police. Resolver operators mitigate weird problems with approaches like this all the time. It's a mistake to imagine that a blessing enshrined in a document >published by the IETF will immediately trigger changes in deployed infrastructure, or that deployed infrastructure is being hamstrung by the lack of such a blessing.

>Consider, however, the different degrees of chaos that might result from:

>(a) instruct all the resolver operators in the world to maintain configuration that special-cases a growing list of DNS names. or

>(b) chose your naming scheme (again, think ONION.EFF.ORG) such that the NXDOMAINs, negative caching, sinkholing, whatever can be controlled by someone who cares about Tor (the >EFF.ORG administrator) without requiring any special handling elsewhere.

>Option (b) is much more friendly to the Internet.


DNSOP mailing list