Subject: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Dec 2013 19:04:13 -0500

Dear colleagues,

I made some remarks in the earlier discussion of
draft-grothoff-iesg-special-use-p2p-names-00.  In this message, I
attempt to review draft-grothoff-iesg-special-use-p2p-names-01
completely.  I hope these remarks are useful.

Overall
=======

I remain extremely concerned that this effort represents another step
along a deep and extremely confusing path of mixing the domain name
system and other name spaces.  I think the IETF needs to figure out
whether we're going to accept that, historically, we had multiple name
spaces but that now we're going to have one big one; or whether we're
going to continue pretending that every other name space doesn't end
up wandering into the DNS anyway.  (If there are additional
alternatives, I am unable to think of them.)  I think a pragmatic
answer is to accept that, given the number of places we expose domain
name slots, anything that uses a name is going to end up having to be
somehow compatible with domain name slots.  But I think that is a
wide-ranging discussion that almost certainly needs to be tackled
#separately from the consideration of this particular draft.

For the purposes of this draft, I think it would be extremely good if
the draft included a section actually documenting the deployment of
these top-level labels on systems in reasonable use on the Internet.
The mere existence of some software somewhere isn't enough.  There
needs to be some evidence of deployment, I think, because otherwise
this is just a case of label-squatting.  That is, if the justification
for normalizing these names is just that some software implemented
them somewhere, then that becomes a trivial mechanism by which people
can do an end-run around the ICANN TLD procedures.  Therefore, I think
for this case we need some evidence of significant existing deployment
of these names in order to meet the terms of the first paragraph of
section 4 of RFC 6761.  (So, this requires an expansion of a paragraph
in section 1 into at least a paragraph for each label.)

The RFC 6761 questions to be answered for each reservation are
answered in this draft in section 5.1, with the questions answered for
all of them.  I think this is a mistake, because I think the
properties of the different names are actually different.  It'd be
much better just to refer to the 6761 questions, and say "here are the
answers" in each case.  So, just for example. I think these are the
answers for the .gnu label:

    1.  Yes.  Users must install GNS to use names under .gnu.
  
    2.  Yes.  The application needs to be GNS-aware, or else the
    application environment must support GNS.

    3.  Yes.  GNS is a parallel name resolution system and a
    GNS-capable resolver will need to know how to resolve such names.
    A GNS-incapable DNS resolver will always receive RCODE=3 (Name
    Error) for any name beneath .gnu.

    4.  No.

    5.  No.

    6.  Yes.  The .gnu top-level label "shifts" the name space to GNS
    as opposed to DNS.  A DNS operator that attempts to configure the
    .gnu name space is therefore treading on the GNS name space.

    7.  Every such registry and registrar should reject such
    registration attempts.  

Something along those lines for each requested label.  Also, see below
about particular issues I have.

_Many_ of the references seem to be works in progress or unstable web
pages.  That needs to be fixed for this document to be a useful
specification.

Particular items in the draft
=============================

Abstract: "designed to help harden name resolution security,
   provide censorship resistance, and protect the users' privacy on the
   Internet."  

I think that's just polemical.  The purpose of registering these names
is, as I understand it, that they're already in use in deployed
systems, so you need to register them for interoperability purposes.
Right?  I suggest saying that instead.  If you really need a
motivation for the uses, then something like, "designed to help users
in non-DNS contexts where DNS-style names are useful for the
applications described in this memo."  You can get into the motivation
for the applications in the text if you want, but not in the abstract,
please.

Terminology:    
   The acronym "pTLD" is used as a shortcut to mean a pseudo Top-Level
   Domain, i.e., a name or label for a network not present in
   operational DNS, and not registered with IANA for use within the
   scope of operational DNS.

I'm not sure I get this.  If this document is published, what happens
is that the candidate labels become real, genuine labels registered in
the DNS.  It just so happens that they appear in no zones, because
they are in effect allocated and not delegated.  I think of allocated
names as still being 'part of' the DNS: .invalid is still part of the
DNS.  I also think it's confusing to claim that these names aren't
"part of" the DNS when the whole procedure here is in fact for putting
the names into a DNS registry.

   In this document, ".tld" (with quotes) means: any domain or hostname
   within the scope of a given pTLD, while .tld (without quotes), or
   dot-tld, both refer to an adjective form.  For example, a collection
   of ".gnu" peers, but an .onion URL.  The pTLD itself is mentioned
   with dot, and within double quotes, and usually followed by the word
   pTLD.

I find that paragraph confusing, but it appears to be defining a term
that is then used less than rigourously throughout the document.  It'd
be better to define the use once and then make the rest of the draft
consistent with the definition.

The ".gnu" Relative pTLD:

    […] Note that ".gnu"
   names SHOULD follow the naming conventions of DNS.

What does this mean exactly?  Is this the LDH rule?  Case-insensitive
but case-preserving?  Is GNS subject to IDNA?  Or are labels just bags
of octets?  Are they only 63 octets each, with a maximum 255 limit?
"The naming conventions of DNS" have been an endless source of
trouble, and I think this needs to be spelled out in detail, or else
left out completely because it's well-specified somewhere else.

   ".gnu" names are personal, relative, and transitive: each user of the
   GNS controls their own zone that is authoritative for all ".gnu"
   domains; zones can be delegated between authorities, so that any user
   can share names, and chain labels to resolve names out of the
   requesting user's zone of control, including across several zones. 

[and the next paragraph].  I think this probably should be cut.  It's
really a description of how the GNS works, and it is neither detailed
enough to give the reader a sense of how that works (it sounds like
chaos on its own), nor plain enough to require no more explication.

The ".zkey" Compressed Public Key pTLD:

It is very far from obvious, in this draft, why this functionality
requires a whole separate TLD.  It _might_ be because of the reverse
trick, in which case say that.

The ".exit" Client Source Routing pTLD:

This one is especially problematic, because it appears to be a TLD
that results in special handling of the name to control DNS lookups.
This _really_ needs to be unpacked because it will certainly have
implications for the global DNS.  Also, "hostname" in here is a little
confusing.  The example, for instance, is
"gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit".  Once the
.exit TLD is registered, then that becomes a valid hostname (but one
that in principle always returns particular answers).  So, is it ok to
have
"gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit.f97f3b153fed6604230cd497a3d1e9815b007637.exit"?
If not, why not?  If so, what do you do when you run into the total
limit on DNS names?

The ".noconnect" Client Interruption pTLD:

If this label isn't requested, just take this section out.

The ".i2p" Addressbook pTLD:

   Apart from the ".b32.i2p" domain that is reserved for SHA-256 hashes,
   other hostnames within the ".i2p." pTLD are non-hierarchical and can
   be assigned locally: example.i2p and other.example.i2p do not
   necessarily belong to the same authority.

This looks like a recipe for future disaster.  What if you end up with
a different encoding scheme in future?  Don't you need to allow for
that?  Also, I really don't get why this one is a TLD.  It seems
like the sort of name that could be absolutely anywhere in the tree.

The ".bit" Timeline System pTLD:

Why does this need to be a TLD?  This one is to me most fraught,
because (1) namecoin sure looks like an effort that has significant
potential money-generating activity associated and (2) I can't see any
reason this had to be a TLD.

Security Considerations:

   Operation of said TLDs into the global DNS scope could as well
   produce conflicts [SAC45] due to later real use and the possible
   acquisition of intellectual property rights in such names.

   The reservation of several Top-Level Domain names for these purposes
   will minimize such confusion and conflict, and safety risks for
   users.

But if these names are added to the registry (assuming this document
is published) then surely they will _not_ be added to the DNS, because
they're already allocated in the DNS.  No?  Therefore, this isn't a
security consideration of the document, but a consideration in case of
non-document :)

Domain Name Reservation Considerations:

   1.  Users MAY use these names as they would other domain names,
       entering them anywhere that they would otherwise enter a
       conventional DNS domain name, or a dotted decimal IPv4 address,
       or a literal IPv6 address.

Really?  So I can put
ajs@[gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit]?  I bet
not.  It's simply not true that names and numbers can everywhere be
used interchangeably.

   2.  Application Software MAY pass requests to any of the six proposed
       pTLDs for normal DNS resolution if A/AAAA records are desired.
       If available, the local DNS resolver MUST intercept such requests
       within the respective operating system hooks and behave like
       DNS.

That is a _very very_ bad idea.  Either these are special names that
aren't part of the DNS, or they're not.  If they _are_ part of the DNS
because you sometimes want to get DNS data associated with them, then
they're DNS names and there's no excuse for this special registration.
Go apply to ICANN.  If they're not, then you can't have this. 

But I think what this actually means is, "If these are passed to a DNS
resolver, the DNS resolver will follow the usual DNS semantics to
resolve them.  That should result in RCODE=3 (Name Error) because the
TLD labels should never appear in the root of the DNS.  I don't like
the bits in this section that suggest "the resolver" can do different
things, depending.  What is really meant is that a resolver call on a
system might be resolving in more than one name space.  It so happens
that a non-DNS resolver might use these name spaces as triggers to do
something.  In any case, if this owner name reaches the DNS resolver,
then the expected outcome is RCODE=3.  In addition, I wonder whether
this means that these ought to be set up as "default local zones" the
way certain other ones are.  See below.

   4.  […]
       But given that ".bit" users have no special privacy requirements,
       and those names are globally unique, caching DNS servers MAY
       choose to treat them as regular DNS names, and cache the
       responses obtained from the Namecoin block chain as if they were
       resolved from the regular DNS tree.

This is, bluntly, a reason to refuse the .bit registration.  If .bit
wants a TLD, then let them get it.  Otherwise, this is a special name
and shouldn't be in the DNS, period.

   6.  DNS Server Operators MAY choose to resolve ".bit" names using the
       Namecoin block chain, and if they do so SHOULD treat such domains
       like they would regular DNS names.

Same here.  Also,

       DNS Server Operators SHOULD treat requests to the other five
       considered pTLDs as typos, for correct installations MUST NOT
       allow such P2P requests to escape to DNS.

This is ridiculous.  The _whole point_ of these special TLDs is that
you expect to hand these names around as though there's nothing
special about them.  In that case, you absolutely must expect that
these names are going to get to the global DNS (if you think they
won't, then I urge you to consider how much .local traffic makes it to
the root).  Because they don't exist in the root zone, they will be
cached for the negative TTL in the root zone's SOA (currently 1 day,
if memory serves).  So, first, that certainly has effects on DNS
operators.  Second, there's no such thing as "considering a label a
typo" except in the most egregious abuses of the DNS.  What we have is
"resolved or did not".  But perhaps what you are saying is that these
ought to be added to the list in RFC 6303, and that they should always
answer NXDOMAIN?  I could certainly live with that.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 31 Dec 2013 08:49:40 +0100

FWIW, very good summary Andrew. Resonates with what my thinking has been. Thanks!

In short:

This draft do point out a presumed need for other kind of namespaces, most notably ones that:

+ are "local but unique" where each user can have a unique namespace where the name globally is not unique

+ are non-unique globally

+ might be globally unique (some risk exists for collision)

BUT:

The beginning of this summary by Andrew do point out the for me most important thing. That this draft do trigger the need for IETF to understand how to manage the situation where multiple resolution systems do use the same namespace. For URI's IETF have historically used a prefix, a scheme, but for normal use (in web browsers for example) the scheme is no longer required. And not only that, people can today enter random strings in the user interface where the string end up being used for everything from lookups in DNS, via lookups in DNS using search paths, lookups using the DNS protocol in various ways (mdns), or keyword searches to searches in search engines. All of those mechanisms do today implicitly use the http protocol and not even the by IETF invented SRV (or URI or NAPTR) mechanisms are used for discovery of correct protocol and port.

This draft is for me "just the next step" in a natural evolution. But to some degree this is a positive event for me. The authors have obviously understood a namespace collision would be a bad thing for the user experience, and they have contacted the IETF.

To be able to move forward, I think what is needed is (I hope this is a correct understanding of what Andrew have written, and that we because of that do agree):

1. IETF must take the namespace collision issue seriously and discuss how to handle the situation

2. The draft must separate the various different kind of namespaces created, and explain explicitly which one of the strings in this draft is of what kind (and the various namespaces must have stable documentation and explanation of their functionality -- for example by publications of RFCs)

3. The .BIT string seems to be a traditional TLD in the DNS and must to be assigned as such be approved using whatever policies ICANN uses for creation of TLDs

    Patrik

On 31 dec 2013, at 01:04, Andrew Sullivan <[email-masked]> wrote:

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

---

From: Christian Grothoff <[email-masked]>
Date: Tue, 31 Dec 2013 21:06:38 +0100

Dear Andrew,

First of all, thanks for your constructive feedback.  I'll try to
answer some of your questions inline now, and we'll try to address
them in the next revision of the draft as best as we can as well.

On 12/31/2013 01:04 AM, Andrew Sullivan wrote:
> this is just a case of label-squatting.  

What kind of metric do you propose, and how do you propose to acquire it?
Let me give you a few examples:
1) # registered names --- easy for .bit (~100k), kind of possible for
   .i2p (~4000), hard for .onion (no clue), even harder for .gnu.
2) # users of the software --- almost impossible for .bit (no installation
   required), hard to tell for .onion (how to distinguish Tor users of
   .onion vs. "ordinary" Tor users?), hard to tell for ".i2p" (AFAIK
   no build-in mechanism), likely possible with error of factor 2-4 for
   .gnu; also, what's a "user" anyway?  Number of downloads? Number of
   peers running at any time? Number of users over a month?

And again, a key question for me is, if you really want to _encourage_
people to _first_ deploy at large scale and _then_ reserve the name.
Saying "once you have a large user base, we'll accept it", means IETF
has decided on a policy where people MUST just take names without checking
with anyone first, and then later "demanding" that they be reserved.
For me, label-squatting implies that someone sits on a label and makes
no use of it; so a better question might be if there should be a process
to "unreserve" names should they fall into disuse.  We've seen this with
IP addresses being returned to the pool, so I can easily imagine having
a mechanism to do this.  Still, given that there are more tLDs than IPv4
addresses, I'm not too concerned that this is an urgent issue that would
need to be addressed immediately.

> That is, if the justification
> answers" in each case.  

I think that's a fair suggestion, especially as with the addition of
".bit" the answers did get a bit more diverse.

> So, just for example. I think these are the

Well, they might be configured or modified to return NXDOMAIN, but
I'm not sure if this "configuration" change is intended to be covered
by the question.

> pages.  That needs to be fixed for this document to be a useful

I was told that i2p2.de recently moved to geti2p.net.  Which other
pages are unstable in your experience? ("Worked for me...").

> Particular items in the draft

Ok, that's editorial, but a reasonable suggestion.

> the names into a DNS registry.

Well, that's going to be a question of what people consider "part of DNS",
but we can probably find a better formulation that avoids this possible
and problematic interpretation.

> consistent with the definition.

Ok, we'll look into this.

> What does this mean exactly? 

Ok, we can make this more precise, I'll try to answer your questions
below.

> Is this the LDH rule?

Yes, in the sense of "SHOULD".

> Case-insensitive
> but case-preserving?  

Yes (on case-insensitive), and SHOULD on 'case-preserving'.

> Is GNS subject to IDNA?

Yes.

> Or are labels just bags
> of octets?  

No.

> Are they only 63 octets each, with a maximum 255 limit?

Yes, in the sense of "SHOULD". However, if the DNS protocol is not
used ("pure" GNS resolution with GNS-enabled applications where
a DNS packet is never created) is is theoretically permitted for
an application to not enforce these constraints.

> left out completely because it's well-specified somewhere else.

I can live with leaving it out. Any objections to that suggestion?

> chaos on its own), nor plain enough to require no more explication.

Ok.

> trick, in which case say that.

Yes, ".zkey" is indeed used as a way to construct a name when doing
"reverse lookups".

> If not, why not?  If so, what do you do when you run into the total

Well, it doesn't really make sense to cascade '.exit' targets like
that, as an exit is prohibited from re-entering Tor (for security
reasons).  Also, yes, in theory appending
"f97f3b153fed6604230cd497a3d1e9815b007637.exit"
even once can cause one to run over the 255 limit on DNS names,
in which case the answer is "tough luck, won't work".

> If this label isn't requested, just take this section out.

I can live with this, the question is if anyone feels like this would
be useful for documentation purposes.  But I agree with you that
it can and probably should go. Anyone against it being removed?

> that?

Well, let's say the person who designed this is no longer even
available for discussion. We're documenting the facts, not
necessarily what one might consider a well-reasoned design
choice (in my opinion).

> Also, I really don't get why this one is a TLD.  It seems

Well, if I had a 4,000-entry /etc/hosts file shared with tens of
thousands of other users, I think I would also try to put all of
those entries under some special TLD to ensure everyone knew that
I was using names from that list, as opposed to ordinary DNS names
or names in my local domain (local domain in the sense of
/etc/resolv.conf).

> reason this had to be a TLD.

Well, I always thought of Namecoin and bitcoin as money-burning
activities, but feel free to invest in Namecoin then ;-).  Still,
I'm not sure I see a provision in RfC 6761 that the activity has
to be non-profit (Apple certainly makes a profit, yet they still
got ".local" for free, right?).

I agree with you that the _technical_ reasons for a TLD are likely
the weakest for Namecoin, and I suspect the marketing/usability
concerns were the dominating reason.  But again, we're documenting
how it was deployed.

This is again an interesting split in your logic:

You suggest people to reserve pTLDs only once  they've reached
a significant size (namecoin with 100k domains is certainly
the largest of the suggested pTLDs, so you should love it!).
Naturally, if people write RFCs only AFTER they get 100k
users, it will be too late for anyone to listen to your
technical advice.

So if you really want to have these types of debates --- how
people should ideally structure their names and integrate with
DNS --- how can you argue at the same time that they should
first deploy to millions of users before reserving the name?

We have three choices:

1) We can decide that we like to influence people and thus
   should make the barrier to reserve a pTLD deliberately low.

2) We decide that we'll just have to let reality happen and
   at least document the resulting reality of the Internet, or

3) We decide to not even acknowledge the reality and pretend
   that RFCs are all there is.

I personally prefer (1), even though our draft largely
represents a case of (2).  Some members here seem to like
to argue for (3) for political reasons (i.e. it is politically
more convenient to ignore reality).

> security consideration of the document, but a consideration in case of

True. Are you arguing to remove this sentence?

An alternative might be to mention that information leakage via DNS
servers that fail to return NXDOMAIN might be a security consideration
that remains even if the draft is published.

> not.  It's simply not true that names and numbers can everywhere be

I don't quite see why this would not work in principle, assuming your
mail client is configured to route SMTP over Tor and the specified
exit supports exiting on port 25 to gnu.org.

> way certain other ones are.  See below.

I guess the question is what you define as "DNS resolver".  For example,
is the "dns2gns" proxy --- which speaks DNS (to applications) and then
forwards
".gnu" and ".zkey" to GNS and everything else to DNS --- a "DNS resolver"?

Is GNU the DNS stub resolver implemented by libc's NSS a "local DNS
resolver"? The formulation of the draft talks about these kinds of
DNS resolvers --- or simply the "gethostbyname" APIs, whereas I suspect
you talk about the resolves operated by ISPs (such as 8.8.8.8).

Naturally, I might be mistaken about what you dislike, or you might
have simply trouble with our use of terminology and what to suggest
an alternative description?  The point remains that applications
(browsers, wget, telnet, etc.) for GNS do not need to be modified at
all, or for other pTLDs the modifications are limited to the addition
or configuration of SOCKS support.

> and shouldn't be in the DNS, period.

We had some discussions about Namecoin caching (off-list) and caching
and Namecoin seem to be, eh, at odds, at least when it comes to NXDOMAIN.
So this paragraph actually needs to be revisited as the ideal behavior
for NXDOMAIN would be different. This will be updated in draft-2.

>        like they would regular DNS names.

I think you're mis-reading the point here, as the Namecoin block chain
is not obtained using the usual DNS protocol from some authority. So
DNS server operators that wanted to do this would NOT go out to some
IP address of a TLD operator that was granted ".bit" operation from
ICANN to fetch the block chain; instead, they'd have to participate
in the Namecoin network to observe block chain updates (a rather
daunting process, so this "MAY" is one that I personally don't expect
to see happening anytime soon by any major ISP).  As ".bit" is not
owned by anyone, your statement of "let them get it" is interesting
--- "them" doesn't exist: AFAIK, there is no business, no (clearly
identifiable) lead developer or designer, just a bunch of people that
run a particular free software implementation and some that contribute
code.  So I suspect any individual buying ".bit" is likely to earn the
scorn of the Namecoin community, and not their trust to "operate" the
TLD, which currently does neither have or need an operator, which is the
key motivation behind the design. (Full disclosure: I'm merely a casual
observer of the Namecoin community, I do not speak for them nor do
I have a ".bit" name or any Namecoin or Bitcoin currency.)

> special about them. 

I expect them to be handed around by end-users and within applications.
I do not expect them to be handed around within UDP packets on port 53
(with the exception of ".bit").

> In that case, you absolutely must expect that
> the root).

I expect that this MAY happen, but if the draft is accepted, one
of our goals is to explicitly authorize DNS operators to prevent
this.  Right now, a well-configured, 100% RFC-compliant DNS resolver
MUST pass a request for ".onion" to the root.  With this draft, we
want to explicitly ALLOW 100% RFC-compliant DNS resolvers to instead
immediately return NXDOMAIN and thus avoid the security and performance
implications of leaking such queries to the root.

>  Because they don't exist in the root zone, they will be

Yes, exactly.  The formulation did end up a bit unclear and should
be fixed.  Our intention was exactly to allow servers to immediately
return NXDOMAIN without going to the root.

Again, thanks for your comments, we'll try to address those in the
next iteration, many of these were really helpful.

Happy hacking!

Christian

---

From: Joe Abley <[email-masked]>
Date: Tue, 31 Dec 2013 17:41:13 -0500

> people to _first_ deploy at large scale and _then_ reserve the name.

You can reserve a name for $10/year, no IETF process required. Less if you reserve under an existing domain name.

The key question for me is, why do any of these uses necessarily require reservation of a TLD label, or something that looks like one?

If (to take an example at random) Tor users could make use of names outside of the DNS that look like DNS names under a .ONION TLD, why could they not just as easily make use of names that end in ONION.EFF.ORG?

The general answer to this question (in the DNS world) is that names will appear in television ads and billboard posters, and hence need to be short and memorable. I'm not sure how convincing that answer is (time will tell, I guess) but it seems less convincing for naming schemes that involve easily-typo'd, long hexadecimal strings as interior labels. These are presumably not intended for direct entry by users. Where is the need for a pithy TLD?

If the answer is "well, it wasn't done that way, and there's a huge deployed base" then I would take the time to consider migration strategies away from schemes that seem to involve top-level DNS labels towards schemes that don't. It's inevitable that these names will leak to the DNS, and those leaks will be easier to mitigate the further the names are from the DNS root.

> implications of leaking such queries to the root.

The IETF is not the resolver police. Resolver operators mitigate weird problems with approaches like this all the time. It's a mistake to imagine that a blessing enshrined in a document published by the IETF will immediately trigger changes in deployed infrastructure, or that deployed infrastructure is being hamstrung by the lack of such a blessing.

Consider, however, the different degrees of chaos that might result from:

(a) instruct all the resolver operators in the world to maintain configuration that special-cases a growing list of DNS names. or

(b) chose your naming scheme (again, think ONION.EFF.ORG) such that the NXDOMAINs, negative caching, sinkholing, whatever can be controlled by someone who cares about Tor (the EFF.ORG administrator) without requiring any special handling elsewhere.

Option (b) is much more friendly to the Internet.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 Dec 2013 18:44:21 -0500

>From what you're saying about the different cases, it sounds like
different metrics are going to be relevant.  For instance, it seems
you could just count for .bit, but presumably the Tor examples could
be worked out from rough estimates of the size of the Tor network.  

> people to _first_ deploy at large scale and _then_ reserve the name.

No, I don't.  What has happened here is, frankly, that the namespace
was squatted on, and you're trying to normalize.  I think that's
valuable and I want to support it.  But what would have been _better_
is to have a discussion early when the names were being built into
protocols.  How to do that is also a problem, but maybe if we can make
it relatively painless in this case it will be more obvious that it
could be less hard in future when it's needed.

> no use of it

I don't mean it that way.  This is "squatting" in the traditional
sense of taking up residency without really having the right to do so.
What's happened, according to your draft, is that these different
names are being used _as though_ they're DNS names, but they're
actually not DNS names.  The point of the draft is to say, "These
names are going to show up in DNS queries.  They shouldn't, but they
will, so to be safe please set these names aside."

Look at it another way.  Suppose that GNS names had a completely
different form.  Say, for example, that GNS had modelled its name
syntax on the old UUCP addresses, but used a different separator.  So,
just say, gnu&bob&alice, to get to Bob's friend Alice.  If that ever
somehow went into the DNS resolution system, it'd fail immediately,
always, from the root.  That wouldn't be great for the root, but at
least we wouldn't have a parallel namespace that looks just like DNS,
but isn't.

> so a better question might be if there should be a process
> to "unreserve" names should they fall into disuse.

How would you know?  If you can't count users of .gnu now (don't even
know what "users" means, indeed), how would you know when it was safe?

> pages are unstable in your experience? ("Worked for me...").

Oh, sorry.  I meant the other "stable": normally, we want the
references in documents (and require the normative references) to be
"stable references" in the sense that the target can't change.  So a
URI isn't enough -- we need a permanent reference to a versioned
document.  (This is the reason RFCs can't be changed once they're
published.  They're an archival series.  If you want to "update" an
RFC, you replace it with a new one.)

> Yes, in the sense of "SHOULD".

Ok.  This is probably the right interpretation of the STD 13
"preferred syntax" (== LDH rule).  What STD 13 says, in effect, is
that you can put anything in there, but things will tend to work
better if you follow LDH.  (Note that RFC 1123 actually relaxed the
rule, because originally labels couldn't start with a number either.)

What is the reason for continuing this tradition in GNS?  (That's
probably out of scope for this document and even this draft, but the
LDH rule has been a PITA and it's one of the things that would be nice
to ditch if we could.)

> Yes.

Wow.  Are you sure you want to buy that much pain?

> No.

Why not?  If the LDH rule is only SHOULD, then what do you do with
octets outside that range?  

> an application to not enforce these constraints.

This advice is worth what you're paying for it :) but I think that's
going to hurt you in the long run.  You're going to get
interoperability problems between people who actually enforce 63/255
and people who don't.  Again, out of scope for this.

> I can live with leaving it out. Any objections to that suggestion?

None here.

> reasons).

Of course not.  I think the collective experience of DNS operators,
however, allows us to suggest that if there is something nonsensical
that is legal under the protocol, someone will start doing it.  In my
day job, in fact, I sometimes meet people relying on those nonsensical
things.  So I thought it might be worth calling out.

>  Also, yes, in theory appending

Ok.  It would be good to note that.

For the whole issue, then, I'd suggest something along these lines:

    Because every name ending in .exit is at least possibly a valid
    hostname in itself, it should be noted that it is theoretically
    possible for those names to be picked up and used in the construction
    of .exit names again.  There is no reason to do this, but it is
    possible.  In constructing such a name, it is possible to exceed
    the total length limit for DNS names.  Such names may fail or
    behave unpredictably when used with DNS resolvers.

> necessarily what one might consider a well-reasoned design

Ah.  I'd leave out the details about the way the design is supposed to
work, then, and perhaps point out that discussion of the details of
operation are beyond the scope of the document.

> I was using names from that list, as opposed to ordinary DNS names

Why?  My employer runs dyndns.org, among other names.  We have way
more than 4,000 names under there.  Why wouldn't that work just as
well in this case?

> activities, but feel free to invest in Namecoin then ;-). 

Snort.  I didn't say it'd make money _for me_!

> concerns were the dominating reason.  But again, we're documenting

Yes.  But this is one of those joints between mere protocol and
policy, because some time ago ICANN became responsible for the policy
of root zone operation.  (The analogy with Apple is a good one -- the
deployment of .local was, frankly, a similar case of
namespace-squatting.)  Nobody cared about this before ICANN adopted an
in-principle indefinite expansion of the root zone, but now we have a
problem.

Getting evidence of the number of actual use (however we work that
out) will go a long way in the argument, though.  On the other hand,
suppose the registration doesn't happen.  The reason that .local (or,
probably more directly comparable in this case, .corp) should possibly
be on the special-use registration list is because we know that there
are services using those names and that there will be security and
user-confusion side effects if those names are also registered in the
DNS name.  Similar arguments for this case wouldn't hurt.

> This is again an interesting split in your logic:

I don't think so -- see the discussion at the beginning.  In particular,

> a significant size

I don't think this is the case.

>    that RFCs are all there is.

I agree that this is a stupid result.  (By way of evidence, I'm one of
the primary offenders behind DNS64, even though I think it's a Bad
Idea in general.)

> True. Are you arguing to remove this sentence?

Yeah, or just add a note to the RFC Editor saying to remove that bit
before publication.  

> that remains even if the draft is published.

I think _that_ would be useful, yes.

> exit supports exiting on port 25 to gnu.org.

Because the [ ] notation signals that what's in there is an IP
address, not a name.

> ".gnu" and ".zkey" to GNS and everything else to DNS --- a "DNS resolver"?

Only partly.  This is similar to the confusion we had about recursive
resolvers and caching name servers.  In the DNSSEC documents, you can
see discussion about "the resovler side of a recursive name server"
and "the name server side of a recursive name server" (or something
similar).  Your example is of a general-purpose resolver system that
does both DNS and GNS.  For the purposes of protocol, then, you have
something like (ASCII art, sorry):

    resolver ---->  DNS ---->  DNS resolver ---> DNS
     |----->  GNS --->  GNS resolver ---> GNS

For the purposes of implementation, these may well all be the same
code.  But for the purposes of the protocol, we need to distinguish
them.

> or configuration of SOCKS support.

Ok, that is probably important to make clearer; probably the
each-name-gets-own-question-answers will do that.

> to see happening anytime soon by any major ISP).

This is an even worse idea.  What you're suggesting there is that
recursive name server operators should add the .bit name to the
answers they give out; but they don't get that answer from the DNS.
Quite apart from what happens in the presence of DNSSEC (I think it's
"fails completely"), I think it is in general bad advice to tell
people to populate their DNS caches with data from outside the DNS.

But they will be:

> this.

You can't "prevent it".  You can just have them swallowed somewhere
else in the DNS system.  They _will_ get passed around on port 53.
Therefore,

> return NXDOMAIN without going to the root.

what I'd do is take a page out of RFC 6303, or follow the text in
question 4 in the RFC 6761 discussion of .test:

   4.  Caching DNS servers SHOULD recognize test names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve test names.  Instead, caching DNS servers SHOULD, by
       default, generate immediate negative responses for all such
       queries. […]

> next iteration, many of these were really helpful.

Glad to be of help.  

Best regards (and happy 2014),

A

-- 
Andrew Sullivan
[email-masked]