Re: [Inip-discuss] Domain Names

[Lyman Chapin <[e-mail]>]

On Jan 13, 2016, at 2:28 PM, Warren Kumari wrote:

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

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

> 
> 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 <[e-mail]> wrote:
> 
>> 
>> On Jan 13, 2016, at 9:05 AM, Suzanne Woolf wrote:
>> 
>>> Lyman,
>>> 
>>> On Jan 10, 2016, at 7:14 PM, Lyman Chapin <[e-mail]> wrote:
>>> 
>>>> 
>>>> On Jan 10, 2016, at 3:43 PM, Avri Doria wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> 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 -
>>> 
>>> 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
>>> 
>> 
>> _______________________________________________
>> Inip-discuss mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/inip-discuss
>>