Subject: Re: [Inip-discuss] Domain Names

From: Lyman Chapin <[email-masked]>
Date: Thu, 7 Jan 2016 16:57:09 -0500

On Dec 24, 2015, at 11:02 AM, Edward Lewis wrote:

> Acting on Olaf's permission, in trying to prepare another version of my
> draft.
> 
> On 12/18/15, 7:05, "Olaf Kolkman" <[email-masked]> wrote:
> 
>> Feel free to forward to appropriate list.
>> 
>> 
>> A Domain Name is a sequence of labels concatenated by a designated
>> separating character.  The Domain Name Space is organized in a strict
>> hierarchical manner with a recognized root Domain Name.  The
>> organization follows the rules of tree structure as defined by the
>> field of graph theory in mathematics [Diestel].

Hi Ed -

In the course of working on another project, I assembled the following extended definition of "domain name space" in an attempt to (a) make the distinction between "the domain name space" and "domain names" clear, and (b) to encourage a bit more precision in the way in which we talk about domain names.

-------------------------------

In graph-theoretic terms, the domain name space constitutes a labelled directed rooted tree in which the syntax of the label associated with each vertex other than the unlabelled root is defined by RFCs 1035, 1123, and 2181. The term "nth level domain name label" refers to a member of the set of all vertices for which the path to the root contains n edges. For n=1 the term most often used is "top level domain name label" or simply "top level domain" (TLD). A fully qualified domain name is a sequence of labels that represents a path from the root to a leaf vertex of the domain name space. The shorter term "domain name" is not formally defined; in common usage it may be the shorthand equivalent of "fully qualified domain name" (FQDN) or refer to any non-empty subset of the sequence of labels formally identified by a fully qualified domain name.

In this formulation, the term "domain name space" refers to the complete graph consisting of all possible vertices and edges - not just those with which a specific meaning has been associated (what we might call "allocated" labels). It is a finite graph because the length of the longest possible FQDN is finite. At any point in time, there is another labelled directed rooted tree - a sub-graph of the domain name space - containing only vertices that represent allocated labels.

-------------------------------

So mathematically, a domain name is simply a sequence of labels. In most of the contexts in which we talk about, write about, or use domain names we add representational elements like "top to bottom" or "separating character," but those are not properties of a domain name.

Not terribly pragmatic, I know; but it might have a place in your draft -

- Lyman

>> 
>> 
>> That definition covers my street address:
>> 
>> Olaf Kolkman
>> Internet Society
>> 400
>> Science Park
>> Netherlands
>> 
>> I think that the recursive character of a domain from RFC805 should be
>> part of the definition.
> 
> This comment hits on the central item in the draft that begs discussion,
> that is, a definition of Domain Names.
> 
> There are a few ways to attack the definition, in increasing order of
> specificity (and perhaps not complete):
> 
> 1 - The nature of the hierarchical arrangement of domains (embedded in the
> recursive definition in RFC 805). The notion that there is a single root
> to the tree and domains descend from that.  The notion of "right-to-left"
> or "left-to-right" is insignificant, "top to bottom" is.  The components
> of a domain's name are the labels from top to bottom (expressed in
> whatever order is appropriate for the locality).  The syntax of the labels
> are undefined or rather not specifically defined.  The means to extract
> information indexed by the domain name is also not specifically defined.
> Meaning - there has to be some implicit means of determining syntax and
> resolution process.  Similarly, the management of the domain name is also
> undefined.
> 
> 2 - The look of a domain name being a sequence of labels from top to
> bottom, separated by a dot character. This descends quickly from the
> architectural plane and comes a long way to what client applications (like
> SSH, FTP, Web Browser) will see from human user input.  The basic
> definition is tied to ASCII but with punycode, Unicode strings can be
> mapped in.  There is implicit signaling established for punycode results.
> What is still a variable are: length of labels, management of labels, and
> means to resolve.
> 
> 3 - A definition that is (or starts with) aligned to that of the DNS.
> There's a syntax defined, both for DNS domain names "on the wire" and in
> zone file format, which is restricted for an era where acceptable
> performance assumed fixed or constrained field lengths.  The DNS imposes a
> centralized means of creating and managing names.
> 
> Of these definitions, the final is the most pragmatic and concrete but
> perpetuates an ASCII-dominate view of the Internet and is tied to ancient
> realities of technology.  Personally I don't like that and is why I refer
> to starting with the DNS definition like "assuming the earth is the center
> of the universe" and then mapping out the other planets' orbits.
> 
> But, this isn't about defining naming and identifier systems, it is about
> defining a particular name and identifier system that (continues to)
> foster reuse of software across various protocols.  Whether there is a
> line drawn around the collection as "IETF" protocols or not is rather
> unimportant in so much as it may not be feasible nor desirable to ever
> draw such a line.
> 
> Where I see the situation heading is a "clarifications" on the topic.  The
> ingredients for a clarification are - lack of a clear definition as
> evidenced by a plethora of valid interpretations (which my draft has come
> to build), a specific need to unify the concept to stem or reverse the
> divergence (the 'crisis' over new entries to the Special-Use Domain Names
> registry), and a willingness to realize that a clarification is inherently
> a change to the base specification and some backwards compatibility pain
> will likely be felt.  This latter point is one that has not been reached
> yet.
> 
> If we proceed towards a clarification on the topic of Domain Names,
> whether or not as names and identifiers, the next order of questions to
> consider includes the next - as one example, but a significant example:
> 
>> When you say:
>> 
>> I think, and I mean that as "think", there is a need to find a happy
>> medium where identifiers can be managed in different ways (DNS hierarchy
>> and zone admin vs. Tor's cryptographic basis) yet use similar syntax for
>> the purposes of sharing existing protocols (like HTTP) while using
>> different resolution processes.
>> 
>> Then I would agree with you. The requirement that gets out of that is
>> that there is a requirement to be able to fork the use of that identifier
>> so that the application knows which resolution mechanism to take. Tor
>> seems to be doing that based on a magic cookie in the form of the TLD
>> label. Not sure if there are any other ways.
> 
> There are two ways to determine the means of resolution when given a name.
> One is implicit in the name, using, as an example, the top-level name
> (note, I don't use top-level domain nor TLD), using that as a switch in
> software that resolves names.  The other, obviously, is explicit, by
> building into software knowledge of what kind of name is being handled,
> e.g., using separate http schemes.
> 
> Personal opinion of mine feels that explicit means would cause greater
> disruption than building in an implicit definition.  Explaining this gets
> into how to solve this as opposed to an architectural discussion, meaning
> it gets into how client software could be built to add "yet another layer
> of indirection" when handling the resolution of names.
> 
> BTW, one implicit way to consider is having the top-level name "looked up"
> within a newer version of a special-use domain names registry.  Limiting
> the needed lookup key to the top-level name might or might not alleviate
> concerns over so-called pervasive monitoring.  (I am not sure if that is
> acceptable.)  Beyond that I can't dream of another scaleable and future
> proof means, I mean a piece of software would hard-code in the rules for
> an untra-privacy desiring naming system but that would not be inherently
> scaleable.
> 
> (I don't know if extreme privacy can scale well.  One has to be very
> careful if one wants to be anonymous.)
> _______________________________________________
> Inip-discuss mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/inip-discuss

---

From: Eliot Lear <[email-masked]>
Date: Fri, 8 Jan 2016 10:43:16 +0100

Hey Gihan,

"Into the Wayback Machine, Sherman!"

Probably worth reviewing Saltzer, Shoch, et al.  See RFC 1498 as a good
starting point.

Eliot

On 12/19/15 6:16 AM, Gihan Dias wrote:
> On 15/12/19 2:35 AM, Suzanne Woolf wrote:
>> The IAB recently decided that all of the technical programs should have public, open-subscription lists, to make sure we’re getting the widest input possible on those topics if architectural interest and to support transparency in “what are the programs doing anyway?”
> Warren, Ed, Suzanne,
>
> Thanks.
>
> I read the INIP description, and my take is that the mandate of INIP is to
>
> 1. Study the current use of names and identifiers on the Internet
> (including, but not limited to the DNS)
> 2a. Identify issues with current naming systems - in particular
> incompatibilities between various systems.
> 2b. Identify gaps (e.g. bidirectional aliasing, or better protection
> for privacy, or context information such as localization or
> administrative boundaries) in the existing naming systems.
> 3. Architect a set of naming systems for the Internet (assuming that a
> single naming system will not suffice).
>
> and the purpose of this list is to discuss the issues in a broader
> audience than only the INIP members.
>
> Do we have any other documents than the INIP description
> <https://www.iab.org/activities/programs/names-and-identifiers-program/>and
> Ed's Internet Draft
> <https://tools.ietf.org/html/draft-lewis-domain-names-01> ?
>
> I will try to get my thoughts together and post something to the list.
>
> Gihan
>
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Jan 2016 15:20:54 -0500

On Thu, Jan 7, 2016 at 4:57 PM, Lyman Chapin <[email-masked]> wrote:

> In the course of working on another project, I assembled the following
> extended definition of "domain name space" in an attempt to (a) make the
> distinction between "the domain name space" and "domain names" clear, and
> (b) to encourage a bit more precision in the way in which we talk about
> domain names.
>
> In graph-theoretic terms, the domain name space constitutes a labelled
> directed rooted tree in which the syntax of the label associated with each
> vertex other than the unlabelled root is defined by RFCs 1035, 1123, and
> 2181. The term "nth level domain name label" refers to a member of the set
> of all vertices for which the path to the root contains n edges. For n=1
> the term most often used is "top level domain name label" or simply "top
> level domain" (TLD). A fully qualified domain name is a sequence of labels
> that represents a path from the root to a leaf vertex of the domain name
> space. The shorter term "domain name" is not formally defined; in common
> usage it may be the shorthand equivalent of "fully qualified domain name"
> (FQDN) or refer to any non-empty subset of the sequence of labels formally
> identified by a fully qualified domain name.
>
> In this formulation, the term "domain name space" refers to the complete
> graph consisting of all possible vertices and edges - not just those with
> which a specific meaning has been associated (what we might call
> "allocated" labels). It is a finite graph because the length of the longest
> possible FQDN is finite. At any point in time, there is another labelled
> directed rooted tree - a sub-graph of the domain name space - containing
> only vertices that represent allocated labels.
> ​
>

​
Poking the bear...

​This makes it sound like there is one domain name space of allocated
labels, and a graph with a single root.

This ignores things like:
+------------------+    +------------------+
|     My house     |    |   Your house     |
|                  |    |                  |
|        +-+       |    |        +-+       |
|        |.|       |    |        |.|       |
|        +++       |    |        +++       |
|         |        |    |         |        |
|      +--v--+     |    |      +--v--+     |
|      |local|     |    |      |local|     |
|      +--+--+     |    |      +--+--+     |
|         |        |    |         |        |
|   +-----v----+   |    |   +-----v----+   |
|   | _printer |   |    |   | _printer |   |
|   +----------+   |    |   +----------+   |
+------------------+    +------------------+​

It also ignores:
www.foo.bar.baz.example.com  where the example.com zonefile is:
$ORIGIN example.com.
*   IN A 192.0.2.1

In the first example, the names *do* come from a conceptual single root,
but you end up with 2 disjoint graphs - my .local is not the same as your
.local. While your definition may be technically correct (
https://www.youtube.com/watch?v=hou0lU8WMgo) it seems either incomplete, or
at least folk may be surprised...

In the second example, the "synthesized" vertices created at foo, bar and
baz *could* be claimed to "allocated" labels that exist for a very short
amount of time, but I think that this may be stretching things a bit far...

It feels like this definition works mainly for people who already
understand (and happen to have the same understanding as you and I :-))
what "the domain name space" and "domain names" are.

W

> ​
> So mathematically, a domain name is simply a sequence of labels. In most
> of the contexts in which we talk about, write about, or use domain names we
> add representational elements like "top to bottom" or "separating
> character," but those are not properties of a domain name.
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Lyman Chapin <[email-masked]>
Date: Fri, 8 Jan 2016 18:45:00 -0500

> labels, and a graph with a single root.

Yes, almost - there is one domain name space, but as a "space" it consists of the labelled directed rooted tree containing all possible vertices and edges, not just those that correspond to "allocated" labels. As the set of all possible well-formed labels is finite, and the maximum length of a FQDN is finite, the domain name space is finite, albeit very large. As a mathematical abstraction, it's useful for thinking (and talking) about domain names, but not very useful for most practical purposes.

> This ignores things like:

No, of course not:

                     Houses
                        |
                 +------+------+
                 |             |
             My house      Your house
                 |             |
                 v             v

etc.

> but you end up with 2 disjoint graphs

All subgraphs of a directed rooted tree are disjoint. That's a good thing :-)

> - my .local is not the same as your

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.

> amount of time, but I think that this may be stretching things a bit far...

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.

> what "the domain name space" and "domain names" are.

That would be redundant, I agree. The intention is for the definition to increase the number of people who understand what "the domain name space" and "domain names" are :-)

- Lyman

---

From: Avri Doria <[email-masked]>
Date: Sun, 10 Jan 2016 15:43:19 -0500

Hi,

Is this a definition specific to the IN class domain name space?

avri

On 08-Jan-16 15:20, Warren Kumari wrote:
>
>
> On Thu, Jan 7, 2016 at 4:57 PM, Lyman Chapin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > On 12/18/15, 7:05, "Olaf Kolkman" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     In the course of working on another project, I assembled the
>     following extended definition of "domain name space" in an attempt
>     to (a) make the distinction between "the domain name space" and
>     "domain names" clear, and (b) to encourage a bit more precision in
>     the way in which we talk about domain names.
>
>     In graph-theoretic terms, the domain name space constitutes a
>     labelled directed rooted tree in which the syntax of the label
>     associated with each vertex other than the unlabelled root is
>     defined by RFCs 1035, 1123, and 2181. The term "nth level domain
>     name label" refers to a member of the set of all vertices for
>     which the path to the root contains n edges. For n=1 the term most
>     often used is "top level domain name label" or simply "top level
>     domain" (TLD). A fully qualified domain name is a sequence of
>     labels that represents a path from the root to a leaf vertex of
>     the domain name space. The shorter term "domain name" is not
>     formally defined; in common usage it may be the shorthand
>     equivalent of "fully qualified domain name" (FQDN) or refer to any
>     non-empty subset of the sequence of labels formally identified by
>     a fully qualified domain name.
>
>     In this formulation, the term "domain name space" refers to the
>     complete graph consisting of all possible vertices and edges - not
>     just those with which a specific meaning has been associated (what
>     we might call "allocated" labels). It is a finite graph because
>     the length of the longest possible FQDN is finite. At any point in
>     time, there is another labelled directed rooted tree - a sub-graph
>     of the domain name space - containing only vertices that represent
>     allocated labels.
>     ​
>
>
>
> ​
> Poking the bear...
>
> www.foo.bar.baz.example.com <http://www.foo.bar.baz.example.com>
>  where the example.com <http://example.com> zonefile is:
> $ORIGIN example.com <http://example.com>.
> *   IN A 192.0.2.1
>
> In the first example, the names *do* come from a conceptual single
> root, but you end up with 2 disjoint graphs - my .local is not the
> same as your .local. While your definition may be technically correct
> (https://www.youtube.com/watch?v=hou0lU8WMgo) it seems either
> incomplete, or at least folk may be surprised...
>
> In the second example, the "synthesized" vertices created at foo, bar
> and baz *could* be claimed to "allocated" labels that exist for a very
> short amount of time, but I think that this may be stretching things a
> bit far...
>
> understand (and happen to have the same understanding as you and I
> :-)) what "the domain name space" and "domain names" are.
>
> W
>
>
>  
>
>     ​
>
>
>     So mathematically, a domain name is simply a sequence of labels.
>     In most of the contexts in which we talk about, write about, or
>     use domain names we add representational elements like "top to
>     bottom" or "separating character," but those are not properties of
>     a domain name.
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Jan 2016 18:24:57 -0500

> Is this a definition specific to the IN class domain name space?

That's an excellent question.  Sitting parked on my wet-drive (the thing
in between my ears before it comes out my fingers) is an I-D entitled,
"DNS CLASS Considered Useless"

If you read carefully the way CLASS is described, it turns out to
assume that the name tree is parallel.  If that is true, then some
things follow:

    1.  All names must subsist in all classes.
    2.  No name with a cross-class type can result in different
    resolution across classes.

If those are both true, then classes simply don't work, because of
[CD]NAME.  And if you think about the way the DNS is defined, this is
not surprising.

DNS is defined as a name space subordinate to which is the type and
class.  If classes worked, then the namespace would need to be
subordinate to class: you'd look up a name under a class with a
specific type.  But that's not how it is defined.

If you look at the very earliest namedroppers archives, actually, it
seems that this was very much the concern some commenters on DNS were
asking, though they didn't put it quite this starkly.  I think that
may be because they didn't yet have the experience with DNS that we
now do.  But I think those earliest questions were right on, and I
think that the complete failure of classes to take off is a pretty
good indication they were right.

I swore I'd submit that I-D before the end of 2015, but it's not even
been typed out yet.  I am still keen to make it happen.  I think we
should close the CLASS registry and admit that it's the appendix of
the DNS.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Lyman Chapin <[email-masked]>
Date: Sun, 10 Jan 2016 19:14:45 -0500

> Is this a definition specific to the IN class domain name space?

Not at this level - RFC 1034 talks about "parallel" namespaces "[b]ecause we want the name space to be useful in dissimilar
networks and applications" but the definition of the domain name space as a labelled directed rooted tree applies to any class-tagged instantiation of it. It will quickly become specific to the IN class space when we get beyond the label and include the resource records that are also "stored" at each node -

- Lyman

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 13 Jan 2016 09:05:21 -0500

Lyman,

> networks and applications" but the definition of the domain name space as a labelled directed rooted tree applies to any class-tagged instantiation of it. It will quickly become specific to the IN…

One of the reasons I liked your definition is that it sounds like it was intended to be useful well beyond specific characteristics of DNS protocol.

I suspect Andrew's right that CLASS can't really be made to work in any case, but it seems to me it's worth continuing to explore how well the namespace can be discussed separately from assumptions about resolution protocols, data stored at the described nodes, etc.

Suzanne

---

From: Lyman Chapin <[email-masked]>
Date: Wed, 13 Jan 2016 13:04:03 -0500

> One of the reasons I liked your definition is that it sounds like it was intended to be useful well beyond specific characteristics of DNS protocol.

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.

- Lyman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Jan 2016 19:28:25 +0000

Lyman's definition is technically correct ("The best kind of correct"),
but, yes, not necessarily satisfying - it is like a complex mathematical
proof showing that the shortest path between two points is a straight
line[0]. This is really important when needing to formally validate
something, but not so useful when trying to ask your plumber to run a new
line to the sink....

So, I decided to just start typing and see what fell out:
A namespace is all possible names that can be used to name "things" in a
class. It is often useful to a particular name to uniquely identify a
single thing.

The namespace we are interested in (at the moment :-)) is a subset of that
namespace which can be usefully used to name computers and similar things
on a network.

The domain namespace is a subset of the above, made up of sets of names
which follow specific patterns (LDH, 63 "letters" (octets), separated (in
display) form by '.' (handwave away IDNs)) - an example: www.foo.bar.example
.

This domain namespace is built like a tree - it has a root ('.') and a
bunch of branches, each one being a label - the above starts at the root,
then follows the 'example' branch to the 'bar' branch, to the 'foo' branch,
to the final leaf (www). There are pointers (called delegations) from each
level to all of the (existent) branches - these are implemented as a type
of data in the tree called nameserver records.

To make things simpler (!) there are a few additional types of labels /
records:
1: a wildcard ('*') - it can stand in for any label at a specific level in
the tree.
2: CNAME and DNAME - these provide pointers to other branches in the tree -
CNAME to a leaf, and DNAME to a completely different branch.

The "delegated" domain namespace is a further subset of the above - it
simply means the set of names that actually exist at a point in time (or
appear to exist at a point in time).
Ideally, the domain namespace is coherent - any user folloing a given path
should arrive at the same leaf.

The domain namespace is simply one instance of a namespace (although, by
far the most common one) - other namespaces can exist that follow
completely different semantics (for example, it could be argued that IP
addresses are a strictly hierarchical, non-flexible namespace). In summary:
A namespace is all possible names.
The domain namespace is all possible names that follow one specific set of
rules.
Domain names are (handwave) those names that actually exist.

[ This example is not nearly as accurate (I've oversimplified / possibly
flat out lied[1]) in a few places), as Lyman's graph model, but may be more
usable by the average plumber... ]

Perhaps we should simply fall back on "I shall not today attempt further to
define the kinds of names I understand to be embraced within that shorthand
description ["domain names"], and perhaps I could never succeed in
intelligibly doing so. But I know it when I see it, and 'www.example.com'
is one, and 'f#%4423' isn't" :-P

W
[0]: The first person who mentions great circle distance or non-Euclidean
spaces gets punched in the mouth...
[1]:  e.g domain name versus hostname.

On Wed, Jan 13, 2016 at 1:04 PM Lyman Chapin <[email-masked]> wrote:

> >> Not at this level - RFC 1034 talks about "parallel" namespaces
> "[b]ecause we want the name space to be useful in dissimilar
> >> networks and applications" but the definition of the domain name space
> as a labelled directed rooted tree applies to any class-tagged
> instantiation of it. It will quickly become specific to the IN class space
> when we get beyond the label and include the resource records that are also
> "stored" at each node -
> >
> > One of the reasons I liked your definition is that it sounds like it was
> intended to be useful well beyond specific characteristics of DNS protocol.
>
> 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.
>
> - Lyman
>
> >
> > I suspect Andrew's right that CLASS can't really be made to work in any
> case, but it seems to me it's worth continuing to explore how well the
> namespace can be discussed separately from assumptions about resolution
> protocols, data stored at the described nodes, etc.
> >
> >
> > Suzanne
> >
>

---

From: Lyman Chapin <[email-masked]>
Date: Wed, 13 Jan 2016 17:05:21 -0500

> something, but not so useful when trying to ask your plumber to run a new

I don't think I agree with your analogy, because the important distinction is not between formal (mathematical proof) and informal/practical (instructions to the plumber); it's between identity and meaning. The namespace of interest here is organized in a specific way, as a labelled directed rooted tree; that's a deliberate choice that suits the purposes of the domain name system, but might be a poor choice for some other name space intended for some other purpose.

[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.]

Defined in that specific way, with unambiguous rules for the construction of syntactically valid labels and ordering them in sequences (domain names), the domain name space gives us the means to identify (associate a domain name with) any point in the tree. That's the identity part. But identity, wonderful as it is, doesn't invest those well-identified points with meaning (except perhaps of the "I am, therefore I am" variety). The protocol apparatus of the DNS does that, using resource records to encode meaning, zonefiles to link identity (domain name) to meaning, and name servers and resolvers to "read out" the encoded meaning during protocol processing.

Name resolution systems other than the DNS, of course, could invest the same well-identified points in the same tree with different meanings, using the same or different mechanisms (RRs, zonefiles, etc., or something else). Ambiguity would arise only (only! hah) if two or more systems associated the same identity with different meanings. In practice, that ambiguity would be most problematic if different systems used the same mechanisms to associate domain name space identities with different meanings.

That's more or less what we're dealing with in this discussion. The label "local" at the top level of a domain name would be associated with one meaning by the DNS and a different meaning by mDNS (although in specific configurations unicast DNS lookups can be tweaked to produce the same result). As an identifier, "local" is a valid ordinary label in the domain name space; but because we decided that it would be useful to let both DNS and mDNS operate with the same mechanisms on the same names, we allow RFC 6762 to associate a non-ordinary meaning with "local": "Any DNS query for a name ending with the label '.local.' MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)." This turns "label" into a processing directive (switch). Nothing new here; I'm sure all of this is in the problem statement for the dnsop special names design team.

This may sound like a pleonastic attempt to prove that the shortest distance between two points is (etc.), but that's not my intention - I think it would be valuable to start the search for a way out of the 6761 hole with a clear understanding of how we got into the hole in the first place, before we start designing procedures for evaluating "special names." (The slide titled "Name Space != DNS" in Alain and Peter's 6761bis deck seems to be leaning in that direction.) Special names are absolutely ordinary as domain name space labels (identifiers) - they are "special" only to the machinery that extracts meaning from domain names during a processing operation. (I was tempted to mention the Velveteen Rabbit here, but wisely decided not to.) There may be no realistic alternative to the current model in which specific labels are overloaded with switch semantics, but recognizing that as a processing artifact - not a name space artifact - at least leaves the question open.

- Lyman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Jan 2016 17:40:56 -0500

On Wed, Jan 13, 2016 at 01:04:03PM -0500, Lyman Chapin wrote:
 
> (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 recently-published terminology RFC attempts to point out this
latent distinction in just a couple places, FWIW.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Jan 2016 17:43:32 -0500

On Wed, Jan 13, 2016 at 07:28:25PM +0000, Warren Kumari wrote:
> class.

This already fails in our case, if you mean "class" in the way DNS does.

(I'll return to this thread when I have more time, but this already
shows how existing terminology makes our life hard.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 13 Jan 2016 17:49:15 -0500

> I don't think I agree with your analogy, because the important distinction is not between formal (mathematical proof) and informal/practical (instructions to the plumber); it's between identity and…

Does Section 1.1 of RFC 2826 ("Maintenance of a Common Symbol Set") help at all here?

Suzanne

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Jan 2016 23:14:40 +0000

> This already fails in our case, if you mean "class" in the way DNS does.

Nope, I did not mean it in the way the DNS does - more "a set or category
of things having some property or attribute in common and differentiated
from others by kind, type, or quality.". I was thinking of putting in a
footnote mentioning this, but the point of the definition was that it
should be easily read and understood by someone unfamiliar with the A:
namespaces and B: the DNS.

> shows how existing terminology makes our life hard.)
You, sir, are a class[0] act, and are definitely in a different class[1] to
myself...
Terminology is hard, let's go shopping...

W
[0]: "showing stylish excellence."
[1]: "the system of ordering a society in which people are divided into
sets based on perceived social or economic status."

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 14 Jan 2016 10:17:02 +0100

> 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…

Hmm… but I thought we were discussing the syntax of the name-space. It seems that we then arrive at 3 things that all hook together: syntax, namespace, and resolution protocol.

The Internet DNS namespace is specifically defined through the resolution system starting at the IANA root. To first approximation it is the hints file used at the resolver that defines the name-space.

I lost track of the question that we are trying to answer? Ed, is there some underlying thing you want to arrive at? Do you want to arrive at a precise definition of Domain names or do you want to solve the confusion that arrives from identifiers that look like domain names?

—Olaf

- - -
Olaf Kolkman                                                         [email-masked]
Chief Internet Technology Officer
Internet Society                                                     www.internetsociety.org
                                                                     LinkedIn: OlafKolkman
                                                                     Twitter: @Kolkman
- - -

---

From: Lyman Chapin <[email-masked]>
Date: Thu, 14 Jan 2016 09:11:54 -0500

> Hmm… but I thought we were discussing the syntax of the name-space. It seems that we then arrive at 3 things that all hook together: syntax, namespace, and resolution protocol.

A domain name that identifies a point within the domain name space has a syntax, but the name space itself does not. Syntax is a set of rules that govern the structure of (in this case) domain names - the composition of labels, and how they may be ordered. The domain name space is just a labelled directed rooted tree, a math/graph construct that doesn't have (or need) a syntax. (I apologize for the way in which this sounds "preachy" - I'm just trying to be as precise as possible in the way in which these terms are used.)

> The Internet DNS namespace is specifically defined through the resolution system starting at the IANA root. To first approximation it is the hints file used at the resolver that defines the name-sp…

The domain name space is explicitly (going back to RFC 1034) not defined by the DNS resolution system. If it's useful to do so, we can define the "Internet DNS namespace" to be the domain name space overlaid with the semantics expected by the resolution system (servers and resolvers). But that would assume an answer to at least one of the questions we're still discussing: "if it is resolved by something other than the DNS, is it a domain name?"

> I lost track of the question that we are trying to answer? Ed, is there some underlying thing you want to arrive at? Do you want to arrive at a precise definition of Domain names or do you want to…

I believe that "precise definition" will help us remove that confusion - but if I'm just adding to it, you (or Ed, or anyone else) should feel free to tell me -

- Lyman

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 15 Jan 2016 11:43:28 +0100

> The domain name space is explicitly (going back to RFC 1034) not defined by the DNS resolution system. If it's useful to do so, we can define the "Internet DNS namespace" to be the domain name spac…

Aha…

I conceptually I always thought there are multiple domain name spaces where each names space is internally consistent (In the context of alternate roots: different root-hints implies different namespace). So for me name-spaces are plural. When you talk about the domain namespace I note you talk about as singular.

In your definition you say "The domain name space constitutes a labelled directed rooted tree" I guess the specifics of that root are important. I tend to think of my.server.in.my.home as being part of a different name-space as the isoc.org in my email address.
Both seem to be captured under your definition. Correct?

So perhaps as a question: Does your definition allow for multiple namespaces, do we want a definition to allow for multiple namespaces.

—Olaf

- - -

---

From: Warren Kumari <[email-masked]>
Date: Fri, 15 Jan 2016 19:03:06 +0000

On Fri, Jan 15, 2016 at 5:43 AM Olaf Kolkman <[email-masked]> wrote:

> Hmm… but I thought we were discussing the syntax of the name-space. It
> seems that we then arrive at 3 things that all hook together: syntax,
> namespace, and resolution protocol.
>
>
> A domain name that identifies a point within the domain name space has a
> syntax, but the name space itself does not. Syntax is a set of rules that
> govern the structure of (in this case) domain names - the composition of
> labels, and how they may be ordered. The domain name space is just a
> labelled directed rooted tree, a math/graph construct that doesn't have (or
> need) a syntax. (I apologize for the way in which this sounds "preachy" -
> I'm just trying to be as precise as possible in the way in which these
> terms are used.)
>
>
>
> The Internet DNS namespace is specifically defined through the resolution
> system starting at the IANA root. To first approximation it is the hints
> file used at the resolver that defines the name-space.
>
>
> The domain name space is explicitly (going back to RFC 1034) not defined
> by the DNS resolution system. If it's useful to do so, we can define the
> "Internet DNS namespace" to be the domain name space overlaid with the
> semantics expected by the resolution system (servers and resolvers). But
> that would assume an answer to at least one of the questions we're still
> discussing: "if it is resolved by something other than the DNS, is it a
> domain name?"
>
> Aha…
>
> I conceptually I always thought there are multiple domain name spaces
> where each names space is internally consistent (In the context of
> alternate roots: different root-hints implies different namespace). So for
> me name-spaces are plural. When you talk about the domain namespace I note
> you talk about as singular.
>
> In your definition you say "The domain name space constitutes a labelled
> directed rooted tree" I guess the specifics of that root are important. I
> tend to think of my.server.in.my.home as being part of a different
> name-space as the isoc.org in my email address.
> So perhaps as a question: Does your definition allow for multiple
> namespaces, do we want a definition to allow for multiple namespaces.
>

... and I have a larger / meta question.
Much of this discussion seems to have turned into deep navel gazing.

Let's pretend for a bit that we come up with a perfect definition of
"namespace" and "domain namespace". It's clean, it's pretty, it's
understandable by the average monkey....
Great. Now what?

Does this somehow help solve the underlying issues? Do we have a clear
description of what the underlying issues actually *are*? Who uses this
definition? Where? How?

Yes, having a definition so that we all know what we are talking about is
useful; it's like having a good tool in our toolbox, but what are we
actually going to build with this tool? Who has the plans?

W

—Olaf
>
> ------------------------------
> Olaf M. Kolkman
> Chief Internet Technology Officer Internet Society
> <http://www.internetsociety.org/>
> e-mail: [email-masked]
> LinkedIn:OlafKolkman <https://nl.linkedin.com/in/olafkolkman>
> Twitter: @Kolkman <https://twitter.com/kolkman>
> ------------------------------
>

---

From: Lyman Chapin <[email-masked]>
Date: Fri, 15 Jan 2016 16:32:22 -0500

> Both seem to be captured under your definition. Correct?

Yes. Whatever software you use to resolve my.server.in.my.home knows how to do it because it implements the same understanding of the LDRT structure and label syntax of the domain name space as the software that resolves isoc.org. The database that supplies the semantics may be different, but it's the same domain name space - labels have to follow the same rules with respect to allowable characters and length, they have to be ordered in a sequence that represents a directed path to the root, etc.

> So perhaps as a question: Does your definition allow for multiple namespaces, do we want a definition to allow for multiple namespaces.

Not in the sense in which I think you mean "multiple namespaces." When you put "local" or "home" in the TLD position of a domain name, you haven't left the domain name space. What you've done is added some additional semantics to the name - the directive (protocol switch) to resolution software to "do something special" that it wouldn't do otherwise. In the case of "local" or "home," that directive is presumably (in simple terms) "use mDNS". That's not a name space issue, it's a protocol issue.

To avoid duplication I'll pick up from there in my reply to Warren's question "Does this somehow help solve the underlying issues?" -

- Lyman

---

From: Lyman Chapin <[email-masked]>
Date: Fri, 15 Jan 2016 17:32:40 -0500

> Much of this discussion seems to have turned into deep navel gazing.

Is that a particularly intense form of the well-defined activity of gazing at navels, or an unspecified level of interest in gazing at a subclass of navels that have the property "deep"? Be precise, man! :-)

> understandable by the average monkey....

The point of the definition is not to be perfect, but to be useful. If you establish (by definition, which in this case begins with RFC 1034) that the domain name space is a LDRT with [L]abels that adhere to a specific well-defined syntax, you can use that to structure and constrain the discussion that really matters, which is indeed your "now what?"

Because it's the rules and procedures for domain name resolution that add meaning (semantics) to domain names - which in themselves are simply sequences of labels directed to the root of the domain name space, with no intrinsic meaning - we can start by saving ourselves the time and effort necessary to pursue any discussion that invokes "multiple namespaces." We have a protocol (semantic) problem, not a problem with the domain name space or the syntax of its labels. That seems like a valuable, tangible, and practical benefit of having a good definition - we know something useful about where to go looking for a solution to the problem of what we've been calling "special names." It's not the names as identifiers that are special - they follow all of the composition rules, and are as ordinary as any other name in the domain name space - it's what we want them to mean to the protocol machinery that manipulates them.

I understand your argument to be that until we get to the specification of the semantics, we have nothing that we can actually work with, so we might as well start at the point at which the domain name space is associated with the specific semantics of the DNS, and simply call that the "domain name space." But as I pointed out in an earlier reply to Olaf, that puts you past the point at which you can meaningfully ask "can some resolution system other than the DNS associate a different semantics with the domain name space?" And the problem we have right now is that different other systems are "not-DNS" in different ways - the .onion case is not the same as the .local case, much less the YetiDNS case. All of them, in fact, rely on the idea that they can be entirely "DNS" in most respects, but observe a specific exception to the semantics that the DNS associates with domain names - because there's a lot of convenient software out there that implements the "DNS" semantics, so the more your stuff looks just like that, the shorter your product development time (and user learning curve) can be.

So we want these "special names" to behave normally with respect to DNS resolution right up to the point at which they hit their special switch - and at that point, we want the resolution process to do something different. It's the switch point in processing that matters, not the name; so I would be inclined to look for solutions in the RRsets that direct the resolution process, not in the names of the zones.

However, because a "special name" is a piece of the commonly shared domain name space, the political question "who gets to have one?" is not answered by any solution to the technical problem of implementing the processing switches that would be required to create the "special" behavior. The bar for reserving a special name should be very high, and higher the more it burdens everyone else. But now we're at a different layer of the reference model :-)

- Lyman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Jan 2016 16:15:03 +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" <[email-masked]> 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:

>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"
<[email-masked] on behalf of [email-masked]> 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"
<[email-masked] on behalf of [email-masked]> 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.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 22 Jan 2016 16:40:09 +0000

My in-box is a mess[0], I just found this looking for another message.  So
my response to this is terribly delayed.

[0] - I'm using an up-to-date commercial email reader that apparently
cannot correctly sort by date. ;)

On 1/7/16, 16:57, "Lyman Chapin" <[email-masked]> wrote:

>directed rooted tree in which the syntax of the label associated with
>each vertex other than the unlabelled root is defined by RFCs 1035, 1123,
>and 2181. The term "nth level domain name label" refers to a member of
>the set of all vertices for which the path to the root contains n edges.
>For n=1 the term most often used is "top level domain name label" or
>simply "top level domain" (TLD). A fully qualified domain name is a
>sequence of labels that represents a path from the root to a leaf vertex
>of the domain name space. The shorter term "domain name" is not formally
>defined; in common usage it may be the shorthand equivalent of "fully
>qualified domain name" (FQDN) or refer to any non-empty subset of the
>sequence of labels formally identified by a fully qualified domain name.

A clarifying question - (is) this definition specific to names in the DNS?

The reason I ask is that I believe that only within the DNS is the name
space finite and that is because the DNS is defined for a 1980's-era code
base.  (I.e., fixed widths, static limits on space.)

>"allocated" labels). It is a finite graph because the length of the
>longest possible FQDN is finite. At any point in time, there is another
>labelled directed rooted tree - a sub-graph of the domain name space -
>containing only vertices that represent allocated labels.
>
>of the contexts in which we talk about, write about, or use domain names
>we add representational elements like "top to bottom" or "separating

I completely agree.  With all of that - sequence/separating character/not
pragmatic.

A question rolling in my mind is - do we want to offer something a few
steps away from mathematic towards pragmatic?  Like - are IETF(tm) Domain
Names things that have ... dots between labels and other constraining
elements?  (Using "dots between labels" as an example.)

---

From: Avri Doria <[email-masked]>
Date: Fri, 22 Jan 2016 15:02:50 -0500

thanks for all the repsonses on my question

> CLASS when coming to a definition of Domain Names.

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?

Also,
Is the definition of names in this only related to DNS usage?

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).

Or am I making some sort of category error?

avri

---

---

From: Edward Lewis <[email-masked]>
Date: Fri, 22 Jan 2016 20:40:28 +0000

>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.
>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.

>Internet domain names (though of course they can use same syntax if they

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jan 2016 17:49:56 -0500

> CLASS vestigial and a DNS artifact, not a Domain Name core concept.

The unwritten draft in my head, "CLASS Considered Useless", will make
exactly this argument.  BTW, it's not just oral history.  I have found
this argument in the very earliest part of the namedroppers archives.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jan 2016 17:51:27 -0500

On Fri, Jan 22, 2016 at 03:02:50PM -0500, Avri Doria wrote:
> standard RR types ignored it.

The standard RR types don't ignore it.  A is defined only for IN, for instance.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 22 Jan 2016 18:51:10 -0500

> this argument in the very earliest part of the namedroppers archives.

Part of the problem here, it seems to me, is that we've gotten this far without a definition of "domain name" except what we can find implicitly in certain protocol definitions-- but nonetheless there's a concept that has developed over time, one attribute of which is that it's consistent in certain desirable ways across multiple possible resolution protocols. This assumption is being used in new protocol development, without being explicit.

This has been making me wonder if it's necessarily possible to get a coherent definition of "domain name" at all, which is why I was happy to see the definition Lyman proposed. 

To answer Warren's question a few days ago, I think that if we can get general agreement on a definition, even one so abstract that it doesn't tell us very much about how to do anything immediately useful, we can use it to reason about the attributes the domain name space actually has-- and what attributes people might think it has, perhaps incorrectly or inconsistently. 

In my dreams this leads to some notions about what kinds of protocols could reasonably re-use domain name abstractions for naming, when we might actually want to stick to DNS as the wire protocol, and when we might want to do something entirely different. See Ed's domain-name draft and:

https://datatracker.ietf.org/doc/draft-hardie-resolution-contexts/
https://www.ietf.org/mailman/listinfo/arcing

Suzanne

---

From: Lyman Chapin <[email-masked]>
Date: Sat, 23 Jan 2016 15:49:17 -0500

> base.  (I.e., fixed widths, static limits on space.)

If we maintain (at least for the sake of argument) a distinction between the "domain name space" and the "domain name system", then the domain name space is defined by (a) its mathematical structure as a LDRT, and (b) the generation rules for syntactically valid labels. The generation rules may be the product of 1980s-era constraints, but they apply today as much as they did then - that is, no one has suggested that we change the rules to allow longer labels, or longer sequences of labels (domain names) - so the domain name space is finite independent of the way in which the protocols of the domain name system associate semantics with domain names. Obviously we wouldn't have these specific generation rules for domain name labels if we hadn't developed them in the context of the domain name system - the labels have a maximum length of 63 LDH characters because that maximum length, with an assumed ASCII-octet encoding, was determined to be "just right" for all of the reasons described in RFC 1034 - and the early specs routinely refer to the domain name space as a component of the DNS (see for example Section 2.4 of RFC 1034). But even the early specs distinguish the domain name space ("specifications for a tree structured name space") from another component of the DNS - resource records ("data associated with the names"). The domain name space is just names (identifiers); the data associated with the names are not themselves part of the domain name space.

> elements?  (Using "dots between labels" as an example.)

That question is on my mind too!

(1) We can talk about a domain name without specifying where and how the data associated with that name are stored, or served in response to queries. The domain name is clearly an identifier; it is not equivalent to a zone file, which is an implementation-specific (RFC 1035) way in which to store the data associated with a name. The domain name may appear in an $ORIGIN directive or SOA RR within the zone file, but the domain name is not the zone file.

(2) How should we think about the use of the "dot" character to mark the boundary between labels in a domain name when the name is represented as text? (We certainly don't store the "dot" in the internal data structures that hold domain names, other than those that are used explicitly for the purpose of displaying domain names for human users.) It's amusing to see the "dot" in written representations of IDN domain names that use scripts in which there is no "dot" character (which doesn't matter after the punycode conversion, of course).

(3) It seems to me that what is particular to the DNS is therefore not domain names (RFC 1034: "The terms 'domain' or 'domain name' are used in many contexts beyond the DNS described here. Very often, the term domain name is used to refer to a name with structure indicated by dots, but no relation to the DNS.") but zone files - the data (meaning) associated with domain names. We might postulate (I don't assert this): For a name that is intended to be both an identifier and a directive - local, for example, or onion - the domain name satisfies only the "identifier" part; the directive part ("do this instead of that" in the course of name resolution) should be encoded in the zone file. Another way to put it would be to say that we should use the zone file to encode the protocol switch semantics that we want to associate with a name rather than putting the name into a special names registry.

Such a postulate might or might not be consistent with our search for something "pragmatic" - I'm not sure yet where to take it. It might mean that for a name like "local" the switch to mDNS would be encoded as a zone file directive rather than embedded in the resolver code. One consequence of going down that path would be the opportunity to make the simplifying assertion that every well-formed (syntactically correct) domain name can be processed by the resolution protocol of the DNS. It might be kicked out to some other resolution system when the DNS resolver hit a switch directive, but there would be no need to have special-case code in the resolver to deal with every possible type of switch.

- Lyman

---

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Jan 2016 19:43:34 +0000

On 1/23/16, 15:49, "Lyman Chapin" <[email-masked]> wrote:

>If we maintain (at least for the sake of argument) a distinction between
>the "domain name space" and the "domain name system", then the domain
>name space is defined by (a) its mathematical structure as a LDRT, and
>(b) the generation rules for syntactically valid labels. The generation
>rules may be the product of 1980s-era constraints, but they apply today
>as much as they did then - that is, no one has suggested that we change
>the rules to allow longer labels, or longer sequences of labels (domain
>names) - so the domain name space is finite independent of the way in
>which the protocols of the domain name system associate semantics with
>domain names. Obviously we wouldn't have these specific generation rules
>for domain name labels if we hadn't developed them in the context of the
>domain name system - the labels have a maximum length of 63 LDH
>characters because that maximum length, with an assumed ASCII-octet
>encoding, was determined to be "just right" for all of the reasons
>described in RFC 1034 - and the early specs routinely refer to the domain
>name space as a component of the DNS (see for example Section 2.4 of RFC
>1034). But even the early specs distinguish the domain name space
>("specifications for a tree structured name space") from another
>component of the DNS - resource records ("data associated with the
>names"). The domain name space is just names (identifiers); the data
>associated with the names are not themselves part of the domain name
>space.

At one time I would have completely agreed, but.

I'll start out with, I can see the logic and sense in declaring the name
space to be finite via limiting the overall length of the names.  While
writing the draft, someone pointed out that there exists today a place
where names with labels longer "work in code".  That is in the /etc/hosts
file.  It does work, FWIW. This called to mind past experience with BSD
Sockets using AF_UNIX, where names aren't bound by the DNS documented
lengths.

The first thought is "those are out of scope" but it makes me then want to
define the scope.  I mean, I could see them being out of scope as they are
arcane cases - but then there's a need to name the scope.

Here's a working example between some machines in my house:

$ more /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost
192.168.1.166   
123456789112345678921234567893123456789412345678951234567895123456789612345
67897123456789.example

And

$ ssh 
elewis@12345678911234567892123456789312345678941234567895123456789512345678
961234567897123456789.example
Last login: Mon Jan 25 14:30:56 2016 from otherhost.example

But

$ dig 
123456789112345678921234567893123456789412345678951234567895123456789612345
67897123456789.example
dig: 
'12345678911234567892123456789312345678941234567895123456789512345678961234
567897123456789.example' is not a legal name (label too long)

So, works for SSH, not for DiG.

>(3) ...We might postulate (I don't assert this): ... we [c]ould use the
>zone file to encode the protocol switch semantics ... One consequence of
>going down that path would be the opportunity to make the simplifying
>assertion that every well-formed (syntactically correct) domain name can
>be processed by the resolution protocol of the DNS.

My first reaction is that this might irk the sensibilities of those who
proposed "onion" (to apply a poor label for the time being).  The issue is
whether the name would be exposed "too much".  I'm unsure of this issue
and am poorly framing it in my mind.  In a way, the code handling the name
ought to have some autonomy in how it resolves the name, in case the code
is, well, paranoid (to again use a poor label).

In sum to this message, the thoughts here keep the DNS "in charge" of the
name handling.  I've been walking down a path to avoid that.  That is not
to imply I think keeping DNS "in charge" is wrong or that there's
someother workable path.  This is only to imply that I've just been
considering a different approach - which may not turn out to be pragmatic.

Ed