Subject: [DNSOP] draft-lewis-domain-names-00.txt

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Sep 2015 19:58:54 +0000

Don't know if this will be posted to DNSOP some other way.

(I've gotten one private comment, so it's been announced somewhere,
someway.)

On 9/17/15, 13:50, "[email-masked]" <[email-masked]>
wrote:

>Name:		draft-lewis-domain-names
>Revision:	00
>Title:		Domain Names
>Document date:	2015-09-17
>Group:		Individual Submission
>Pages:		13
>URL:            
>https://www.ietf.org/internet-drafts/draft-lewis-domain-names-00.txt
>Status:         https://datatracker.ietf.org/doc/draft-lewis-domain-names/
>Htmlized:       https://tools.ietf.org/html/draft-lewis-domain-names-00
>
>
>Abstract:
>This document states a definition of Domain Name beyond the use of
>the term within the Domain Name System.  The document includes a
>survey of the diverse ways Domain Names have been interpreted within
>various protocols over time.  The purpose of this is to give a solid
>foundation for work on Domain Names across all protocols making use
>of Domain Names.

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Thu, 17 Sep 2015 21:03:47 +0000

Ed,
	I find the document useful, and illuminating, but that it suffers from one glaring omission -- no substantive discussion of the relationship between domain names and URIs (the related term "URN"[1] is mentioned in Section 1.2, but never expanded upon). To be sure, while the "Authority" component of a URI is not *always* based on a DNS name (or a "domain name", as distinguished in your Draft), it _usually_ is, and RFC 3986, aka STD 66, makes the relationship quite explicit:

"However, a globally scoped naming
system, such as DNS fully qualified domain names, is necessary for
URIs intended to have global scope. URI producers should use names
that conform to the DNS syntax, even when use of DNS is not
immediately apparent ..."

So, names in URI "Authority"s should *look* like DNS-style FQDNs, even if some other "Authority" resolution-and/or-uniqueness-guaranteeing mechanism underpins the particular Scheme. 

Since URIs are so commonplace in modern communication mechanisms (including one little app called web browsing :-), I think the tie-in between URIs and domain names should at least be mentioned in a comprehensive "domain names" document.

														- Kevin

[1] As per STD 66: "Future specifications and related documentation should use the general term 'URI' rather than the more restrictive terms 'URL' and 'URN'".

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Thursday, September 17, 2015 3:59 PM
To: dnsop
Subject: [DNSOP] draft-lewis-domain-names-00.txt

On 9/17/15, 13:50, "[email-masked]" <[email-masked]>
wrote:

>This document states a definition of Domain Name beyond the use of the 
>term within the Domain Name System.  The document includes a survey of 
>the diverse ways Domain Names have been interpreted within various 
>protocols over time.  The purpose of this is to give a solid foundation 
>for work on Domain Names across all protocols making use of Domain 
>Names.

---

From: George Michaelson <[email-masked]>
Date: Fri, 18 Sep 2015 10:16:15 -0300

My private comment bears repeating in public.

DOMAIN names is about the property of domains. Domains are encompassing,
set-theory/venn-diagram style. A domain and a prefix are analogous
concepts. One is expressed syntactically somehow, the other is a
mathematical property of bounding in a number field but they have the same
basic behaviour.

the UK domain order in coloured book mails obeyed this property: it just
used reverse semantics to the ARPA model.

XXXXXXXX.onion is *not* a domain name inside the .onion part: as I
understand it, the value is a hash, or other function which has no nesting
properties expressed syntactically.

This quality of domain names, the concepts of domains, is a distinct
property which bears thinking about.

HOST.TXT was not a domain system, it was a linear map. Honey Danber had
some qualities of domain-ness. Usenet groups after the great mod.*
 reordering became more domain like.

On Thu, Sep 17, 2015 at 4:58 PM, Edward Lewis <[email-masked]>
wrote:

> >Status:
> https://datatracker.ietf.org/doc/draft-lewis-domain-names/
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Sep 2015 13:39:49 +0000

>My private comment bears repeating in public.

That's good...

>mathematical property of bounding in a number field
> but they have the same basic behaviour.
>
>understand it, the value is a hash, or other function which has no
>nesting properties expressed syntactically.
>

So, it's true that the word "domain" has other meanings, it wasn't coined
for the use evident in RFCs (and other documents).

I went through a similar discussion early in the preparation of RFC 4594
"The Role of Wildcards in the Domain Name System".  Initially it was
"Clarifications on Wildcards" which ran into the question of "if you have
to redefine them, it's not a clarification."  Next the objection was that
I'd initially written that Wildcards was the way to do record synthesis in
the DNS.  The objection was well founded, Wildcards are *a* way to do
record synthesis, and the only possible means unless we ditch or seriously
alter AXFR.  (That discussion began my interest in that topic.)

There have been other things called domains before, and domain names.
It's clear from reading the old (pre-1000) RFCs that there was "science"
going on that was unrecorded in the RFC series.  This document is by no
means able to capture that - yet, until I get some reference material.

So - look at this document as trying to define "Domain Names" as they
appear in IETF, RFC-documented protocols.  With the document about the
interoperability of the IETF's use of "Domain Names."  Perhaps the title
should be "IETF(tm) Domain Names". ;)

In summary, your point is taken that there's a wider scope to the topic.
There has to be, I don't think anyone had a nightmare one night and the
DNS was born.  The goal here is to establish a basis for how we extend the
way Domain Names appear in Internet technologies - not just IETF, but
hopefully one in the same even if there's a lag.  From experience I won't
set as a goal a way to unify how all protocols use Domain Names - that has
long since passed, the protocols are working fine, there's no need to
restructure code for the sake of documentation.  But there's a need to
look at the forward path.

Ed

PS - My work is based, except where noted, on what is recorded in the
RFCs.  I know that the RFCs aren't all encompassing but I wasn't "in the
room" so have no other input to add.  (I know this from being "in the
room" and seeing the resulting RFC lacking some important detail.)  If
others were in the room and have other points of data to supply, please do
so - preferably with a citable reference.

---

From: Alec Muffett <[email-masked]>
Date: Fri, 18 Sep 2015 13:54:34 +0000

> On Sep 18, 2015, at 14:16, George Michaelson <[email-masked]> wrote:
> 
> DOMAIN names is about the property of domains. Domains are encompassing, set-theory/venn-diagram style. A domain and a prefix are analogous concepts. One is expressed syntactically somehow, the other is a mathematical property of bounding in a number field but they have the same basic behaviour.
> 
> the UK domain order in coloured book mails obeyed this property: it just used reverse semantics to the ARPA model.
> 
> XXXXXXXX.onion is *not* a domain name inside the .onion part: as I understand it, the value is a hash, or other function which has no nesting properties expressed syntactically.

Hi, my name's Alec, I work for Facebook and lead the engineering team for Facebook over Tor.

You are certainly correct that the label immediately left of ".onion" is a hash, and functions not unlike a layer-3 address; however, there may be other labels leftwards of the hash, under (to some extent) other administrative control.

The canonical example of this would be: www.facebookcorewwwi.onion <http://www.facebookcorewwwi.onion/> versus m.facebookcorewwwwi.onion versus… well, anything.you.like.sixteencharshash.onion.

With onion addressing it's all a matter of whether the layer 7 protocol honours the symbolic name that it has been given (eg: www.facebookcorewwwi.onion <http://www.facebookcorewwwi.onion/>) and passes it to the server via metadata (eg: HTTP "Host:" header) rather than a delegated and differentiated address lookup.

I feel this may need clarification in your section on Tor addressing.  Perhaps it's not **really** domain-naming, but it **looks** much more like it.

Also, there is some information which requires correction:

According to an email message, ".onion" names may (in the future)
exceed the length limits of a label imposed on DNS domain names,
reaching 64, 80, or more bytes. [DNSOP1]

Per this e-mail:

https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html <https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html>

...from Nick Mathewson at Tor, he says:
So it's IMO fine to say ".onion addresses are case-insensitive and
will comply with existing DNS limitations for label lengths (63) and
maximum fqdn lengths (253ish)".
Which contradicts draft-lewis-domain-names-00

Also, my name's not "Alex" :-)

    - alec

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Sep 2015 14:04:52 +0000

On 9/18/15, 9:54, "Alec Muffett" <[email-masked]> wrote:
> 
> I feel this may need clarification in your section on Tor addressing.  Perhaps
> it's not **really** domain-naming, but it **looks** much more like it.

The first point of the document is to allow us to answer that "perhaps" -
without a definition of Domain Names, we don't know.  The question includes
- are "Domain Names" just things that look like something  or are they
things that have a lot of baggage (such as means of assignment [which is
different between DNS and distributed hash tables]).

I'm not disagreeing, just underlining that until the definition is in place,
it's hard for me to be in complete agreement.
> https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html
> 

So - and not to be pointed - but in your email I reference, should I ignore
that for the sake of this document?  I mean what the message says seems to
contradict what you are quoting from Mathewson - which is fine - but this is
something unclear to me.

(I wasn't aware of Mathweson's message, I'm not subscribed to that list.)

> Also, my name's not "Alex" :-)

I got 75% of the name right. ;)  Sorry about that - I don't read all the
letters on a page.

---

From: George Michaelson <[email-masked]>
Date: Fri, 18 Sep 2015 11:12:12 -0300

I think its possible I'm arguing off to the side Ed. But, there was a
scoping quality in domain, as applied to domain names, which is pretty
"big" in my opinion. Its analogous to the ordering issues in fully
qualified (relative) distinguished names in X.500. The order of elements of
Surname= Given= Generational-Qualifier= were perhaps moot, but the nesting
qualities of C= and O= and OU= were not. It was pretty clear (mistakenly?)
to me that you might be able to re-order the S/G/GQ elements in a wildcard
match inside some O=/OU= local context, but searching for all CN=*Smith* at
the C= level was going to be a hard ask.

So this quality of the word 'domain' is not in my mind, just hand waving.
Its innate. The decision to make the dot separator function as both a label
boundary, and potentially a zone-cut, has consequences. a putative FQDN is
like a Relative Distinguished name, except you can't know where the
zone-cut is a-priori, until you get some information back.

AppleTalk names were interesting, structured. They got some ideas from VMS
(or seemed to) which I suspect also were ideas out of Tops-10 and other
places about how you name things according to symbolic types and syntaxes.
DNS names were almost syntax free, with just three rules of significance
here

1) they order L to R. They nest.
2) the dot is a boundary, but not all dots are zone-cuts
3) there were limits on length

Does anyone else find themselves reaching into long term storage over
things like symbolic links with computed values? SunOS and the architecture
${cpu} in the symlink so it was computed on-the-fly to find your
/usr/local/${arch}/bin path in NFS?

DNS didn't do that. there is no my.dom.$intermediate.ain capability in the
name model.

And that kind of quality, rule 1) -they nest, is what the "D" in DNS means.

To me, its not incidental. Its core. If they don't obey the nesting
functions of Domains, they aren't domain-names.

On Fri, Sep 18, 2015 at 11:04 AM, Edward Lewis <[email-masked]>
wrote:

> I feel this may need clarification in your section on Tor addressing.
> Perhaps it's not **really** domain-naming, but it **looks** much more like
> it.
>
>
> I'm not disagreeing, just underlining that until the definition is in
> place, it's hard for me to be in complete agreement.
>
>
> So - and not to be pointed - but in your email I reference, should I
> ignore that for the sake of this document?  I mean what the message says
> seems to contradict what you are quoting from Mathewson - which is fine -
> but this is something unclear to me.
>

---

From: Alec Muffett <[email-masked]>
Date: Fri, 18 Sep 2015 14:16:16 +0000

> So - and not to be pointed - but in your email I reference, should I ignore that for the sake of this document?  I mean what the message says seems to contradict what you are quoting from Mathewson - which is fine - but this is something unclear to me.

Yes, you should ignore that text.

Nick is the engineer at Tor who implements the relevant code.

In the following, he provides the following undertaking:

https://lists.torproject.org/pipermail/tor-dev/2015-August/009275.html <https://lists.torproject.org/pipermail/tor-dev/2015-August/009275.html>

> The examples in Proposal 224 are a mere 53 characters long leaving 10 to
> play with for padding-hyphens and possibly checksum characters.
>
> Nick: Is this likely to need to change? Or might there be a need to encode >
> 315 bits / 63 chars total?

I don't anticipate this changing.

If there were ever a need to encode more than that number of bits,
we'd add an extra label.

So, .onion addresses will stay within DNS bounds.  :-)

    - alec

---

From: Bob Harold <[email-masked]>
Date: Fri, 18 Sep 2015 10:51:13 -0400

On Fri, Sep 18, 2015 at 9:54 AM, Alec Muffett <[email-masked]> wrote:

> ...
> You are certainly correct that the label immediately left of ".onion" is a
> hash, and functions not unlike a layer-3 address; however, there may be
> other labels leftwards of the hash, under (to some extent) other
> administrative control.
>
> The canonical example of this would be: www.facebookcorewwwi.onion versus
> m.facebookcorewwwwi.onion
>
...

>     - alec
I would argue that "facebookcorewww" is a domain within the "onion" domain,
and that the "www" and "m" here are within the "facebookcorewww" domain.

I also think that the fact that the 'name' of the domain happens to be a
hash is significant, it is merely the 'name' of the domain, and how the
name is chosen is not what defines a domain.

We might even say that the actual domain could be considered to be the
private information that the hash is created from, or the service, or
address (however Tor finds the resource).

---

From: George Michaelson <[email-masked]>
Date: Fri, 18 Sep 2015 12:00:24 -0300

If they nest, then yes. if the xxxxx. under onion is hash denoted only for
other reasons, but otherwise is a truly encompassing domain, then yes. If
it has a SOA. and NS, and there is a clear zonecut, its not just a domain,
its a DNS domain. But we know that isn't how its going to work: this is a
domain name system outside of the DNS. the concept of a zone cut, of a
Serial, a TTL, NS of the zone, none of those properties of the system are
inherent givens. I beleive they might even be not-givens: they don't exist,
because the functional mapping behaviour lies in another model.

But if there is magic which means m.facebookcorewww. under 76543.onion is
deterministically known to be the same as m.facebookcorewww. under
123456.onion, without query into the zone to get state, then I am less sure
this should be considered a domain. Its not obeying strict nesting rules.
There is no implication of scoping.

-G

On Fri, Sep 18, 2015 at 11:51 AM, Bob Harold <[email-masked]> wrote:

>> You are certainly correct that the label immediately left of ".onion" is
>> a hash, and functions not unlike a layer-3 address; however, there may be
> I would argue that "facebookcorewww" is a domain within the "onion"
> domain, and that the "www" and "m" here are within the "facebookcorewww"
> domain.
>

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 18 Sep 2015 12:19:26 -0400

> Hi, my name's Alec, I work for Facebook and lead the engineering team for Facebook over Tor.

This reminds me of the time I set down with a collection of people who would later turn into NZNOG, at a Uniforum meeting in Taupo. Since we were sitting in a circle, it seemed only natural to start things off with "My name is Joe, and I work for an ISP". Everybody else without missing a beat replied with the twelve-step "Hi Joe". We had a moment.

Hi Alec!

> You are certainly correct that the label immediately left of ".onion" is a hash, and functions not unlike a layer-3 address; however, there may be other labels leftwards of the hash, under (to some…

I think that we are all guilty from time to time of trying to form elegant, general descriptions of things that are not actually elegant, or useful to generalise.

The DNS is frequently described has having three core concepts: (a) the servers and the wire-format protocols that they talk, (b) the data model (resource records, etc) and (c) the namespace. (a) provides the infrastructure for (b) to be retrieved using a key from (c).

There are other name resolution protocols that are not the DNS, but which use similar namespaces to (c) and perhaps similar (b) but different (a). Pertinent examples are multicast DNS and Onion/tor, and (arguably) the localhost "protocol" that simply maps the name localhost to the addresses 127.0.0.1 and ::1.

The ugliness all rotates around the pragmatic decision to use the right-most label in a name as a resolution protocol selector. We can complain about that all we like, but reality is that we're going to have a hard time pushing those cats back into the bag. At the very least there will be injuries and bleeding, and you know the cats aren't going to like it.

It would be lovely if nobody had ever used the right-most label like this, and instead there was a standard and accepted way to specify a resolution protocol in a URI, and everywhere else that a name is used. But there isn't. Also, running code, etc.

Whether or not we should call an onion or mdns name a "domain name" or something else is just a detail. I don't think agreeing on the answer is going to solve any of the problems that we actually have.

Joe

---

From: Jim Reid <[email-masked]>
Date: Fri, 18 Sep 2015 17:51:33 +0100

On 18 Sep 2015, at 17:19, Joe Abley <[email-masked]> wrote:

> Whether or not we should call an onion or mdns name a "domain name" or something else is just a detail. I don't think agreeing on the answer is going to solve any of the problems that we actually have

+1

---

From: George Michaelson <[email-masked]>
Date: Fri, 18 Sep 2015 13:58:29 -0300

Ed wrote a draft whose purpose claimed to be definitional around what
domain names are. In that context I replied. If you don't really care how
we use words, thats fine too.

I agree it won't alter anything and I want to stop here, since I suspect
I'm already well on the way to hitting peoples kill file.

G

On Fri, Sep 18, 2015 at 1:51 PM, Jim Reid <[email-masked]> wrote:

> > Whether or not we should call an onion or mdns name a "domain name" or
> something else is just a detail. I don't think agreeing on the answer is
> going to solve any of the problems that we actually have
>
> +1
>

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 18 Sep 2015 13:56:45 -0400

Hi George!

> we use words, thats fine too.

I don't think that's a reasonable summary of what I care about, for the record :-)

I understand the context. I was really talking to a wider context, which is the difficulty with words we're used to seeing in the DNS when they are used in other name resolution protocols -- I was trying to suggest that the wider context has more to do with the use of multiple naming systems than it does with the overloading of individual terms.

> I'm already well on the way to hitting peoples kill file.

I don't have a kill file, George, but if I did the world would be a gloomier and more tedious place with you in it.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Sep 2015 14:50:25 +0000

On 9/18/15, 12:51, "DNSOP on behalf of Jim Reid" <[email-masked]

>>going to solve any of the problems that we actually have

I'm a little surprised at this response and the plus one.

Here's the problem I see.

Lets say I want to write a very basic SSH client (just to make the story
simple).  Someone can then type "eds-ssh computer-name" and open up a
secured connection.

If computer-name ends in .local, I open TCP to an IP address from the
lookup in mDNS.

If computer-name ends in .onion, I open TCP to an IP address I get via Tor
(assuming that .onion supports remote shell).

If computer-name ends in a digit, I suppose it's an address literal and
open TCP accordingly.

If computer-name ends in whatever is in the DNS root zone, I find the
address in DNS.

If computer-name ends in something not in the DNS root zone, I return an
error.

The gotchas include, what if the latter two are indistinguishable because
the DNS resolver sent back a landing page - or the latter three if the
redirection service didn't recognize .onion as special.

What if, in a year from now, .carrot becomes yet another way to resolve
names?

What if, in the future, .alt is defined as having special meaning?  (Note
- the fact that .alt is in an actual ID and .carrot is purely fictional
means .carrot is closer to being an RFC. ;))

It seems to me that a new layer of software is emerging between the UI and
the stub resolver, one that will need to know where to send a name
resolution query.  (Perhaps even amongst DNS stub resolvers on different
interfaces.)  This emerging layer needs to know how to direct it's work
flow.  The Special Use Domain Names Registry would be the place to start
(but as it's written now, the emerging layer can't be future proofed).

These are just TLD examples, perhaps a simplification.

I see a fork in the codepath ahead regarding "whether the DNS is above
Domain Names" (like .alt) or whether "Domain Names are broader than what
was conveniently defined for a DNS".  It's important to know which of
those two statements are true so we can get on with Special Use Domain
Names, and perhaps to find ways to objectively assign new names for new
uses.

I think defining -whether- name.onion is a Domain Name will make us
re-think how Domain Names interoperate amongst protocols beyond the DNS.

---

From: George Michaelson <[email-masked]>
Date: Mon, 21 Sep 2015 12:08:47 -0300

Your example has some problems for me.  Problems which I guess your
question was designed to draw out.

Firstly, *some* tor active clients operate by using bump-in-the-stack
methods based or analogous to SOCKS. So, there is an API which intervenes
on the normal operations and tunnels, and then its basically transparent.
Where this happens, and how this happens begs questions about the DNS
gethostby*() and getDNS*() api. -SOCKS does one set of things. the
TOR-SOCKS model (I hypothesize, but I do believe this exists) may do
something else.

Secondly, applications which don't use generic bumps in (application)
stacks, need to be re-coded to DTRT. So the .local example you gave, the
different OS's do a different job of implementing a set-aside into mDNS:
Its not uniformly available. "it depends" -And by analogy, one can expect
that .onion set-aside logic will not be uniform: if I took an apparent FQDN
xxxxx.onion on an SSH command line, and punched it into Opera, or Firefox,
or Chrome, or Safari, or curl, or ftp, I *might* get different behaviours.

I think the meta-question is a good question, but I don't think it only
faces one way (into DNS, and how we think about DNS) -It faces into the
problem space:

 "what is the set of mechanisms we have to hand, to try and do
name-to-locator mapping"

and some of them are domain names, and some aren't, and some have been
coerced into the domain name space so that other processes (X.509
certificate behaviour) can work, because of the SubjectName and
SubjectAlternateName being coerced into the dot-separated domain name form)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 21 Sep 2015 17:11:46 +0200

On Thu, Sep 17, 2015 at 07:58:54PM +0000,
 Edward Lewis <[email-masked]> wrote 

> >Name:		draft-lewis-domain-names

If you want a nice example of a domain name which is not a DNS name,
add in your /etc/hosts (or equivalent for your OS):

104.20.1.85 veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com

It is not a DNS name (first label is too long) but it works fine for
several applications which expect domain names:

% ping -c 3 veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
PING veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com (104.20.1.85) 56(84) bytes of data.
64 bytes from veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com (104.20.1.85): icmp_seq=1 ttl=58 time=2.10 ms
64 bytes from veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com (104.20.1.85): icmp_seq=2 ttl=58 time=1.88 ms
64 bytes from veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com (104.20.1.85): icmp_seq=3 ttl=58 time=2.27 ms

--- veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.887/2.089/2.273/0.166 ms

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Sep 2015 16:16:20 +0100

Edward Lewis <[email-masked]> wrote:
> resolution query.

What do you mean "is emerging"? The name service switch was introduced
over 20 years ago!

There are lots of alternate name resolution systems supported by NSS:
hosts files, NIS, WINS, mDNS, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 21 Sep 2015 17:20:18 +0200

On Fri, Sep 18, 2015 at 12:19:26PM -0400,
 Joe Abley <[email-masked]> wrote 
 a message of 111 lines which said:

> Whether or not we should call an onion or mdns name a "domain name"
> or something else is just a detail. I don't think agreeing on the
> answer is going to solve any of the problems that we actually have.

I disagree. RFCs are written with words and discussions at the IETF or
elsewhere use words. Agreeing on the "right" words is important. Words
are not innocent. (Refusing to call .onion names "domain names" was
also a way to refuse the registration of .onion.)

To quote Camus <https://en.wikipedia.org/wiki/Albert_Camus>, "Naming
things badly adds to the misfortune of the world"

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 21 Sep 2015 17:28:24 +0200

On Thu, Sep 17, 2015 at 07:58:54PM +0000,
 Edward Lewis <[email-masked]> wrote 
 a message of 145 lines which said:

> >the term within the Domain Name System.

Very good document, IMHO, and useful. I appreciate that we have a
document explaining clearly the difference between a domain name and a
DNS name. I loved the history bit, with SMTP defining the domain name
:-)

Two remarks:

>  the ordering of the sequence, such as left-to-right or
> right-to-left,

You make a confusion between the ordering of the sequence and its
representation. You may mention the ordering (the most specific label
at the beginning, the root at the end) as long as you don't refer to
the representation (in english, the most specific label is on the
left, in arabic on the right).

So, I suggest, when describing domain names, to use only "first" and
"last" for the labels and never "left" or "right", which are
script-specific.

> What is excluded in this definition is [...] the designated
> separator character's representation,

Then, /etc/cups/ppd/Konicac.ppd is a domain name? I tend to regard the
dot as a sure sign that the character string is intended to be a
domain name.

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 21 Sep 2015 12:11:02 -0400

> several applications which expect domain names:

Those applications probably use the getaddrinfo() function for name
lookup, and specifications for that function [0,1,2] don't specify a
length limit for the 'nodename' parameter.

[0] http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html

[1] http://tools.ietf.org/html/rfc3493#section-6

[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx

-- 
Robert Edmonds

---

From: hellekin <[email-masked]>
Date: Mon, 21 Sep 2015 17:36:20 -0300

> re-think how Domain Names interoperate amongst protocols beyond the DN
S.

Agreed, but why limit to .onion?  Can your example stretch to include
.bit, .i2p, .gnu, .zkey, and why not .exit?

In a recent private conversation it was suggested that as long as a
domain cannot sell subdomains it could be interesting to consider
(without affecting ICANN domain-name business).

Earlier we've been discussing P2PNames and came to the conclusion that
the term TLD should not be employed outside the DNS context, so I
welcome your draft to clarify this aspect.

Regards,

==
hk

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Sep 2015 11:44:04 +0000

On 9/21/15, 16:36, "DNSOP on behalf of hellekin" <[email-masked]
on behalf of [email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>

You tell me.  The draft is not necessarily comprehensive.  Examples are
not exhaustive lists.

The point of the draft is to move from a situation where we have a
hodgepodge of cases to one where we have a formal ontology.  From there,
the hope is that patterns will emerge that will increase determinism.

>(without affecting ICANN domain-name business).

This is a non-sequiter.  "Selling" is not one of the criteria.  OTOH,
whether names are centrally assigned (as in DNS) or uniquely spawned
(distributed hash tables) is a technical aspect, but even that doesn't
really matter - what matters is the method of converting the name into, as
appropriate, a location or other data value (key/cert for example).
(IMHO, just about any mention of ICANN is a red herring.)  The draft is
trying to forge a definition of Domain Names, with a better understanding
of how they function and interoperate amongst protocols.

>welcome your draft to clarify this aspect.

As mentioned in the draft, top-level names is defined very early on in the
evolution of the concept.  TLD has emerged, more so in the last 15 years,
to be a specific kind of entity within the management of DNS operations.

It is my suspicion/belief that the top-level name will retain special
status as we go on because - and this is belief talking and not anything
more mature - there needs to be some way to signal how the name "below"
(in the rooted tree sense) is resolved.  I.e., if I see "onion" I go to
Tor, "local" mDNS, a numeric value is treated as a literal or error, a
known DNS TLD to the DNS, and so on.  I'm not sure this observation will
be something that grows into the draft or not but is a central reason why
I think we have to start with a basic definition.

That list of examples can conceivably grow at the cost of complexifying[0]
software.

[0] yes, I know, not a word.

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 22 Sep 2015 09:20:58 -0400

Hi Stephane,

> also a way to refuse the registration of .onion.)

I suspect I didn't explain myself very well.

I am all in favour of an accurate and unambiguous lexicon, and I think 
there's a lot to like about Ed's draft.

However, the problem we are struggling with (which Ed spoke more about 
in a follow-up e-mail) is the conflict between different name resolution 
protocols that have namespaces similar enough for applications to treat 
the same.

I think we need to address the architctural issue that the last label in 
what applications (and Ed) call a domain name is in some cases a 
protocol selector token, and in other cases is not.

(We might wish that there was a better answer than this, perhaps has 
part of the URI spec or something else, but let's face it, that 
particular quadraped has long since departed his straw-strewn abode).

Joe