Re: [DNSOP] draft-lewis-domain-names-00.txt

Edward Lewis <> Mon, 21 September 2015 14:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8DD9E1B3258 for <>; Mon, 21 Sep 2015 07:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.932
X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nnwFy225u29W for <>; Mon, 21 Sep 2015 07:50:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 613211B3264 for <>; Mon, 21 Sep 2015 07:50:29 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 21 Sep 2015 07:50:26 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1044.021; Mon, 21 Sep 2015 07:50:26 -0700
From: Edward Lewis <>
To: Jim Reid <>, Joe Abley <>
Thread-Topic: [DNSOP] draft-lewis-domain-names-00.txt
Thread-Index: AQHQ8YNHdEo//bQ/vEaybYlWidLMPZ5CuraAgAAKsgCAACh8AIAACPqAgARSEgA=
Date: Mon, 21 Sep 2015 14:50:25 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3525677420_6377676"
MIME-Version: 1.0
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] draft-lewis-domain-names-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: Mon, 21 Sep 2015 14:50:35 -0000

On 9/18/15, 12:51, "DNSOP on behalf of Jim Reid" <
on behalf of>; wrote:

>On 18 Sep 2015, at 17:19, Joe Abley <>; wrote:
>> Whether or not we should call an onion or mdns name a "domain name" or
>>something else is just a detail. I don't think agreeing on the answer is
>>going to solve any of the problems that we actually have

I'm a little surprised at this response and the plus one.

Here's the problem I see.

Lets say I want to write a very basic SSH client (just to make the story
simple).  Someone can then type "eds-ssh computer-name" and open up a
secured connection.

If computer-name ends in .local, I open TCP to an IP address from the
lookup in mDNS.

If computer-name ends in .onion, I open TCP to an IP address I get via Tor
(assuming that .onion supports remote shell).

If computer-name ends in a digit, I suppose it's an address literal and
open TCP accordingly.

If computer-name ends in whatever is in the DNS root zone, I find the
address in DNS.

If computer-name ends in something not in the DNS root zone, I return an

The gotchas include, what if the latter two are indistinguishable because
the DNS resolver sent back a landing page - or the latter three if the
redirection service didn't recognize .onion as special.

What if, in a year from now, .carrot becomes yet another way to resolve

What if, in the future, .alt is defined as having special meaning?  (Note
- the fact that .alt is in an actual ID and .carrot is purely fictional
means .carrot is closer to being an RFC. ;))

It seems to me that a new layer of software is emerging between the UI and
the stub resolver, one that will need to know where to send a name
resolution query.  (Perhaps even amongst DNS stub resolvers on different
interfaces.)  This emerging layer needs to know how to direct it's work
flow.  The Special Use Domain Names Registry would be the place to start
(but as it's written now, the emerging layer can't be future proofed).

These are just TLD examples, perhaps a simplification.

I see a fork in the codepath ahead regarding "whether the DNS is above
Domain Names" (like .alt) or whether "Domain Names are broader than what
was conveniently defined for a DNS".  It's important to know which of
those two statements are true so we can get on with Special Use Domain
Names, and perhaps to find ways to objectively assign new names for new

I think defining -whether- name.onion is a Domain Name will make us
re-think how Domain Names interoperate amongst protocols beyond the DNS.