Re: [Inip-discuss] Domain Names

Edward Lewis <edward.lewis@icann.org> Fri, 22 January 2016 20:40 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: inip-discuss@ietfa.amsl.com
Delivered-To: inip-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA891A882C for <inip-discuss@ietfa.amsl.com>; Fri, 22 Jan 2016 12:40:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level:
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 1kI3ZuscYUcG for <inip-discuss@ietfa.amsl.com>; Fri, 22 Jan 2016 12:40:30 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FB01A882A for <inip-discuss@iab.org>; Fri, 22 Jan 2016 12:40:30 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 22 Jan 2016 12:40:28 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Fri, 22 Jan 2016 12:40:28 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "avri@acm.org" <avri@acm.org>
Thread-Topic: [Inip-discuss] Domain Names
Thread-Index: AQHRSlIifVYPXIB/skeh6ZSfDoEE4Z7yzqQAgBIKbYCAA7gkAP//tqyA
Date: Fri, 22 Jan 2016 20:40:28 +0000
Message-ID: <D2C7F991.12D11%edward.lewis@icann.org>
References: <D285CCDC.11B63%edward.lewis@icann.org> <A3306B3F-2C01-4236-8A5F-119C1669425B@isoc.org> <D2A15E6C.124B4%edward.lewis@icann.org> <7047EC59-873A-4A76-80EF-3F2899A9052A@interisle.net> <CAHw9_iL1f7pgaFHdqWJTpW5mxbfRYsquOO3J-5cVNLv103LSig@mail.gmail.com> <A8E926AC-3BFF-4406-A12F-B3578BA28E5E@interisle.net> <D2C5151E.12BB5%edward.lewis@icann.org> <56A28AEA.9060604@acm.org>
In-Reply-To: <56A28AEA.9060604@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.0.151221
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3536322023_4431691"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/inip-discuss/3-BwftQq25rvEAdujLG7RIGi6wY>
Cc: "inip-discuss@iab.org" <inip-discuss@iab.org>
Subject: Re: [Inip-discuss] Domain Names
X-BeenThere: inip-discuss@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IAB Internet Names and Identifiers Discussion List <inip-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/inip-discuss>, <mailto:inip-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/inip-discuss/>
List-Post: <mailto:inip-discuss@iab.org>
List-Help: <mailto:inip-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/inip-discuss>, <mailto:inip-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2016 20:40:32 -0000

On 1/22/16, 15:02, "Inip-discuss on behalf of Avri Doria"
<inip-discuss-bounces@iab.org on behalf of avri@acm.org> wrote:

>I had always understood that CLASS was broken in some sense in that the
>standard RR types ignored it.  I did not realize it had been designed as
>a NULL .
>
>Can it be ignored as long as it is part of the syntax?  Or does it need
>a footnote in any definition?

This is an arm-chair response, i.e., not researched.

In the messages sent "on the wire" there are 16-bit fields for the CLASS
value.  They can't be removed unless we overhaul what's send over the
wire.  Altering the meaning of the 16-bit field would cause backwards
compatibility issues, at least in theory.

I should add one anecdotal story to this.  One of the "legendary figures
of DNS" once told me that a major screw up was placing the 16-bit field
for CLASS after the field for the "owner name".  Had the 16-bit field come
first, it could have been interesting, a way to distinguish different ways
to encode the owner name.  Being afterwards, one had to stick to one lone
means of encoding the owner name in order to discover the CLASS value.
I'll stress that I got this as part of an oral history, not documented, so
it's almost worth the paper it's written on.  But it is what makes me call
CLASS vestigial and a DNS artifact, not a Domain Name core concept.
>
>Also,
>Is the definition of names in this only related to DNS usage?

In my draft (if that is "this") no, I'm trying to raise the idea of domain
names out of the realm of the DNS and into their own place.  My rationale
is (as an example) to put things like Tor's naming on the same table as
DNS when it comes to an architectural view.

The DNS has the most detailed definition of it's "dialect" of Domain
Names, hence DNS seems to be the authority.  That might be well and good -
but this stymies innovation in alternates to the way the DNS manages names.

>When looking at URL syntax is  it safe to say that the domain names only
>refer to  hosts within the set of Common Internet Schemes?  And that
>names in other schemes are outside these definitions are thus not
>Internet domain names (though of course they can use same syntax if they
>wish).

I'm not terribly well-versed in URL so someone may correct me.  The URL
definition, for http(s): in particular, calls the first "part" an
authority.  There is text saying the authority can be thought of as DNS
managed but is not exclusively DNS managed.  The wording I've read isn't
very detailed, I forget the reference off-hand but I am sure it is in the
draft I have.  (Again, take this email as an armchair response.)

Here's the conflict with URLs and CLASS - in the http://... scheme,
there's no way to distinguish the CLASS to use for the authority's name -
assuming it is a DNS name.  I bet that browsers just plug in "IN"
(Internet Class) as oppsoed to CHAOS or HESIOD (the other useable,
registered values for CLASS).  Perhaps a browser might "know that
"version.bind" ought to be CHAOS class, but that would be a stretch.

Besides the CLASS, the problem run into with the dotOnion work from Tor is
that only an extended browser would know to use the Tor name resolution
process and not the DNS.  (Again, the authority of the URL lacks meta-data
about whether the name is in the DNS and what CLASS value to use.)

>Or am I making some sort of category error?

If I'm reading right, I think you are seeing, or perhaps starting to see,
the problem at hand.

When we had just one game in town, DNS and IN class, there was no need for
other applications/protocols to be careful when handling
identifiers/names.  As others games come to town, there's a need for some
clarification on Domain Names.