Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

Lyman Chapin <lyman@INTERISLE.NET> Thu, 14 May 2015 01:58 UTC

Return-Path: <lyman@INTERISLE.NET>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84261A9007 for <dnsop@ietfa.amsl.com>; Wed, 13 May 2015 18:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5agtzjbgOWs for <dnsop@ietfa.amsl.com>; Wed, 13 May 2015 18:58:41 -0700 (PDT)
Received: from mail.shire.net (mail.shire.net [199.102.78.250]) by ietfa.amsl.com (Postfix) with ESMTP id BFE641A890D for <dnsop@ietf.org>; Wed, 13 May 2015 18:58:41 -0700 (PDT)
Received: from c-66-30-117-182.hsd1.ma.comcast.net ([66.30.117.182] helo=[172.24.20.155]) by mail.shire.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <lyman@INTERISLE.NET>) id 1YsiQ5-0006It-2z; Wed, 13 May 2015 19:58:41 -0600
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Lyman Chapin <lyman@INTERISLE.NET>
In-Reply-To: <7AD02DF7-45A5-42CE-AAE2-50CCAE3B6A4F@virtualized.org>
Date: Wed, 13 May 2015 21:58:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EC766DD-E56D-4E6F-80D7-8B26BC87A528@INTERISLE.NET>
References: <20150513205135.14395.qmail@ary.lan> <7AD02DF7-45A5-42CE-AAE2-50CCAE3B6A4F@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.1283)
X-SA-Exim-Connect-IP: 66.30.117.182
X-SA-Exim-Mail-From: lyman@INTERISLE.NET
X-SA-Exim-Scanned: No (on mail.shire.net); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/TTEPe0ZTAtK_EmXfiZOZ41RcDGw>
Cc: dnsop WG <dnsop@ietf.org>, John Levine <johnl@taugh.com>
Subject: Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 01:58:43 -0000

On May 13, 2015, at 6:05 PM, David Conrad wrote:

> John,
> 
>> On May 13, 2015, at 1:51 PM, John Levine <johnl@taugh.com> wrote:
>>> The distinction I'm making suggests why corp and onion seem different.  They are, in this
>>> fundamental resolution nature.
>> 
>> I was under the impression that part of the problem with .corp was
>> that there were a lot of SSL certificates floating around.
> 
> The SSL cert aspect of CORP usage was a component of the concern, but not the sole problem.

I think it's important to recognize that the issues with corp/home/mail have to do with *scope*, not with whether or not the DNS should be involved in resolving them. The established usage of corp/home/mail depends (conceptually and in practice) on using "the DNS" for name resolution, but it also depends on the historical assumption that those names would never resolve outside of their local scope because they were not globally-valid TLDs. That's not the case for onion (for example).

>> With regard to the theory that ICANN has said they won't delegate
>> .corp, .home, and .mail, they've only said they're "deferred"
> 
> I believe this is true.
> 
>> So this isn't an ICANN issue, it's an IANA issue.
> 
> It is neither: it is a DNS operational issue. A "large" number of people are apparently squatting on CORP/HOME/MAIL. Delegation of those TLDs would thus impact that "large" number of people.

I think it is inaccurate (and unhelpful) to refer to the people who have been using corp/home/mail as squatters; most of them have simply been following what textbooks, consultants, and "best practice" guidelines have been advocating for a long time. They are not trying to claim or usurp territory that they (should) know doesn't belong to them; they have been playing by the rules that they learned when they studied for their Microsoft certification exams. We could go back in time and warn everyone that using a non-delegated name as the TLD anchor for an AD tree would someday turn out to be a problem, but absent that we have little justification for blaming them.

That having been said, I understand that you're agreeing with me that this is a DNS operational issue :-)

>> ICANN can't sell
>> .corp, .home, and .mail for the same reason they can't sell .arpa or
>> .invalid: they're already spoken for.
> 
> This is not true.

It's not, and John knows that, but it should be.

> ARPA is defined in RFC 3172 and the IAB "in cooperation with ICANN" are responsible for it.
> INVALID is defined in RFC 2606 which reserves its use.
> 
> CORP/HOME/MAIL are not defined anywhere (other than drafts).
> 
> But I suspect you know this, so I'm unclear why you claim "they're already spoken for."
> 
> ICANN can't "sell" CORP/HOME/MAIL because there are concerns related to security/stability with those TLDs that are, as yet, unresolved.

The security/stability concerns do not prevent ICANN from selling them. A decision by the IETF to reserve them would. My point from the beginning [1] has been that the operational stability of the Internet is the proper concern of the IETF; it is not a policy issue, or a domain name registry competition issue, or any of the other issues that are the proper concern of ICANN. I don't intend that as a negative comment about ICANN - I'm not saying "those guys would sell their .grandmother if they thought they could make a buck out of it, security and stability be damned." I'm saying that the IETF's core interest in a stable, operating Internet is the context in which the issue should be resolved.

- Lyman

[1] https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.txt