Subject: Re: [DNSOP] back to: Some distinctions and a request

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 2 Jul 2015 10:02:59 +0000

Hi,

I think that Andrew's effort to distinguish between a domain name and
a DNS name is useful.  It gives us some clear terminology to use to
discuss domain names that wish to use a non-DNS name resolution
method.

RFC6761 introduces a mechanism for the handling of these types of cases.  
In the recent cases of .onion, .gnu, .zkey etc. we have software using domain
names but wishing to use a non-DNS name resolution mechanism.

This is a "hand in glove" use of RFC6761.  For persons wishing not to
allow the use of RFC6761 for these names, it would seem that you have
two options:

1. Invalidate RFC6761 indicating it was a mistake.  This is not a disaster,
mistakes are made and sometimes need to be rectified.

2. Form a different community for the assessment of these issues, and 
decide not to participate in that process.  Thus, "you" are not allowing the
use.

Option 2 may not be such a silly idea.  Some members of the community
made it clear that they do not wish for DNSOP to be a clearing house for
RFC6761.

I assume that .gnu, .zkey, .bit communities would have the patience to
wait for the formation of an alternative processing mechanism, but there
is time pressure on .onion due to the upcoming work with certificates.

Thus, it would seem that a decision is required from this community for
the .onion case.

Needless to say, I support all of these cases where software is using
the domain name syntax but using a non-DNS name resolution mechanism.

I provide that support because they are addressing the issue of privacy
which the greater IETF community embraced with RFC7258.

The DPRIVE WG are working on privacy enhancements *within* the
DNS system.  It is a difficult problem, though many useful contributions
are emerging.  The above non-DNS using softwares approach the
same issue in a different manner: dont use DNS at all.  The advantage
of this approach is that all of the challenges that DPRIVE are wrestling
with are not encountered at all.  The only requirement is the registration
via RFC6761.

Hugo Connery
--
'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman.
________________________________________
From: DNSOP [[email-masked]] on behalf of Andrew Sullivan [[email-masked]]
Sent: Thursday, 2 July 2015 03:42
To: [email-masked]
Subject: Re: [DNSOP] More after onion? was Re: Some distinctions and a  request

Hi Ed,

On Wed, Jul 01, 2015 at 12:26:43PM +0000, Edward Lewis wrote:
> I'm sympathetic to the use the path of least resistance - e.g., use names
> that syntactically are DNS names

I note that the Subject: line of your note still contains a vestigial
reference to the thread I started recently on this, and your message
nevertheless returns to collapsing "domain names" and "DNS names".

I don't know whether I've simply failed to explain the distinction I'm
trying to make, or whether you reject the premise.  Could you please
be clear about which it is?

To me, the _point_ of onion. is that it is not a DNS name.  You're
right that it has the same syntax -- because it is a domain name, but
not (intended to be) a DNS name.  The registration of the name in the
special use registry would achieve that end.

You might object that this distinction is extremely hard, because
there's nothing about the label itself to signal this namespace shift,
and unaware clients will therefore automatically just treat such names
as DNS names, not special-use domain names.

I happen to agree with that, but we cannot hold back this tide: it was
let loose once local. became an in-band protocol switch, without any
registration, in Apple's widely-deployed Bonjour service.  We might
wish that people hadn't abused the namespace to turn it into protocol
switches as well as everything else, but the history of SRV through
Bonjour shows that this technique is popular and unlikely to go away.
Commanding the tide to stay back when you are neck deep in water is
not likely to work.

Therefore, I claim, we need to make some clear distinctions and
understand what has actually happened, and then adjust to the new reality.

Best regards,

A

--
Andrew Sullivan
[email-masked]

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2015 12:51:17 +0000

>discuss domain names that wish to use a non-DNS name resolution

Until this message, I wasn't clear on Andrew's distinction - we have been
talking off-list for the past few days too.

To me a domain name is: a sequence of bits that, when rendered in hex
notation, can look like this:

0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00

That is what is sent over the wire, through ports and is deposited in
memory of name servers.  Note the lack of dots.  And this is why I can't
see a difference between domain names and DNS names.  To me, they are one
in the same.

This dates back to a discussion had while the labs I was in was developing
DNSSEC code.  Our boss (Russ Mundy) made the statement that there are two
versions of a domain name, on-the-wire and in-the-file and it was the
on-the-wire format that mattered.  Later in my career I worked with a firm
that developed it's own DNS code based on some legacy stuff from it's
start-up days.  The start-up operated on the in-the-file format,
converting to and from on-the-wire format constantly.  This was not a good
approach.

So when I hear "domain name" I think of the format that includes an octet
with flags and a number and then that number of octets of data,
terminating with a null octet.  What is seen in files is just a
transliteration of that, "abc.example." is just a conventional way to
represent the domain name above.

Now, if times have changed and a broader audience thinks "abc.example." is
a domain name, there's a need to document that.  In an old RFC there are
rules for representing a domain name in a file, rules that are
inconsistently understood and applied.  Maybe it's not times, it's
perspectives.  I'm coming up through the DNS, I didn't come across the DNS
from application space.

What I mean by rules inconsistently applied is a case of apparently
mis-aligned RFCs on ENUM.  In one RFC, domain names were presented as
conversions to ASCII and the other following the rules of the old RFC for
escaping characters.  Specifically, a back-slash was the issue, in one RFC
it was bare, in the the other escaped, and this difference caused
implementers of ENUM code headaches.

(I should look this up.  I lost the notes on that incident, but probably
can try to dig up the references.)

I'll ask this, are these (thought to be) domain names:

\097\098\099.example.  { 97 is the decimal equivalent of 'a' in RFC 20's
ascii table }

\a\b\c.example.

example.中国. {latter two characters are Chinese, meaning the country of
China}

现在我跟老婆住华盛顿可是以后我飞到IETF.练习 { a sequence of Chinese
charaters, IDNA2008 code
says label too long }

The latter is a placeholder for names that would be "too long" for the DNS
but otherwise look like, in a file, a domain name.  This is said to be
true in Tor's use.

I am not asking to be facetious.  I have had to deal with these questions
over the years.  The latter I have code to test because I'd been asked to
look at official names of geographic regions and whether what would
'appear' to be a domain name from that could possibly be carried across
port 53.

If there is a distinction to be made between domain names and DNS names,
the former needs to be defined first. What are the rules in an http:// or
ftp:// URL?  Colloquially I think the first name is a 'domain name' but I
have never been able to trace that down.  I doubt that the 'domain name'
there is ever processed in on-the-wire format (as I started with) until
the DNS stub resolver accepts the request and spits out something to a
recursive server at port 53 somewhere.

(This omits the other under-worldly distinction of what names are eligible
for registration, etc., which is a distinction I've had to deal with.  In
a world where one can write in any script with any kind of pen or pencil,
you have to know where do, um, draw, the line.  IDNA2008?  Punycode?
Different rules for different systems?  And, is the "domain" of the
problem all code, all protocols, or what's in common use on the global
public Interent?)

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 2 Jul 2015 16:04:20 +0000

Hi Mr Lewis, and list,

I believe that you are making a category error here.  The key
point is that the softwares that are using the domain name (dot
separated network identifier) labeling system do not wish to
use the DNS architecture for name to address resolution, at all.

However, they may wish to use the excellent transport mechanisms
that IETF have defined over the years, including the latest version(s)
of TLS.  I come back to this below when considering the failure
mode of communication to a URI.

Additionally, they wish to protect the privacy of their users by
having the DNS reject to resolve these names.

We have a mechanism which reliably translates www.example.org
into some on-the-wire byte representation and works.  This does not need
to change, or even be investigated.

Here is what I believe the non-DNS resolution softwares want:

1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu)
within the root zone as "not a domain".  i.e if anyone asks the
answer for anything in or under that pTLD the answer is NXDOMAIN.

2. Iterative resolution software to also be aware of this, such that
they have a permanent in cache response to hand out NXDOMAIN
without bothering the root zone's resolvers (and exposing the query).

3. qname minimisation to be approved and implemented.  In this case,
if 2. is not achieved the exposure of the end user system is dramatically
limited.

All of the above is "worst case usage" from these softwares.  Normal
operation is that the DNS architecture does not even see these name
resolutions happening -- they use whichever mechanism they have
designed and implemented -- the end user is satisfied (assuming their
mechanism works) and the DNS knows nothing.

Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/

When entered into the Tor browser, the DNS sees absolutely no traffic, at all,
irrespective of whether the "domain name" exists.  E.g if asdfasdfasdfasdf.onion
is not defined within the Tor network, still the DNS sees nothing.
However, some configuration of a recently defined TLS transport is used (https).

When opened with a regular browser, the use of the Tor network is
exposed, as described above.  The communication will fail, as
the asdfasdfasdfasdf sub-domain is not registered (and hopefully
not registerable).  We are talking about *how* it fails, and reducing
the leaking of information in that process.

All of these on-list discussions are about point 1. above; Negative registration
in the root zone via RFC6761.

Steps 2 and 3 are, I expect, also on the agendas for these overlay networks,
because they care about the privacy of their community.

If point 2 could be universally achieved, points 1 and 3 are moot.
But, that is never doing to happen, thus the current approach.

Sincerely,  Hugo Connery

NB: I am not a member of the community for any of these networks, and
I certainly dont speak on their behalf.  I do use Tor regularly.
________________________________________
From: Edward Lewis [[email-masked]]
Sent: Thursday, 2 July 2015 14:51
To: Hugo Maxwell Connery; Andrew Sullivan; [email-masked]
Subject: Re: [DNSOP] back to: Some distinctions and a request

\a\b\c.example.

---

From: manning <[email-masked]>
Date: Thu, 2 Jul 2015 09:40:19 -0700

If that is the case,   that these folks don’t want to use the DNS name-address resolution at all, then
there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS
for its intended purpose.   If House Finch Feathers OY  applies to ICANN for the .ONION TLD, there
should be zero objection, since other use is outside the scope of the DNS.

the use of a “reserved label” registry simply for “defensive” purposes is properly outside 
the scope of the IETF goal of defining and developing Internet Protocols.   

As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate
effort, but the facts are that overlaps occur in real life (see also:  acronym overload)  and the name space
in question is the DNS view of the name space, not domain name space en-toto.    (whee - hows that for
a run-on sentence!)

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 2 Jul 2015 16:59:59 +0000

manning,

The "defense" is the defense of the privacy of their community
due to the commonality of the URI format.

(protocol)://(domain-looking-string)/(path).

Open that with the "right" software and all is good, no privacy is
lost, and the DNS is not involved.  Open it with
DNS based software and you leak information / lose privacy.

It is that simple.

The negative registration is to minimize info leakage and loss of 
privacy, which apparently we care about.

Hugo Connery
--
'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman.
________________________________________
From: DNSOP [[email-masked]] on behalf of manning [[email-masked]]
Sent: Thursday, 2 July 2015 18:40
To: Hugo Maxwell Connery
Cc: [email-masked]
Subject: Re: [DNSOP] back to: Some distinctions and a request

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: manning <[email-masked]>
Date: Thu, 2 Jul 2015 10:24:33 -0700

Hum…   “domain-looking-string” …  Per RFC 1945, we read:
"3.2.2 http URL

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

       http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

       host           = <A legal Internet host domain name
                         or IP address (in dotted-decimal form),
                         as defined by 
Section 2.1 of RFC 1123

       port           = *DIGIT”

So then the question on the table is,  What is a “legal host domain name”?   RFC 1123, using SMTP as the example, says:

"5.3.5  Domain Name Support

         SMTP implementations MUST use the mechanism defined in 
         Section 6.1 for mapping between domain names and IP addresses.  This
         means that every Internet SMTP MUST include support for the
         Internet DNS.”

This STRONGLY suggests that “domain-looking-string” is , in fact,  a host that is identified using the Internet DNS.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2015 10:34:42 -0700

manning wrote:
> ... STRONGLY suggests that “domain-looking-string” is , in fact, a
> host that is identified using the Internet DNS.

i agree with this interpretation, which means, it's the spec itself
that's wrong, not hugo's interpretation of it. the internet people
didn't love .UUCP addresses either but that didn't stop them from working.

what the internet should be doing is defining escape mechanisms for
non-internet systems, rather than saying "we are the only thing you can
use".

-- 
Paul Vixie

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2015 18:33:52 +0000

>use the DNS architecture for name to address resolution, at all.

That's well understood.

>mode of communication to a URI.

Instead of "transport" which for me and others means things like TCP and
UDP, I think you mean applications.  If I understand correctly, Tor uses
web browsers and URLs because the existing base does what Tor needs.
Which is fine.  Code reuse, etc.

>having the DNS reject to resolve these names.

That's not a way to protect privacy.  Just asking a DNS server "leaks"
some information.  The DNS can't prevent anyone from asking, rejecting the
query is too late.  OTOH, as someone managing DNS operations, the queries
don't leak enough of the right information (although they may leak the
wrong information, with "right/wrong" a subjective call).

>to change, or even be investigated.

My point about on-the-wire was a tad bit obtuse.  I was trying to explain
what I thought a domain name was and relied upon the DNS protocol's
version of what goes out the socket, through the port and out over the
electromagnetic waves.  I figure the DNS itself is unique in the
formatting.

When URLs go into the electromagnetic medium, I bet they are converted
into something ascii-compatible or unicode encoded (I haven't checked).
When X.509 certificates go out, the subjectAltName holding a domain name
would be passed through ASN.1, then maybe a DER/BER/etc., and so on.  If
that's what is meant by a domain name, it's not what I was thinking.

I wasn't trying to say all applications use the DNS format, just that when
it comes to DNS names and domain names, I think of them as the same
because I usually operate on the DNS wire format.

Still, I'd like to see a common definition of what a "domain name" is in
the context of domain name use in URLs, email addresses, X.509
subjectAltName and other places I'm not listing because I'm not thinking
of them.

>answer for anything in or under that pTLD the answer is NXDOMAIN.

To some extent this is just a registration of the string in the root TLD.
Just like registering a name that will "work" the impact is about the same
up though registration.  I thought about how to scale this and make this
work seeing that there's a high application fee for positive
registrations.  I don't have a clear answer. An alt-TLD is a good partial
solution, i.e., reserving one string the root is something I can see as
possible but not a TLD per "not a domain" domain-looking namespace.

E.g., One concern is confusability between names.  Like, is example. and
ex<cyrillic-a>mple. the same thing?  This has been an issue amongst
commercial names.  But what about .bit and .b1t?  Neglecting money, cost,
budget, there's still work to be done to avoid the ensuing operational
issues that would likely follow.

>without bothering the root zone's resolvers (and exposing the query).

That's a lot of code to distribute.  And existing code bases don't do this
now.  (Yes, the usual excuse for not innovating.)  The reality is you
can't stop someone from asking overnight.

I could see such software consulting the special use domain name registry
and dynamically deciding how to resolve the name.  But that's generations
(of code) off into the future.

>if 2. is not achieved the exposure of the end user system is dramatically

I see this as a non-sequitir.  If one is not supposed to ask the DNS, then
it doesn't matter.  If one is leaking, this only means that some of the
authoritative servers don't see the intended name, the recursive does.

>However, some configuration of a recently defined TLS transport is used

If that's the case, why is this being discussed in DNSOP? ;)

>the leaking of information in that process.

In this case the users also have 0 availability of the desired object.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2015 18:36:25 +0000

On 7/2/15, 13:34, "DNSOP on behalf of Paul Vixie" <[email-masked]

>non-internet systems, rather than saying "we are the only thing you can

At the risk of further annoying Andrews ... if there was a definition of
domain name in contexts external to the DNS, that would be helpful.  Plus,
in each context, what are the escape rules, if needed?

E.g., At one time, some "funny guy" tried to register ctrl-G as a TLD.
(He knows who he is.)  How would that be written in a URL?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Jul 2015 08:26:54 +1000

In message <[email-masked]>, Edward Lewis writes:
> >> ... STRONGLY suggests that =E2=80=9Cdomain-looking-string=E2=80=9D is , in
>  fact, a

In a domain name: \007 (RFC 1034 presentation encoding)
In a host name: not possible as it is outside the allowable syntax.
In a url it would depend upon the scheme.  It would not be valid for
http:, https: or mailto: to start with as all three are restricted to
using hostnames.  For those schemes where it is valid input %07.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Jul 2015 18:55:26 -0400

> non-internet systems, rather than saying "we are the only thing you can

The Internet _has_ done that.  Unfortunately (and I do think it's
unfortunate), the Internet did this by in-band signalling in things
that go in domain name slots in protocol strings.  That what
local. (and, given its deployment, onion.) are doing.

I don't have to like it to recognize that this has happened, and that
as people who are trying to design systems to maximize
interoperability we have to cope with those facts.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: manning <[email-masked]>
Date: Thu, 2 Jul 2015 16:02:37 -0700

agreed.  but a “reserved string” registry isn’t the way to do that…  at least in a scaleable fashion.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 2 Jul 2015 19:04:34 -0400

> represent the domain name above.

Hi, Ed:

I have a somewhat different understanding.  I read in 1034 §3.1 that:

    The domain name space is a tree structure.  Each node and leaf on
    the tree corresponds to a resource set (which may be empty). [...]
    The domain name of a node is the list of the labels on the path from
    the node to the root of the tree. [...]

These definitions use abstract data types like trees and lists.  (They
shouldn't be confused with concrete data structure implementations of
those types.)

The same section then defines two concrete representations of domain
names:

    [DNS wire format names.] Internally, programs that manipulate
    domain names should represent them as sequences of labels, where
    each label is a length octet followed by an octet string. [...]

    [DNS "presentation format" names.] When a user needs to type a
    domain name, the length of each label is omitted and the labels are
    separated by dots (".").  Since a complete domain name ends with the
    root label, this leads to a printed form which ends in a dot. [...]

So, I take the octet sequence \# 13 03616263076578616D706C6500 and the
character string "abc.example." to be two different representations of
the domain name whose list of labels is "abc", "example", and "".  But I
don't see how one of the concrete forms is a transliteration of the
other.

-- 
Robert Edmonds

---

From: manning <[email-masked]>
Date: Thu, 2 Jul 2015 16:11:03 -0700

the ^G registration was done prior to RFC 1123 being written.   

I think, this whole discussion (particularly Ed Lewis’s POV about wire formats v. readings from RFC 1034 suggest
reopening the can’o’worms that was/is the IDN debate and 8bit clean, native Unicode, etc.   

Regarding Andrew S. recognition that the horse has left the barn (.local, .onion, etc.)  there are two options open:
1) close the door before others escape and completely pollute the watershed,
2) throw in the towel and give up

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 2 Jul 2015 19:44:23 -0400

> This STRONGLY suggests that “domain-looking-string” is , in fact,  a host that is identified using the Internet DNS.

Have a look at the later HTTP/1.1 RFCs (7230) and the URI generic syntax
RFC (3986).  RFC 7230 defines http URIs, but it relies on the URI
generic syntax (RFC 3986) to define "uri-host"'s, and that specification
explicitly declines to require that "domain-looking-strings" be Internet
DNS names:

3.2.2.  Host

   [...]

   This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.  A URI resolution implementation might use DNS,
   host tables, yellow pages, NetInfo, WINS, or any other system for
   lookup of registered names.  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, and should limit these names to no more than
   255 characters in length.

   [...]

-- 
Robert Edmonds

---

From: manning <[email-masked]>
Date: Thu, 2 Jul 2015 17:58:08 -0700

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 2July2015Thursday, at 16:44, Robert Edmonds <[email-masked]> wrote:

>   name beyond what is necessary for interoperability.  
[…]
> .  However, a globally scoped naming

	There in lies the problem.  These systems have no way to disambiguate a local v. global scope.
         It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets
         and no way to attempt DNS resolution.   Or they need to ensure that DNS resolution occurs after every other “name lookup technology”
         which is not global in scope.

	Paul Vixies point about an escape method not being apparently visible comes to mind.

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 2 Jul 2015 21:21:46 -0400

>          which is not global in scope.

I don't understand this point.  Since Onion hidden service names are
based on hashes derived from public keys surely they're globally scoped
(barring hash collisions)?

-- 
Robert Edmonds

---

From: manning <[email-masked]>
Date: Thu, 2 Jul 2015 20:56:12 -0700

> (barring hash collisions)?

If they _are_ globally scoped,  what part of the local system decides which namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the DECnetV, the IXP, or the DNS…
where is search order determined?  Does first match in any namespace win?  What is the tiebreaker when there are label collisions between namespaces?

/bill

---

From: manning <[email-masked]>
Date: Fri, 3 Jul 2015 06:43:13 -0700

Actually, there IS an escape method already defined.  We just don’t use it much these days.
It’s called  “class”

There is no reason these alternate namespaces should sit in the IN class.  they could/should be in their
own class, like the old CHAOS protocols.   So  a class  “ONION” or “P2P” would work out very nicely.

After all it’s the Domain Name System.  (can comprehend names in multiple domains, not just the Internet)

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 Jul 2015 10:01:05 -0400

> own class, like the old CHAOS protocols.   So  a class  “ONION” or “P2P” would work out very nicely.

Yup, but the problem is that people want to be able to enter the
alternate namespace names into existing applications (like browsers,
ssh, etc), just like a "normal" DNS name. They want to be able to
email links around (like https://facebookcorewwwi.onion/ ) and have
others click on them, etc.

There is no way that I know of to tell e.g Safari to look this up in a
different class... and, even if there were, they would *still* leak,
because people are lazy...

W

-- 
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: manning <[email-masked]>
Date: Fri, 3 Jul 2015 07:21:29 -0700

Thanks for that.  The original claim was that these name spaces were global in scope, but not part of the Internet.
So I took that as face value.  Your example, while perhaps a valid interpretation, is not what was asked for.
If it is, then namespace/class specific applications/extentions need to be developed/deployed, OR folks need
to suck it up and just use the Internet portion of the DNS (and its associated rules, e.g. new TLDs are defined 
by ICANN)

/bill

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 03 Jul 2015 17:18:01 +0200

Unfortunately I think we all in this discussion [again] mix up discussion about DNS with the discussion about the name space that is in use for example by what we know as "the domain name system rooted at the root zone managed by IANA".

I think we just must force ourselves to stay focused on namespace management. A portion of that name space is to be accessed using DNS. Some other portions of that very same name space is access using other mechanisms.

This is not easy, but I think that is the way to attack the problem.

And given such a view, IETF is to decide what strings are to be used "by other mechanisms" so that [for example] they can and should never ever be accessed by the domain name system.

This while ICANN have processes for deciding what string should be TLDs, based on the standards created by for example the IETF.

Maybe a document is needed that describes that namespace? How it is partitioned?

  Patrik

On 3 Jul 2015, at 16:21, manning wrote:

> If it is, then namespace/class specific applications/extentions need to be developed/deployed, OR folks need to suck it up and just use the Internet portion of the DNS (and its associated rules, e.g. new TLDs are defined by ICANN)
>
> /bill
>
>

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Fri, 3 Jul 2015 15:19:26 +0000

Hi,

I can't comment on whether this suggestion makes sense for these
overlay networks, but it may be one way of handling these non-DNS
resolving but still use HTTPS/TCP "IN" type things.

I expect that Hellekin, C Grothoff, and others (TOR, namecoin, ...)
would be best placed to comment.

There is still the time challenge for the certificate work.

Thanks for your suggestion, manning.

Hugo Connery
--
Head of IT, DTU Environment, http://www.env.dtu.dk
what the internet should be doing is defining escape mechanisms for
non-internet systems, rather than saying "we are the only thing you can
use".  P Vixie
________________________________________
From: DNSOP [[email-masked]] on behalf of manning [[email-masked]]
Sent: Friday, 3 July 2015 15:43
To: Robert Edmonds; Andrew Sullivan
Cc: [email-masked]
Subject: Re: [DNSOP] Some distinctions and a request - Have some class?

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: manning <[email-masked]>
Date: Fri, 3 Jul 2015 08:50:20 -0700

Perhaps.  The Domain Name System is just that.  A naming system for domains, one of which is the Internet.  Being lazy, and in the absence of significant development in other
domains (save the CHAOS domain), our community conflates the DNS(IN) as the entire DNS.  Which is false.  The DNS, class IN, is rooted at the root zone managed by the IANA.
The DNS, class CHAOS, is not.   The DNS, class ONION, may not.   

Legacy applications/browsers etc, are also lazy and have built in assumptions about DNS, class IN.

This would only be true for globally scoped name spaces,  (so not .LOCAL)

And I would be happy to write up something about name spaces, partitions, etc.  

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: joel jaeggli <[email-masked]>
Date: Fri, 3 Jul 2015 08:54:13 -0700

> because people are lazy...

well before we just started  typing stuff in and let heuristics and
search engines divine what we meant, we had urns. I will  not suggest
that we're going back there UI wise but the heuristics can get  more
expressive. this can be largely a UI issue today in chrome, if I want to
send my query to a particular application e.g. wolfram alpha I do "= "
and proceed.

UI grooming in no way prevents leakage. nor does it preclude you from
having to divine the intentions of the user.

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 3 Jul 2015 12:26:08 -0400

Hi,

> I think we just must force ourselves to stay focused on namespace management. A portion of that name space is to be accessed using DNS. Some other portions of that very same name space is access us…

If I've followed the discussion so far-- which has been very good, and exactly what I think we've been working towards for quite awhile now-- this is key to making any kind of progress beyond beauty contests for the IETF to judge about "things that look like TLDs" and confusion for developers of new technology who want to use DNS-compatible names.

> And given such a view, IETF is to decide what strings are to be used "by other mechanisms" so that [for example] they can and should never ever be accessed by the domain name system.

As long as administrators can configure their own namespaces, the IETF has limited power in this area, and IMHO shouldn't chase more. We can provide advice, however, such as encouraging the use of .alt names in the same kind of "protocol switch signal" names that people are starting to scatter arbitrarily through the namespace.

> This while ICANN have processes for deciding what string should be TLDs, based on the standards created by for example the IETF.

It does seem to me that an important feature here is that "TLD" as we're using it is "name in the root zone (or root zone space), to be managed within a context that assumes DNS protocol and semantics as well as DNS-compatible name space." (That is, people using the term "TLD" to refer to single-label DNS-compatible name are incorrect-- "onion" is not a TLD, and that's largely the point.)
> Maybe a document is needed that describes that namespace? How it is partitioned?

Andrew requested on the list last week that we discuss the possibility of 6761bis in Prague, and the draft agenda (to be posted in the next couple of days) does include a slot for that. In the meantime, let's continue here.

best,
Suzanne

---

From: manning <[email-masked]>
Date: Fri, 3 Jul 2015 11:11:23 -0700

> It does seem to me that an important feature here is that "TLD" as we're using it is "name in the root zone (or root zone space), to be managed within a context that assumes DNS protocol and semant…

CHAOS names are DNS-compatible. But they are not anchored in the root of the Internet class.

I guess my question here is, what would prevent House Finch Feathers OY from applying for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN class?

I will not be able to attend the DNSOPS WG since I arrive in Prague later in the week, but would appreciate being part of this ongoing discussion.

/bill

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 Jul 2015 15:56:47 -0400

> I guess my question here is, what would prevent House Finch Feathers OY from applying for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN class?

Nuttin' -- they can apply, but the expectation is that it wouldn't be granted.

The last new gTLD round "Draft Applicant Guidebook" contained:
2.2.1.2.1 Reserved Names All applied-for gTLD strings are compared
with the list of top-level Reserved Names to ensure that the
applied-for gTLD string does not appear on that list.

<and then a table, containing, amongst other things (including
'ICANN', 'IETF', 'IESG', 'RSSAC' and 'SSAC' (don't even get me
started..)) all of the single labels in the "Special Use Names"
registry and "*Note that in addition to the above strings, ICANN will
reserve translations of the terms “test” and “example” in multiple
languages. The remainder of the strings are reserved only in the form
included above.">

So, putting something on the SUN registry seems to make it not
eligible for being considered as string that can be applied for (at
least in this last round)

W

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 03 Jul 2015 23:58:53 +0200

> I guess my question here is, what would prevent House Finch Feathers OY from applying for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN class?

Nothing, if that is the goal, which I claim it is not.

The goal is to ensure that portion of the name space, rooted at ONION, is _not_ existing the portion of the name space reachable by the normal DNS. To ensure the name space is properly partitioned.

  Patrik

---

From: manning <[email-masked]>
Date: Fri, 3 Jul 2015 16:56:01 -0700

Borrowing a snippet from the operational community (h/t Chris Morrow).
If one replaces “subnet” with “domain”… 

——
this is really a form of: "A subnet should contain all things of a
like purpose/use."

that way you don't have to compromise and say: "Well... tcp/443 is OK
for ABC units but deadly for XYZ ones! block to the 6 of 12 XYZ and
permit to all ABC... wait, can you bounce off an ABC and still kill an
XYZ? crap... pwned."

segregation by function/purpose... best bet you can get.
——

So I -think- we are on the same page here, although I would replace your use of the phrase, “name space” with domain.  We have empirical evidence of multiple domains using the same name space.
(Fred Baker persuaded me that there is a single name space, but we partition/segregate by function/purpose).   The same name space for UUCP, CHAOS, Internet, Onion, etc…  just different domains.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 3 Jul 2015 20:00:14 -0700

On 7/3/2015 4:56 PM, manning wrote:

> Borrowing a snippet from the operational community (h/t Chris
> Morrow). If one replaces “subnet” with “domain”…

Indeed -- subnet <--> domain do not map properly in the current landscap
e.

- - ferg

- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2015 06:31:20 -0000

>I guess my question here is, what would prevent House Finch Feathers OY from applying
>for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN
>class?

At the moment, nothing.  

Remember, we also have a draft about .HOME and .CORP and .MAIL.  ICANN
says they're not planning to delegate those names, but they have about
20 active applications and $3.7M in application fees for those names
which suggests that their plan may not be entirely final.  That's why
I think we need an ongoing way to identify names that should stay out
of the DNS for engineering reasons.

R's,
John

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 08:40:14 +0200

> (Fred Baker persuaded me that there is a single name space, but we partition/segregate by function/purpose).   The same name space for UUCP, CHAOS, Internet, Onion, etc…  just different domains.

This is why I do NOT want to use the word domain, but name space, and why I suggest discussion must start there.

Because we, as Warren explained, are discussing collision avoidance when there is a risk the same name have multiple use.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 09:12:04 +0200

> of the DNS for engineering reasons.

+10000

Once again:

ICANN do say what strings in the name space should be TLDs.

IETF do say what strings in the name space should NOT be TLDs.

The rest are just strings waiting to end up in one of the two groups.

   Patrik

---

From: Steve Crocker <[email-masked]>
Date: Sat, 4 Jul 2015 09:16:17 -0700

See the end for something provocative.

> The rest are just strings waiting to end up in one of the two groups.

Perfectly stated.  There is really just one name space.  Once a string is designated by the IETF for some purpose other than allocation as a top level domain, it is, IMO, permanently barred from being allocated as a TLD.

As a practical matter, non-TLD strings regularly leak into the public domain name system and wind up at the root.  In principle, this should not be a problem except for the additional load it places on the root servers, EXCEPT we have also seen end systems depend on the NXDOMAIN response from the root servers as part of their processing.  This creates a nasty security hole.

I propose augmenting the DNS to include entries in the root that serve the purpose of giving slow NXDOMAIN responses instead of quick responses for those strings that the IETF has identified as not TLDs.  local, corp, home, mail, and others are what I have in mind.  This is intended to incentivize developers not to release code that improperly depends on the NXDOMAIN response in their search path.

Steve

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 4 Jul 2015 12:29:16 -0400

(no hats)

> On Jul 4, 2015, at 3:12 AM, Patrik Fältström <[email-masked]> wrote:
> 
> Once again:
> 

In the interests of precision in our discussion: I’m not convinced that’s actually the case, and I’m not convinced it’s consistent with what we’ve said in the conversation so far. I *think* it loses exactly the distinction that we started the thread with.

It seems to me, from long experience of both organizations, that ICANN says what names should and shouldn’t be in the DNS root zone— a specific instantiation of the namespace, tied to use in a specific database (the public DNS) and the DNS protocol. (Enormous chunks of the Applicant Guidebook, and of the deliberations in the new gTLD program, were devoted to discussion of what names should *not* be in the root zone.)

It further seems to me that the IETF says what names it considers to be in the namespace for other reasons, such as enabling deployment of new protocols (as already pointed out upthread, it’s perhaps unfortunate but undoubtedly true that people are doing this and we may want to enable it).

Avoiding collisions between DNS and non-DNS use of domain names is probably important to us (to some degree that’s what we’re trying to decide). But I have thought, and continue to think, that we make a serious mistake if we regard it as our purpose to “say what strings in the name space should NOT be TLDs.”  The IETF delegated that responsibility long ago to someone else, and for good reason.

> The rest are just strings waiting to end up in one of the two groups.

I’m not sure I agree with this either, but will have to think further.

best,
Suzanne

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 04 Jul 2015 21:05:57 +0200

On 4 Jul 2015, at 18:29, Suzanne Woolf wrote:

> It seems to me, from long experience of both organizations, that ICANN says what names should and shouldn’t be in the DNS root zone—

Well, I have never seen ICANN saying "definite no" to any string. ICANN only say "no, this string is not to be ok in THIS round of gTLD applications" (as part of the result of the PDP), or "we defer delegation indefinitely".

If you have other data, please let me know.

As a chair of SSAC I am interested... ;-)

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 4 Jul 2015 20:35:14 -0400

> Actually, there IS an escape method already defined.  We just don’t use it much these days.

Classes don't work in the general case, because CNAME (and following
it, DNAME) is class-independent.  This is arguably a bug in the
protocol, but it's a fact nevertheless.  As a result, different
classes aren't really different namespaces.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Steve Crocker <[email-masked]>
Date: Sat, 4 Jul 2015 18:26:43 -0700

Folks,

I’ve been watching the dialog on this list regarding to level names.  Attached is my attempt to clarify the state of affairs and identify the loose ends.  Both PDF and pptx versions attached, the latter in case someone is moved to edit the slides directly.

Cheers,

Steve

---

From: "John R Levine" <[email-masked]>
Date: 5 Jul 2015 14:32:03 +1200

> Avoiding collisions between DNS and non-DNS use of domain names is 
> probably important to us (to some degree that’s what we’re trying to 
> decide). But I have thought, and continue to think, that we make a 
> serious mistake if we regard it as our purpose to “say what strings in 
> the name space should NOT be TLDs.” The IETF delegated that 
> responsibility long ago to someone else, and for good reason.

I thought we were heading toward a process to identify domain names that 
should not be in the DNS for engineering reasons.  In practice they're 
likely to be TLDs, but I can imagine hypothetical situations where someone 
invents a son-of-onion under .ARPA or somewhere else.

Regards,
John
[email-masked] (try it if you dare)

---

From: Ray Bellis <[email-masked]>
Date: Sun, 05 Jul 2015 08:17:03 +0100

> classes aren't really different namespaces.

Andrew,

Can you please elaborate on what you mean there?

Sure, CNAME is *defined* for all classes, but AFAIK there's no way to 
"jump" out of one class into another using a CNAME.  If you've queried 
in class FOO and see a CNAME then the resolution of the target of the 
CNAME should continue in class FOO.

RFC 1034 §3.6.2:

"CNAME RRs cause special action in DNS software. When a name server 
fails to find a desired RR in the resource set associated with the 
domain name, it checks to see if the resource set consists of a CNAME 
record with a matching class. If so, the name server includes the CNAME 
record in the response and restarts the query at the domain name 
specified in the data field of the CNAME record."

kind regards,

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 5 Jul 2015 13:51:08 +0200

On Sat, Jul 04, 2015 at 09:16:17AM -0700,
 Steve Crocker <[email-masked]> wrote 
 a message of 21 lines which said:

> except for the additional load it places on the root servers,

RFC 7535 could be a solution.

> I propose augmenting the DNS to include entries in the root that
> serve the purpose of giving slow NXDOMAIN responses instead of quick
> responses for those strings that the IETF has identified as not
> TLDs.

If it is a serious proposal, I object. Delaying answers require
keeping state in the authoritative name server and opens a nice DoS
boulevard.

---

From: Steve Crocker <[email-masked]>
Date: Sun, 5 Jul 2015 04:56:21 -0700

> keeping state in the authoritative name server and opens a nice DoS

Hmm… It would be acceptable to simply dump requests for those names if the load is too high.

---

From: P Vixie <[email-masked]>
Date: Sun, 05 Jul 2015 13:11:31 +0100

Delay is expensive for responders since it requires state. Steve's goal of making some tld strings flaky so as to encourage developers to avoid DNS for those names could be met statelessly. For example delegate them to localhost.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: P Vixie <[email-masked]>
Date: Sun, 05 Jul 2015 13:14:16 +0100

Right. Cname does not cross classes.

In original DNS, class was incoherently sometimes an attribute of zone data and sometimes a namespace selector. In modern DNS it is coherently always the latter.

---

From: Steve Crocker <[email-masked]>
Date: Sun, 5 Jul 2015 05:30:26 -0700

Stephane and Paul,

I’m ok with anything that provides effective negative feedback.  Dropping queries or redirecting them is ok with me.

Thanks,

Steve

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 5 Jul 2015 14:32:00 +0200

On Sun, Jul 05, 2015 at 04:56:21AM -0700,
 Steve Crocker <[email-masked]> wrote 
 a message of 23 lines which said:

> It would be acceptable to simply dump requests for those names if
> the load is too high.

In that case, resolvers try and try again, which is even worse for the
authoritative name servers. Also, deciding whether to reply or not may
be more work than just replying.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 5 Jul 2015 10:44:40 -0400

On Sun, Jul 05, 2015 at 08:17:03AM +0100, Ray Bellis wrote:
> 
> Sure, CNAME is *defined* for all classes, but AFAIK there's no way to "jump"
> out of one class into another using a CNAME.

No, that's correct.  But if the point of using a class is to create a
separate namespace, then the fact of class-independent RRTYPEs means
you can't do that.  As Paul Vixie notes, there appears to be some
ambiguity with CNAMEs on this front, but as nearly as I can tell RFC
6672 makes this plain for DNAME.

Imagine the alternative-resolution class FAKE.  In the IN class,
example.com has a DNAME entry pointing to example.net.  What should
happen when someone performs a query for QNAME localentry.example.com,
TYPE AAAA, and CLASS FAKE?

RFC 6672's description of the algorithm does not use CLASS as a
distinguishing criterion.  So, I think the answer is the DNAME
processing should return the results for localentry.example.net,
regardless of the class.  As a consequence, CLASS does not work to
provide different completely independent namespaces, and therefore
co-ordination across the class registrations will be necessary.  In
effect, CLASS doesn't work.

At least, that's my reading of the RFC.  I'd be pleased to be wrong.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Sun, 5 Jul 2015 17:16:05 +0000

> TYPE AAAA, and CLASS FAKE?

What *should* happen, IMHO, is the DNAME shouldn't come into consideration
because it only exists in class IN. localentry.example.com/FAKE/AAAA is in
a different namespace entirely, and a query for it should never reach the
example.com/IN zone.

What *does* happen is unclear; maybe nothing.  To the best of my
knowledge, nobody currently uses non-IN namespaces except for strictly
local authoritative data such as version.bind/CHAOS/TXT.  I'm not sure
whether it's even theoretically possible to do more than that today; in any
case it hasn't gotten much attention from implementors or operators, so if
the code exists, it's not being exercised.  Non-IN delegation and recursion
probably aren't adequately specified, certainly aren't adequately tested,
and if my interpretation above is correct, they'd imply a need for a
./FAKE root zone alongside the ./IN one, which opens up multiple cans of
distressingly wiggly worms.

However, I can imagine a mechanism in which a query for some.tld/FAKE
instructs the local resolver to use an alternate resolution mechanism for 
some.tld, with the DNS protocol being used only for that first hop.
This might be suitable for things like .onion.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ray Bellis <[email-masked]>
Date: Sun, 05 Jul 2015 22:38:18 +0100

> a different namespace entirely, and a query for it should never reach the

I agree.  I very strongly suspect that the omission of explicit QCLASS
matching in DNAME is a simple omission that none of us caught at the
time rather than a deliberate attempt to make DNAME class independent.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 5 Jul 2015 22:01:55 -0400

Two message replies in one:

On Sun, Jul 05, 2015 at 05:16:05PM +0000, Evan Hunt wrote:

> the code exists, it's not being exercised.

You're quite right that nobody is really exercising classes anyway,
but if you read RFC 1034 the story doesn't get a lot better.

One could argue that CNAME and DNAME do not alias namespaces across
class boundaries because when you do the DNAME and CNAME
substitutions, you do it "matching down, label by label, in the zone."
That would seem to help, except that if you look up what a zone is
RFC 1034 (section 4.2) says this:

    The class partition is simple.  The database for any class is
    organized, delegated, and maintained separately from all other
    classes.  Since, by convention, the name spaces are the same for
    all classes, the separate classes can be thought of as an array of
    parallel namespace trees.  Note that the data attached to nodes
    will be different for these different parallel classes.

Since the RDATA for a CNAME or DNAME is another point in the tree, the
above convention would suggest in fact that you _can't_ point to a
different alias (or else, we'd get a very unusual meaning of the terms
"parallel" and "same").

> Non-IN delegation and recursion

Especially if you're also supposed to honour some convention about
parallel namespaces.

> This might be suitable for things like .onion.

If all we want is a convention for instructing the local resolver,
repurposing classes seems like a lot of work.  After all, apparently
Bonjour and Tor -- and for that matter, DKIM -- are able to figure
this out by grovelling through magic labels in the owner name.  It's
filthy, but the code all shiped ages ago.

> time rather than a deliberate attempt to make DNAME class independent.

I recall quite clearly raising the issue at the time (though maybe not
on dnsext -- perhaps only in private conversation.  That'll teach me),
because I had the distinct, um, pleasure of simultaneously trying to
explain DNAME to people who thought it would magically solve all their
variant issues, and trying to understand a certain M. Morfin's plan to
bootstrap his Intersem using new classes.  I would have liked it if
the answer to everyone I could think of was, "Please do what you like
with your namespace," but it didn't seem to work that way.  So this
was not at least an oversight in my case.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: manning <[email-masked]>
Date: Sun, 5 Jul 2015 23:43:05 -0700

While not Paul or Stephane, I would like to point out that repeated, empirical evidence shows that simply dropping or ignoring queries has the 
operational effect of link saturation.   A quicker, more reliable DDoS vector may not exist.  I could not agree that dropping queries is sensible or
prudent, if the goal is to have a workable DNS.  As to delay as a mitigating strategy, well, that didm;t work so well either.  The original RFC 1918
blocks had no public DNS service.  We then made the mistake of standing them up.  The intent was to delay the response, with an NXDOMAIN first
and then a redirect into the private network.  It was never flaky enough and developers built around that.  This became apparent when we actually 
started responding authoritatively from these servers.   I think it was less than an hour before Herb and Jon were in my office and we had a call with
the President of the University.   Neither delay, nor redirection will be effective.  Either no answer or an authoritative answer give the community certainty.

I’ll step back and let the experts “solve” this.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Evan Hunt <[email-masked]>
Date: Mon, 6 Jul 2015 06:48:18 +0000

> different alias (or else, we'd get a very unusual meaning of the terms

The remark prefaced with "by convention" doesn't strike me as particularly
definitive.  There's no .bind TLD in class IN, yet version.bind/CHAOS
exists in many DNS servers, therefore the namespaces aren't actually
parallel or the same, whatever the authors may have expected to happen
at the time 1034 was written.

> filthy, but the code all shiped ages ago.

Point taken, but the problem we're facing is magic special-purpose labels
potentially being repurposed in the global DNS and thus becoming ambiguous.
Allocating class ONION, class MDNS, etc, for things like this may actually
turn out to be less trouble in the long run than ensuring that ICANN never
sells anybody a TLD called .onion.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jul 2015 08:31:24 -0400

On Mon, Jul 06, 2015 at 06:48:18AM +0000, Evan Hunt wrote:
> definitive.

I suppose I'd feel better about that if LDH weren't enshrined at least
in operational policies all over the Internet.  But I suppose you're
right: we could issue a document formally deprecating the convention
and then explicitly noting that since aliases are defined in terms of
zones, therefore alias processing is not permitted to cross class
boundaries and can result in non-parallel name spaces.  In principle
classes would be useful again (though you're still right to note that
the code is almost completely unexercised.  I have been led to believe
that Jefsey Morfin and his friends intend to run/are running an
experiment using classes, so perhaps we're in for some excitement).

> sells anybody a TLD called .onion.

ICANN does have a policy that entries in 6761 are automatically out of
bounds, and I can't imagine the parallel universe where they decided
that was a bad rule.  So I'm not super worried about a collision.

You have an interesting point anyway, however, which is I guess what
Bill was saying in the first place.  If an application actually wanted
to protect itself from DNS processing the answer would not be to use a
magic string (which could well leak to the IN-class DNS) but instead
to call for resolution using a different class.  I wonder how many
libraries allow you to specify this.  I observe that at least the
getdns API has it available.  Maybe it really is time for another class.

I seem to recall that John Klensin suggested a separate class to
handle IDNs many years ago.  I'll see whether I can find any of the
relevant discussion as to why that road was not followed.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 07 Jul 2015 10:50:39 +0200

Steve Crocker writes:

 > Folks,
 > 
 > I`ve been watching the dialog on this list regarding to level names.
 > Attached is my attempt to clarify the state of affairs and identify the
 > loose ends.  Both PDF and pptx versions attached, the latter in case
 > someone is moved to edit the slides directly.

Either I don't understand the slides or they seem to be inconsistent.
As an example, you defines 8 "states" [1] and 8 definitions (later
called "Categories: when you give exanples. However the examples
doesn't match the definitions:

	Definition 2: Names that have not been formally recognized but
		are being used privately or for applications that have
		not yet become standard

	Definition 3: Two letter Latin characters that have not yet
		been assigned by the ISO 3166 maintenance agency but
		might be in the future.

	Category 2: xq

	Category 3: onion

Are these mistakes or purposely. (There seem to be more of these cases
on the slides).

	jaap

[1] I'm not sure whether this is a proper term. Can one state move to another?

---

From: Steve Crocker <[email-masked]>
Date: Tue, 7 Jul 2015 17:21:49 -0400

Jaap,

This was a mistake on my part.  I was working at my laptop and didn’t have space to see everything at once.

As a separate matter I didn’t see a copy of my submission, and I incorrectly assumed it hadn’t gotten through, perhaps because attachments weren’t allowed.  I was wrong, but it caused me to resubmit a text-only version.  The error, along with another error, were corrected, and I updated the text slightly.  I have also updated my slide deck in case I need to use it another time ;)

With respect to terminology, I am now using “name” to mean a top level string.  Some names are top-level domain names, i.e. TLDs, and some are not.  I am using “subset” instead of state to designate the status of a name.  I have in mind that at any given time, each name is in exactly one of these subsets.  If we need to create more subsets, that’s fine with me.  This is a draft that is intended to stimulate a discussion.

Thanks,

Steve