Re: [Inip-discuss] Domain Names

Edward Lewis <edward.lewis@icann.org> Wed, 20 January 2016 16:15 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 9D5A81A9096 for <inip-discuss@ietfa.amsl.com>; Wed, 20 Jan 2016 08:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.523
X-Spam-Level:
X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] 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 p-VXo2_O4PDw for <inip-discuss@ietfa.amsl.com>; Wed, 20 Jan 2016 08:15:06 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FDA1A9090 for <inip-discuss@iab.org>; Wed, 20 Jan 2016 08:15:06 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 20 Jan 2016 08:15:04 -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; Wed, 20 Jan 2016 08:15:04 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "inip-discuss@iab.org" <inip-discuss@iab.org>
Thread-Topic: [Inip-discuss] Domain Names
Thread-Index: AQHRSlIifVYPXIB/skeh6ZSfDoEE4Z7yzqQAgBIKbYA=
Date: Wed, 20 Jan 2016 16:15:03 +0000
Message-ID: <D2C5151E.12BB5%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>
In-Reply-To: <A8E926AC-3BFF-4406-A12F-B3578BA28E5E@interisle.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.9.151119
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_3536133299_7481095"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/inip-discuss/zEfeIZP5hKyMqEHA9jD6ZwI-b6A>
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: Wed, 20 Jan 2016 16:15:08 -0000

Trying to catch up on the discussion (I was off-net for a few weeks).  I
got back from being away from the network on Jan 18th.

This is an omnibus response to comments up to Olaf asking "what's this
about?" (On Jan 14th in my local timezone).  Mostly here are:

1.) I agree with a couple of Lyman's responses to Warren, and Andrew's to
Doria.
2.) I think there's evidence that the assumption that the DNS defines
Domain Names needs to be broken.

On 1/8/16, 18:45, "Lyman Chapin" <lyman@interisle.net> wrote:

In a response to Warren's examples referring to synthesized names...

>It's incomplete in the sense that the domain name space simply
>establishes the mathematical context within which domain names can be
>constructed. It doesn't tell you how to use them.

>I think the second example mixes apples and oranges. Having a
>well-defined domain name space is relevant to the understanding and
>construction of domain names, like www.foo.bar.baz.example.com; it's not
>relevant to the way in which the RRs in zonefiles direct the operation of
>name resolution.

I agree with Lyman here.  The "wildcard" in DNS is a DNS mechanism for
synthesizing responses to queries and not a definition of the name space.
Wildcards are a shorthand, one could also fully populate the entries by
hand which indicates to me that "wildcards" do not impact/define the name
space but merely reflect it in a more compact manner.  (I'm being
esoteric, having spent a few years preparing the WildCard "clarifications"
RFC - number 4592, leading me to that conclusion.)

On 1/10/16, 18:24, "Inip-discuss on behalf of Andrew Sullivan" wrote:

>On Sun, Jan 10, 2016 at 03:43:19PM -0500, Avri Doria wrote:
>>Is this a definition specific to the IN class domain name space?
>
>That's an excellent question.


I saw the question and had the same reaction.  "CLASS", as far as I
recall, is a DNS invention, not a Domain Name concept.  And the word I'd
use is vestigial (as opposed to appendix, in Andrew's response).  CLASS in
DNS is often forgotten, neglected, and never seemed to blossom in to any
beneficial function.  Unless something emerges, I am inclined to ignore
CLASS when coming to a definition of Domain Names.

On 1/13/16, 13:04, "Inip-discuss on behalf of Lyman Chapin"
<inip-discuss-bounces@iab.org on behalf of lyman@interisle.net> wrote:

>It is! But several people have pointed out that although it may be
>useful, it isn't satisfying. In the math/graph realm we have the domain
>name space and we talk about trees, subtrees, and vertices. In the DNS
>realm we have zones, subzones, and zonefiles and we talk about
>delegation, name servers, and resource records (among other things). It's
>useful to discuss the name space separately from the resolution
>protocols, but from an engineering standpoint the usefulness level is
>much higher if we also know how specific systems (like the DNS) use the
>name space - the correspondence or mapping, if you will, between the
>math/graph realm and the DNS (as a system of protocols) realm.


I'll second that.  In the years of trying to explain DNS and DNSSEC, I ran
into that divide many times (not realizing it was a divide at the time).
Eventually I learned to separate DNS' management model (zones), data model
(the tree), as well as a few others - including the "publishing model
(servers)."  The DNS and the concept of Domain Names only intersect in
what the DNS is storing, in hindsight, from both the perspectives of the
DNS and of Domain Names, that's a small intersection.

"if we know how specific systems (like the DNS)" - I'll emphasize here
that DNS is one example, not the only example, and I think that is what
Lyman is saying.  The DNS (crowd) has spent more time on the topic of
Domain Names but doesn't mean that crowd has monopoly on defining Domain
Names.

On 1/13/16, 17:05, "Inip-discuss on behalf of Lyman Chapin"
<inip-discuss-bounces@iab.org on behalf of lyman@interisle.net> wrote:

>[It's worth noting here, although it gets ahead of the argument a bit,
>that CNAME and DNAME are directives that modify traversal of the tree;
>they are not labels, and are not part of the domain name space. (That
>observation applies even more obviously to ALIAS, ANAME, and other
>redirection hacks.) Similarly, the wildcard "*" is simply a primitive
>regular-expression way to refer to a set of labels; it is not itself a
>label.]


Well, a "*" can be a label - www.*.foo.example - because "*" only takes on
the wildcard/synthesis meaning during a traversal of the name space.  (See
the RFC for details.) Meant with a slight ";)".

What's important in Lyman's point is - one must separate the DNS from
Domain Names.  The DNS as so much machinery in it (traversal directives
like DNAME) that gets confused with what is served in the data model of
Domain Names.  The DNS is poorly architected, given hindsight, a
by-product of the seat-of-the-pants effort, to just get it going.  DNS
isn't evil or bad, it's just not a good textbook.