Subject: [DNSOP] Some distinctions and a request

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Jun 2015 13:07:22 -0300

Dear colleagues,

Perhaps it's to do with blood flow to my brain due to my experiences
this week, but I've been contemplating some distinctions that we have
perhaps not made as clearly as we might in respect of RFC 6761.  This
message is an attempt to lay those out.

RFC 6761 contains a number of questions for how to determine whether
something is a special-use name, but I think there may be missing a
distinction that is useful.

It seems to me that, for any domain name, there are three things that
are relevant:

1.  The namespace.
2.  The registry for that name (in the old-fashioned, not ICANN, sense)
3.  The zone at that name.

RFC 6761 appears to suggest that one should not have a special-use
entry that definitely appears in the zone at the special-use name.  I
suggest in addition that we have a distinction to make.

At least some special-use names are in-band signals of a protocol
shift.  For instance, logically speaking local in the root zone is not
really a special name that is in the registry, but not in the zone.
Instead, it's a signal that one should query on port 5353.  (This does
not mean you can't implement this with tricks in the DNS, or that you
might not find some way to respond in DNS for local. queries; just
that the _point_ of the string is a protocol switch.)

Some other possible special-use names are really names that are
expected to appear in DNS contexts _but_ that are not expected to
resolve in the global DNS context.  We can think of these as
_negative_ entries in the target DNS registry: registrations that are
supposed to prevent other registrations and are supposed to prevent
DNS resolution in the global DNS.

I think these distinctions need to be make clear.  In addition, I
think it would be really helpful if these distinctions were made in
the special-use names registry document, which makes me think that RFC
6761bis is needed.

I think this topic should be on the agenda for Prague.  I also think
that it would be really helpful to keep these distinctions present to
mind in additional discussions of the topic.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 25 Jun 2015 12:51:46 +0000

>3.  The zone at that name.

I have to admit that this list isn't clear enough for me.  When you same
"name space" are you referring to a domain name space or a more general
name space.  I ask because the last entry "the zone" is specific to domain
names.

With "onion" as the root of a namespace for Tor (sorry, maybe the term is
off), it has names in it that are in the "Tor name space".  There's no
"zone" in the DNS sense related to this, because this is not DNS.
However, there is talk that the TLD "onion." ought to remain, forever, a
non-existant name (as defined in RFC 4592 [The wildcard one]) and that
then means there should be no zone for "onion."

Just a bit confused.

>shift.

>resolve in the global DNS context.

These are two very different things.  The first is that the name's look
implies how it is resolved (mapped to an address, say).  The latter is how
the DNS is impacted by a domain name that looks similar to the name in
question is treated.

I don't know if this comment is related, and I think I've said this before
(so guilty of repeating myself perhaps), the special-use domain-name
registry isn't very useful unless it indicates what someone/something
looking up the registry ought to do with the name besides not asking the
DNS for it.  In this case, "in-band signals" should be made explicit in
the registry.

But are the two things Andrew has really separate?  I mean, isn't the
registry saying "this" has a non-DNS purpose and DNS ought not make it
exist?  Yes, the the two are different (separated by the and in the
previous sentence) but are related outcomes from the use of the name in
some special way?

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jun 2015 13:43:00 -0400

Hi Ed,

> name space.  I ask because the last entry "the zone" is specific to domain

In my view, the namespace is the logical space of all possible domain
names.  So, it includes any name that has at least one label.  Any
label may be no more than 63 octets long.  The whole thing can only be
255 octets long.  In presentation format, each label is separated by a
dot.  Frequently, the last dot (and the final, null label) is
implicit.

In this namespace, I claim, there are several registries.  One such
registry is a special-names registry.  This registry has a bunch of
rules for ho things get into it.  The things that get in are domain
names, but they are not necessarily DNS names.  In my view, local. and
the proposed onion. are both non-DNS domain names.  Indeed, their very
function is to act as a switch to a resolver, to tell it, "The name
anchored here is not in the DNS, but is resolved in some other way."

The rest of the registries in the domain name space -- the ones that
cover all the parts of the namespace not excluded by the special-names
registry -- are DNS domain name registries.  One of these is the root
registry.  In those registries are two kinds of registrations: ones
that are there to enable further delegation (a "positive
registration", to give this a name), and ones that are there to
_prevent_ further delegation (a "negative registration").  For
instance, com. is registered in the root zone, as a delegation point.
Conversely, IETF is on the reserved strings list in the Applicant
Guidebook (section 2.2.1.2.1) and is therefore, I claim, in the
registry to prevent further delegation.  Similarly, the rule about all
2-letter strings that are not in the ISO 3166 short codes list is such
a preventative registration.

Finally, there is the zone file, which contains the positive
registrations in the DNS.

(Naturally, by way of implementation, one could turn all negative
registrations into entries in a zone file, by registering TXT records
that said, "This name is not registered for resolution on the
Internet," or something like that.  Let's stipulate that this is a
special case, but I don't think it obscures the point I'm trying to
make.)

> off), it has names in it that are in the "Tor name space".

Yes, but as I understand it the rule is that such names are also part
of the domain name space.  (There could be a future time where some
names beneath onion. are actually longer than the DNS would permit,
and I don't know whether to call such things "domain names" or not;
but it's fortunately not a problem for us today so I'm going to ignore
it.)

> There's no "zone" in the DNS sense related to this, because this is
> not DNS.

Yes.

> then means there should be no zone for "onion."

I claim that, because of the function of onion., a registration of it
in the special names registry effectively takes it out of the DNS name
space (while maintaining it in the domain name space).  For that
reason, onion. MUST NOT be registered in the DNS root; but that's
because its name is excluded from the DNS namespace and not because of
something special it does with respect to DNS.  This is different from
(say) ietf., which _is_ in the DNS name space (it's registered there,
though negatively).

Does this make the distinction I'm trying for any clearer?

> the DNS is impacted by a domain name that looks similar to the name in

No, I don't think I was saying that.  The first is a case where, if
you match that label, you get a signal that you are walking out of the
DNS name space and into some other protocol.  For instance, if you
encounter a domain name with the top-most label "local.", you
immediately know that you shouldn't look that up in DNS, but instead
in mDNS.  The second case is where a name _is_ part of the DNS, but is
not registered in some special way.  "Example.com" is an example of
this: it shouldn't normally give back results in the DNS, because of
its special function.

> DNS for it.  In this case, "in-band signals" should be made explicit in

Doesn't the existing registry (which gives a link to the defining
document) do that?

> previous sentence) but are related outcomes from the use of the name in

I am claiming that there is a logical distinction here that can help
us make evaluations.  For instance, one could argue that we ought to
distinguish between (say) corp. and onion.: the latter functions as a
protocol switch, and needs to be out of the DNS namespace.  The former
is in fact in active use in DNS names all over the place, and that's
what makes it dangerous.  It is not obvious that the evaluation
criteria in each case ought to be the same.  Significantly, for
protocol-switch questions there is little in the way of positive
empirical evidence that ought to count.  (Though if someone came along
and asked for a special-use registration of something already
registered in the DNS namespace, either positively or negatively, we
might want to ask different questions.)

I hope this helps,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 30 Jun 2015 11:43:42 +0000

>In my view, the namespace is the logical space of all possible domain

That certainly narrows the discussion for me.

>In those registries are two kinds of registrations: ones
>_prevent_ further delegation (a "negative registration").

In the sense that the DNS name space is bounded - there's only a finite
set of names it can contain - there exists a complete roster of all names.
 You can then divide the list into names that have a responsible party and
those that don't - and call that (positively registered) and not (or
negatively) registered.

I separate registration from delegation.  Registration means I have
entered the domain name in database (or register as a noun) with some
characteristics.  The characteristics include contact information (e.g.,
technical, abuse) and/or whether the name is available for some operations
(etc., delegation, re-registration).

Delegation refers to the "DNS as per STD 13" action of entering NS records
and giving total control of the names below the name in the DNS namespace
tree to an (possibly different) authority.  Not all names in the register
get to be delegated because of rules like reserved names, IDN variants,
rules rooted in the policy of the registration activity.

>but it's fortunately not a problem for us today so I'm going to ignore

I'm not aware of "the rule" that declares Onion names as part of the
domain name space.  Not an argument, just a data point.  I've always
heard, and have been running on this, that Onion names are not part of the
DNS name space.

If Onion's namespace permits names that cannot be part of the finite
roster of DNS name space, then I derail seeing how Onion names are domain
names.  With that, any sort of logic to meld the two name spaces falls
apart.  This isn't a criticism of either name space.

>(say) ietf., which _is_ in the DNS name space (it's registered there,

Let me go backwards.  I asked the WhoIs server of IANA and it does not
know of "IETF."  "IETF." is in the finite roster of domain names, it is
not delegated (owns no NS records) and is not present in a register as far
as I can tell.  Perhaps it is in a register as a name assigned to some
entity and is not eligible for delegation, but I can't find the register
(easily).  And to throw this in the mix, the name is non-existent within
the DNS protocol (RFC 4592) because it owns no resource records sets and
has no descendants - yet it is a member of the finite roster of possible
names.

I think/assume/believe that Onion is name that has been deployed through
out the network in such a way as to set up a potential conflict with the
use of "onion." as a domain name.  I say "think" because I am going on the
list discussion, I have no hard evidence of it - only because I am a
curmudgeon when it comes to technology.  Given the apparent deployment of
the name, it is probably wise that it not be delegated in the public DNS,
i.e., the system that is in use where Tor also operates.  (I.e., not in
the protocol, but in operations.)

The special-use domain names registry is apparently the right place to
register the name.  But to me that is an incomplete process.  Who or what
is the entity that is assigned/owns the name?  (Okay, the registry
identifies an RFC that ought to have that information.)  Once registered
in that way, should the name be delegated?  What I hear is no.  Is being
an entry in the special-use domain names a barrier to delegation?  I
assume so. Is being an entry a barrier to being used in the DNS?  This is
not clear - I can ssh to a .local machine.

>Does this make the distinction I'm trying for any clearer?

Perhaps.  (Despite the mangling of the question...;)...I've got a pretty
clear distinction in my head how this works, I don't know whether we are
converging though.

>The first is a case where, if you match that label, you get a
>signal that you are walking out of the
>DNS name space and into some other protocol.

My analogy is human spoken languages.  I was once in Holland and
approached by a waiter.  I thought the waiter addressed me in German
(which would be odd), so I responded in German.  I then discovered it was
German-influenced Dutch he was speaking.  Just because something sounds
like German doesn't mean it is, it might be Dutch.  Just because something
looks like a domain name doesn't mean it is, it might be an Tor
identifier.  Outside of trying one and failing, falling back to some
other, I don't see a way to meld the two spaces.

>The second case is where a name _is_ part of the DNS, but is
>not registered in some special way.

For that, and because you mentioned the special word "registered", there
are registry database inspection protocols (WhoIs, IRIS, RDAP) that, at
least by design, handle that distinction.  Granted, IRIS went no where and
RDAP is still wearing diapers, but I'm talking intent here.

>Doesn't the existing registry (which gives a link to the defining

Not programatically.  Code can't read RFC. ;)

I imagine I am a thread in java.  I can use those cool RESTful interfaces
and JSON notation to guide my way through code paths and libraries to
decide how to transmit some information to an identifier.  Obviously, an
English parser isn't what I want to carry around.

>might want to ask different questions.)

Alain Durrand and I talked about this a few weeks back.  He made the point
that you can distinguish the namespace of an identifier "on the right" or
"on the left" imaging the use of names in URLs.  I.e., there could be a
"http-tor://tor-name.onion/path" and use http-onion to tag this as a Tor
identifier or "http://tor-name.onion/path" and assume it's Tor because of
the onion where I'd expect(*) a domain name to be.

* - It is important to say that I only expect a domain name to be there -
I never was able to find out whether the http
method/schema/etc/I-forget-the-word expects the first part of the path
name to be a domain name or not.

Logically, yes, there is a distinction between Tor's name space and the
DNS name space.  I'm not sure though that the distinction is detectable in
how we render in words or bits the identifiers.  The special-use domain
name registry is an attempt to do that but, in my opinion, it isn't a
complete solution as it doesn't help code (for one).  (And I do have
non-specific concerns over the admission criteria to the registry, i.e.,
the corp/onion divide you mention.)

---

From: Ray Bellis <[email-masked]>
Date: Tue, 30 Jun 2015 12:48:15 +0100

On 30/06/2015 12:43, Edward Lewis wrote:
> Is being an entry a barrier to being used in the DNS?  This is

So can I, but that's because my computer's name service stub used mDNS
to find it, not DNS.

Ray

---

From: Edward Lewis <[email-masked]>
Date: Tue, 30 Jun 2015 11:55:59 +0000

On 6/30/15, 7:48, "DNSOP on behalf of Ray Bellis" <[email-masked]

>So can I, but that's because my computer's name service stub used mDNS

Would the same code handle .onion?  (Perhaps a new version via RPM push.)

Is relying on software updates scaleable?

This is the flip side of whether the name ought to return NXDOMAIN if the
DNS is queried...

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jun 2015 11:18:01 -0400

> those that don't - and call that (positively registered) and not (or

This is a different use of "positively|negatively registered" than I
outlined.  The case that I was talking about I think _does_ have an RP
for the negaitve registration.  But that registration is there to
prevent delegation.  Another example of this is the controversial
reservation practices in xxx and sucks: you pay your money for a
registration to guarantee that the name will _not_ be delegated.

> tree to an (possibly different) authority.

Yes, exactly.

> heard, and have been running on this, that Onion names are not part of the

You're conflating "DNS name space" and "domain name space" again.  I
didn't say they're part of the DNS name space; and given what the
top-level label onion. does, they can't possibly be.  At the
beginning, I claimed that the domain name space was all the logically
possible domain names, not all the ones in fact possibly in the DNS.
Under this definition, local. is part of the domain name space and not
part of the DNS name space (because of local. being registered in the
special use names registry).

When I asked about this before, one of the onion proponents told me
that onion names have to conform to DNS (and, he claimed, LDH) rules
right now, though that is a possibly temporary convention. 

> as I can tell.

That's because you're assuming that the whois contains all
registrations in the top-level name space.  I wish it were true that
ICANN, in its role as steward of the root zone, registered things in
the root whois that it was registering/reserving from allocation to
others.  But it doesn't, for reasons known best to itself.  The AGB
clearly reserves some names from use, which I think pretty plainly
puts them into the DNS name space and outside of eligibility for other
registration.  That is, I claim, a negative registration of the name.

> use of "onion." as a domain name.

This line of argument is collapsing the very distinction I was trying
to make.  Onion and (say) corp both have that property, but only one
of them is functioning to signal a protocol change.

> identifies an RFC that ought to have that information.)

Are you arguing that is inadequate?  If so, a reason why would be nice.

> Once registered
> in that way, should the name be delegated?  What I hear is no.

I think pretty obviously this depends on the use case, which goes in
the defininig RFC if I read 6761 correctly.

> My analogy is human spoken languages.

Where computers are concerned, that is almost always a mistake.

> Not programatically.  Code can't read RFC. ;)

But it can implement one.

> the onion where I'd expect(*) a domain name to be.

I think this is a terrible confusion of URI schemes vs. name-space
switches.  It's true that if you treat the URI as an unformatted
string you can parse it this way; but there are already rules for
that.  But I think anyway that's a distraction.  We don't need
uri-schemes to creep into this.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 30 Jun 2015 16:27:10 +0000

>registration to guarantee that the name will _not_ be delegated.

So this is about words - what you call a negative registration is a
registration nonetheless, with an responsible party.  If I want to
delegate a name that is registered "negatively", I can go to the
responsible person, trade with them and then get the name delegated so
long a all policies are followed.  It's like buying the house lot next to
yours to make sure no one builds on it.

But I don't think this is a significant point of contention.

>You're conflating "DNS name space" and "domain name space" again.

How can I not (conflate them)?  I don't follow you.

>I didn't say they're part of the DNS name space; and given what the
>top-level label onion. does, they can't possibly be.

I have some trouble parsing, let alone understanding, that sentence.
"They" in "they're part" refers to the names ending in "onion."?  From
what I understand that would be a $key.onion.  I don't grok how
$key.onion. "can't possibly be" a domain name given that "onion." is.  (Or
isn't, I'm just confused.)

>At the

Here my confusion is centered on "not all the ones in fact possibly in the
DNS."  Do you mean names of greater than 256 octets, etc., not possible
because they violate syntax rules?  Or...I don't follow.

I don't see that "local." is not part of the DNS name space.  It's in the
special-use domain name registry.  Perhaps it's confusing because RFC 6761
defines "Special-Use Domain Names" and not Special-Use Names.  From the
title, I assume that the list if objects are domain names that are part of
the DNS name space that are accorded special status for some reason.
Which fits "local."

>registration.  That is, I claim, a negative registration of the name.

Well, it's odder than that.  There is ICANN's WhoIs and IANA's WhoIs.  I
mentioned IANA's specifically for a reason.  And I'll defer to the comment
that WhoIs isn't totally representative of what's in the registration
database (anywhere, all the time).  I really don't know if there is a
formal listing of "IETF." as having any status in any register.  (Using
the dictionary definition of register as an official roll.)

What's "the AGB"?

>But it can implement one.

No, people can implement an RFC.  Perhaps this isn't a point that will go
far, but, DNS has defined "unknown types" which can future proof servers.
General apps don't have something like that.  I mean - if the app can ask
the registry for the names, it can react somehow (I won't expand here).

>uri-schemes to creep into this.

That was partly mean as an example of how to separate namespaces.

After this exchange, I'm still confused - are Tor Identifiers domain name
or not?  Is there an intersection or not?  Or is it just a "they look the
same?"

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jun 2015 18:53:32 -0400

On Tue, Jun 30, 2015 at 04:27:10PM +0000, Edward Lewis wrote:
> registration nonetheless, with an responsible party.

Well, it's about conceptual clarity.  If we want to call that
"negative registration" instead "skippy the wonder dog", I don't care.
But there's a difference between "positively registered with someone
that delegation is not allowed" and "a possible name enumerable in the
namespace that is not registered."  I hope we can agree on that.

> How can I not (conflate them)?  I don't follow you.

I am trying to draw a distinction.  I'm going to try one more time
here on the list, begging everyone else's indulgence, and then if that
doesn't work I'm going to figure that I can't explain it.  Perhaps
another way to say this is that the term "DNS" has taken on a separate
meaning from "domain name", but I think that's not necessary:

On the one hand, we have the domain name space.  It encompasses within
it all the logically-possible domain names.  These are all the names
of one or more labels, where one label is null length and is the last
label, and all the other labels are between 1 and 63 octets.  The
whole name must be under 255 octets.  Otherwise, there is a variable
number of labels and each label may vary in length according to the
above restrictions.  It is, as you point out, a finite name space.

On another hand, we have the _DNS_ space.  This is a subset of the
domain name space as such.  The DNS space is all the names covered in
the domain name space, that may in fact be registered (not just
delegated, but registered) in the DNS.  (Note that DNS means domain
name system, so another way to say this is that these are the domain
names that are in fact allowed in the system.)  I say that
protocol-switch names like local. are inside the domain name space,
but not in the DNS space, because they function to switch any lookup
out of the domain name system and into some other resolution
mechanism.  Other special names do not have the same effect --
invalid., for instance, does not.  (Note that one consequence of this
is that the null-length label is special in more than one way, because
it has to exist in every system namespace.  I think that's all right,
because these different names are all within the domain name space,
just not in the DNS space.  It's conceptually hideous, but I can see
why people do it in implementation.)

(I'm leaving out the zone space here, because that's yet another
subset, of DNS space, and we seem to agree about that.)

> $key.onion. "can't possibly be" a domain name given that "onion." is.

both $key.onion. and onion. are domain names, but they're not in the
DNS namespace.

> because they violate syntax rules?  Or...I don't follow.

There are names outside the domain name space, yes.  A name that has a
label longer than 63 octets is outside the domain name space.

> defines "Special-Use Domain Names" and not Special-Use Names.  From the

Yes, they're domain names, but not DNS names.  

> mentioned IANA's specifically for a reason. 

Ok, a fair point.  But surely ICANN could register names that it will
not (by policy) admit to the IANA root zone in the IANA whois without
any delegation?  Hmm, I suppose not, given the IANA rules for
registrations.  This is an interesting policy problem, but fortunately
not one we have to discussion on DNSOP.  I understand there was a
large meeting recently that might have presented a forum for this.

> the dictionary definition of register as an official roll.)

It's in a list in the Applicant Guide Book, as I mentioned in the
previous message.  Given that the AGB is the holy tome of new
non-ccTLD allocations for registration by ICANN, I think that counts
as an official roll.
 
> What's "the AGB"?

"Applicant Guide Book".  "AGB" seems to be a common shorthand for this
in ICANN circles.  Sorry for the jargon.

> No, people can implement an RFC.  

Yes, and then they have an implementation which implements the RFC.
At least, that's the way people say such things to me.  I agree it's
too bad that we don't have the lexico-grammatical precision in English
that Latin does, but here we are.

Anyway, I hope this helps.  If not, then perhaps I'm completely wrong
or perhaps I'm just doing a poor job explaining myself to you.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]