Re: [Inip-discuss] Domain Names

[Warren Kumari <[e-mail]>]

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