Re: [Inip-discuss] Domain Names

[Edward Lewis <[e-mail]>]

On 1/23/16, 15:49, "Lyman Chapin" <[e-mail]> 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