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

Joe Abley <> Tue, 31 December 2013 22:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C0721AE3FD for <>; Tue, 31 Dec 2013 14:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SKp0cbTINhSo for <>; Tue, 31 Dec 2013 14:41:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::233]) by (Postfix) with ESMTP id C6DC51AE316 for <>; Tue, 31 Dec 2013 14:41:23 -0800 (PST)
Received: by with SMTP id x13so13574132ief.38 for <>; Tue, 31 Dec 2013 14:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LD/oqiDOe31Zo0u9c/AAIDuu2x4vPKIrWLw2QwrdlSc=; b=lU9YGcxJPou1TH2k0wCC+peUTTPE/Nj42hKjW+TpnEVwBE9Hac4wGc9P+6buo3Mk71 m4294QyGaJI+sJkNwrTSGYcNjJZ2sCOGxycStufS9rSgH7ldXmmQWVXcuC4BDZBp24rw RRlGMWhYeOXEDz8mSlCYDBGTW2zEiqt1oUF2g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LD/oqiDOe31Zo0u9c/AAIDuu2x4vPKIrWLw2QwrdlSc=; b=hiF5QsgL35dbCnCfDAlWr/X5u+Or21JylXBLQTTsB7mvPSrgAy6fghe6qKzjFgbcD+ dbh8Wq0NtXPlUERtcxzaw7l5pFYgYyWeX3hsEwLohQBiil7iOY2Uoztc0YRa/LuWl+aj c3W0rXCVvX0TC8uRw53rX3cGx290TcBB7xi5opCMZCUkcBWJii7ibXo6TwfT5z5Ks1u/ X0xjtHFbprLnGA0N7O/AJlKYfXFI1Bja4G233OSEPPo+xHjrGOn7d0lWPyArMaJX4k47 NJA3yvLrorQTGYNzvSYfvmDCU4FimAexcG9boKTGDd7W9cPDd9N6DR8LCSwzs7F3eV8D NxFQ==
X-Gm-Message-State: ALoCoQl62wb+WW236AhnLjelnptnLdcDdB8phdpQxHJ/1YNi2EQRabd6rydBOx6Nfadvbf18oVuR
X-Received: by with SMTP id p6mr2300582ici.85.1388529677171; Tue, 31 Dec 2013 14:41:17 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d18sm52201407igz.0.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Dec 2013 14:41:15 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B1523E8A-35A8-4545-933A-485F13B0916A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Joe Abley <>
In-Reply-To: <>
Date: Tue, 31 Dec 2013 17:41:13 -0500
Message-Id: <>
References: <> <>
To: Christian Grothoff <>
X-Mailer: Apple Mail (2.1827)
Cc:, IETF DNSOP WG <>,,, Andrew Sullivan <>
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: Tue, 31 Dec 2013 22:41:26 -0000

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?

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.