[DNSOP] On ALT-TLD, GNS, and namespaces...

[Warren Kumari <[e-mail]>]

Warren’s meta-comment -[ Please read this ]-
-------------------------------------------------------------------------
I believe that there is still an open-mineshaft problem around Internet
domain namespaces - what exactly they are, what is the DNS namespace, how
one determines the boundaries of the space, how one switches namespaces,
etc. We've take a few cracks at this nut — a partial list includes the IAB
ENAME workshop, SUDN problem statement, drafts from Suzanne and Ed, the
pain around .onion  (a fuller list is in [0]) -- but we haven't actually
solved it.

TL;DR: Domain names are older than the DNS protocol and have always been
used in multiple contexts. DNS naming conventions and protocol are by far
the most widely used naming system in the public Internet, and have
provided an extremely useful naming space default for Internet hosts and
users. Both this “default” status and widespread use have made DNS the only
Internet naming system usually considered in either operational or policy
terms. ICANN exists to make decisions about the contents and administration
of the DNS root zone, while the IETF has continued to adapt and expand DNS
naming conventions and protocol to accommodate new use cases (DNSSEC, IDNA,
encrypted transport, etc.). This arrangement has worked reasonably well–
but not all domain names are DNS names, and not all are administered within
the public default DNS root domain. As various naming conventions and
protocols have become more of a presence on the Internet, the risk of name
collisions, resolution failures due to wrongly routed queries, and so on
increase….and whatever the usefulness of any specific naming convention or
protocol, confusion among them undermines usefulness for all of them.

Avoiding such complications in an open Internet is a hard problem, and
there are good reasons why it’s hard to agree on whether there’s one
problem, several problems, strictly administrative problems, etc.  - this
area is very much cross-discipline, touching on technology, policy,
politics and philosophy, and requires significant amounts of long-term
"deep" thought. We've repeatedly gotten sidetracked and / or discouraged /
kicked the can down the road on this topic.  Many of the parts of this
problem space are really quite subtle, and there are many "obvious" or
knee-jerk type answers which have already been discussed - there is lots of
history here (some links at the end of this email), and you should probably
read some of it before proposing a solution — for a good corollary from the
mail world, see 'FUSSP' (e.g:
https://slashdot.org/comments.pl?sid=98024&cid=8373855 ). There are a
number of foundational documents around this topic which are well worth
reading if you want to have an educated opinion on this topic - these is a
partial list at the end of the email, but "RFC8244 - Special-Use Domain
Names Problem Statement" and "ICANN OCTO-034 Challenges with Alternative
Name Systems" (
https://www.icann.org/en/system/files/files/octo-034-27apr22-en.pdf) are
good starts.

A few weeks ago I started trying to resurrect the work — I have a slide
deck that I was planning on presenting at IETF114 to re-expose the issues
and get people excited about working on it again. I was proposing forming a
design-team to work on it, but the set of people that I shared the idea
with initially convinced me that I needed to better define the structure,
scope and venue before launching this.
So, I withdrew my request for presentation time, but I *am* still planning
on organizing a group to try and get some better focused discussions on
this entire topic.  So, watch this space!
----------------------------------

And, now, jumping into some of the actual discussion — I'm starting off
with a FAQ style set of answers to some questions I'd seen in the recent
threads. These are mostly unordered, but getting them out of the way early
seemed useful. Note that, as with basically all of this email, these are my
views only...


FAQ - .alt / .internal / similar
-------------------------------------------
1:
Q: What was/is the intended use for .alt?
A: From the Abstract (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld): "This
document reserves a string (ALT) to be used as a TLD label in non-DNS
contexts." - the important term here is 'non-DNS' contexts. It is intended
to clearly delineate that names "under" .alt are *not* DNS names, and
should not be sent to the DNS for resolution. This means that DNS stub
resolvers and recursive resolvers can drop any query which make it to them.

2:
Q: Ok. So, what was/is  .internal / SSAC113?!
A: From SSAC113 (https://www.icann.org/en/system/files/files/sac-113-en.pdf),
Sec 1.1: "In this document, the SSAC limits its discussion to private-use
TLDs intended for use with the DNS protocol and for private use only. Many
private-use TLDs, such as .onion and .gnu, do not use the DNS protocol or
DNS infrastructure. The reservation and usage for such TLDs would require
special handling and is not discussed in this document; there have been
efforts in the
IETF to address them." — the important terms here are "intended for use
with the DNS protocol". A simple analogy is RFC1918 space for names.

3:
Q: Wait, I'm confused. What's the difference?
A: .alt is explicitly a switch to denote that a name (e.g foo.alt) is not a
DNS name - DNS resolvers can, and should discard queries for it. .
.internal (or whatever string is chosen) is explicitly a private-use *DNS*
space. Stubs should treat it just like any other name, and recursive
resolvers should process it like a "normal" DNS query - note that in
enterprises it is expected that recursive resolvers will forward or be
authoritative for things names like accounting.internal or
vm34.iad.internal or similar. The handling is very different - it is an
error for a lookup for foo.alt to end up in the DNS, but expected for
foo.internal.

4:
Q: Why is .alt being discussed in the IETF and .internal was progressed in
ICANN?
A: Actually, both started in the IETF - .alt back in 2014, and .internal
(as draft-wkumari-dnsop-internal) in 2017. .internal was presented at
IETF100 -
https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-draft-wkumari-dnsop-internal-00
, and, as I interpreted the feedback[1] was that this was DNS naming, and
better handled at ICANN, and so I took it to ICANN. I believe that this was
correct — the name is a *DNS* name.



FAQ - Namespaces (please also see the meta-comment at the top of this email)
---------------------------
1:
Q: Why don't people who want to invent some sort of new naming system use
some unprintable / non-LDH characters to delineate their space? Like an
emoji, or ! or \ or \00 or ...
A: Even though I have a badge which claims otherwise, there are no protocol
police. Anyone can just start using whatever string they like at the end of
a name, and there is nothing that you, I, or your favorite deity can do to
stop them (we've seen this happen a bunch already in several blockchain
based systems).

This means that whatever solution is proposed for switching namespaces
needs to be actually usable - if it isn't, alternative name space
resolution developers will simply choose a string that they like, or just
create an overlay that pre-empts the entire namespace. It also needs to
work with existing applications, like 'ssh' and 'ping' and browsers and
anywhere else you can realistically expect a name to show up (e.g '!' makes
unix shells sad, typing an emoji is a non-starter (and most apps will
choke), etc.) This means that the selector either needs to be a valid DNS
name (e.g .alt) or a string which most applications will pass -
interestingly, Wes Hardaker did some testing recently and underscore labels
work in many places, so e.g foo._boop works.
NOTE: If you find your fingers itching to reply to this, go re-read the
meta-comment at the top of this mail - I'm planning on organizing a group
to discuss these issues.

2:
Q: Many of the newly proposed name resolution systems use some sort of cool
and sexy crypto stuff underneath them - why don't they just use something
like 0x325562c769da3f80d0e63bb56514bc2e2723c9b5 as a suffix? It will be
randomly unique, and so there is no risk of collisions?
A: Go see #1 — you cannot expect users to enter 'ssh
my-computer.0x325562c769da3f80d0e63bb56514bc2e2723c9b5' or
'www.ILikeCheese.325562c769da3f80d0e63bb56514bc2e2723c9b5'. A primary
reason that we use names to refer to computers and services instead of IP
addresses is that we want them to be convenient.  Also see the meta-comment
— if you are interested in this sort of thing, please come participate in
the namespace group whenever it is created.

3:
Q: The DNS got here first. It is the best naming system and the only one
that should exist. Anyone who tries to create an alternative name
resolution system is bad and should feel bad.
A: That's not a question, it is a rant. Even if it were true, that doesn't
stop people from creating alternative resolution systems and these (see #1,
#2) may collide with your perfectly pure and wonderful DNS. Also, eeeeewww…
Please see the meta-comment, and please don't come participate in the
namespace group. :-P



Finally, getting to the whole GNS topic… and once again, some history /
context is important here...

Enter the Internet-Draft draft-schanzen-gns, submitted to the ISE (the “I”
stands for “Independent.”) for publication as an Informational RFC. It
documents “the GNU Name System (GNS) technical specification.  GNS is a
decentralized and censorship-resistant domain name resolution protocol that
provides a privacy-enhancing alternative to the Domain Name System (DNS)
protocols.”


The proponents of this mechanism *did* try to discuss their idea in both
the IETF and in ICANN, and didn't get a particularly friendly response.
They even tried to get an RFC6761 reservation for this - see:
draft-grothoff-iesg-special-use-p2p-names
In addition to .GNU, this document attempted to reserve a number of names,
including ZKEY, EXIT, BIT, …. and .ONION.

I'm sure many people here remember (and still bear the scars from) the
.onion discussions, but the summary is that it was approved, and an IESG
statement was published (https://www.ietf.org/blog/onion/) which included:
"However, subsequent to this action, the IESG believes RFC 6761 needs
action, and substantial community input. It needs to be open for review and
modification because the current process is unscalable." and "The DNSOP
working group is chartered to address this RFC 6761 review."
The message was that we were putting RFC6761 reservations on hold while we
considered and investigated the issues with the RFC6761 process. We did a
bunch of work here - RFC8244 - "Special-Use Domain Names Problem
Statement", Ed Lewis'
https://datatracker.ietf.org/doc/html/draft-lewis-domain-names,
Suzanne Woolf's “Some Considerations on the Use of Domain Names Outside of
the Global Public Domain Name System” -
https://www.ietf.org/archive/id/draft-stw-whatsinaname-02.txt and
​​"Guidelines for Use of the Special Use Names Registry” -
https://www.ietf.org/archive/id/draft-stw-6761ext-01.txt being just a few
of the examples, but we never actually *fixed* RFC6761. Please actually
read RFC8244 for a list of issues (including Section 3, bullet 1, 2, 3, 4,
9, Section 4). Also note that there have been some discussions between the
IETF and ICANN on improving the coordination and relationship.


This brings us to where we are now - the proponents have documented the
technical mechanisms used in the "The GNU Name System" (I personally think
that it has some incredibly clever mechanisms and some very cool features,
but that is neither here nor there).

The GNS proponents have tried repeatedly to "do the right thing" - they are
trying to document how their name resolution system works, they have tried
(hard) to participate and engage, they have tried to request a reserved
string. They tried to bring it to the IETF and ICANN, and didn't make any
substantive progress.
They have finally brought  it to the ISE, who (as per usual) has asked for
a Conflict Review (see RFC5742 - "IESG Procedures for Handling of
Independent and IRTF Stream Submissions"), and it is also being discussed
here, in DNSOP.


I'm wearing multiple hats here, including:
1: Operations AD / member of the IESG, tasked with performing the conflict
review.
The list of conflict review responses to select from is quite limited (see
RFC5742).
Without a clear way (such as a suffix) to clearly differentiate these names
from "real" DNS names, I think that is "could potentially disrupt the IETF
work done in WG DNSOP (and others)" or "this document extends an IETF
protocol in a way that requires IETF review" are the closest.

2: Long time participant in the namespaces discussions.
This document stumbled into a known issue — there is no clear way to create
namespaces which do not conflict with the DNS while still being useable and
attractive. While I happen to love the DNS, I'm not arrogant enough to
believe that it is the only namespace or Internet name resolution system
that can or should exist. "We got here first" or "we are the incumbent, go
away" is not (to me) tenable.

3: Someone concerned about name and namespace collisions.
See the earlier mention of the lack of protocol police. Even if we wanted
to, we cannot stop someone (I'm not saying GNS in particular) from using
e.g .ietf as a string in some naming system that they have just created[2].
This means that, unless we are willing to provide a mechanism for other
entities (like the GNS) who are creating other name resolution systems to
co-exist, we will eventually end up in a situation where the meaning and
intended resolution system of a name is unclear. Regardless of the merits
of any specific domain namespace and protocol, confusion among them
undermines all of them. I don't know about you, but I really don't want to
end up in a situation where I send my auntie an email with a link to '
www.cutecats.foo', and discover that because I'm using resolution system X
I see fluffy ginger kittens playing with a ball of yarn, but that she,
using resolution system Y, instead gets older calico cats sitting in a boot.



Ok, enough pontificating — let's try wrap this up.

1: If the ISE wants to progress the GNS draft, I think that there should be
a simple mechanism to determine that a name should be resolved using the
GNS - for example, a reserved string to signal that this name is not a DNS
name and should not be resolved using the DNS.

2: I believe that there needs to be a mechanism to switch namespaces.
I'm biased, but I think that something like .alt (or the use of underscores
before the right-most-label) is a good option (but I'll also note that I'm
biased). Again, not all new resolution systems would use it, but we've seen
some evidence that at least some would. This document could, for example,
use .gns.alt to delineate their names.

3: Most importantly, I think that we need to address the core namespace
issues that this document has (once again) surfaced. It is clear that
people want to use names which are not resolved using solutions other than
the DNS. You might think that they are wrong, but they exist, and we will
need to find a way to co-exist peacefully with them.

So, please see the meta-comment again — I want to reopen the discussions
around "all of the namespace issues" - this is clearly a massive scope, and
potentially includes lots of politics, economics, technical, and similar–
but the IETF can’t directly address many of those factors, so we’ll try to
determine what’s the IETF’s part of the job instead, and propose a way to
get it done. It will also require people being willing to put aside their
differences and people from many communities all working together with good
intentions.

I really really don’t want us to try and reopen the full set of discussions
here and now though – there is a large amount of foundation material that
people should read before having an opinion, and the IETF doesn’t own all
aspects of naming things (nor even just DNS things).

Ronald Reagan once said: “The nine most terrifying words in the English
language are: I'm from the Government, and I'm here to help.”   If DNSOP
discusses this topic without including all of the other stakeholders, even
if whatever we discuss is absolutely perfect, it will likely be viewed with
suspicion that we are trying to exert control, or that we technical people
don’t understand all of the politics and policy implications, or that we
missed important aspects, or…

Let’s not end up creating a new quote of “The ten most terrifying words in
the English language are: I'm from the IETF, and I fixed it for you...”

W



[0]: A small selection of prior work:
ENAME:
Announcement:
https://www.iab.org/activities/workshops/explicit-internet-naming-systems-ename/
Summary: https://www.ietf.org/blog/ename-workshop/

SAC090 SSAC Advisory on the Stability of the Domain Namespace

Ted - “Considerations for establishing resolution contexts for Internet
Names”
https://datatracker.ietf.org/doc/html/draft-hardie-resolution-contexts-01.html
Ed Lewis - “Domain Names”
https://datatracker.ietf.org/doc/html/draft-lewis-domain-names
Suzanne Woolf - “Some Considerations on the Use of Domain Names Outside of
the Global Public Domain Name System” -
https://www.ietf.org/archive/id/draft-stw-whatsinaname-02.txt
Suzanne Woolf - “​​Guidelines for Use of the Special Use Names Registry” -
https://www.ietf.org/archive/id/draft-stw-6761ext-01.txt

Presentations:
ICANN
EnCirca - Blockchain, IoT and DNS (ICANN64 Tech Day, Kobe, Japan) -
https://ccnso.icann.org/sites/default/files/field-attached/presentation-blockchain-iot-dns-11mar19-en.pdf

Namecoin: Decentralized DNS-Like Identifiers (ICANN58 TEG) (
https://www.namecoin.org/files/videos/icann-58/Namecoin-ICANN58-TEG-Final.pdf

Linking DNS with blockchain-based ENS records (ccNSO / Tech day) -
https://ccnso.icann.org/sites/default/files/field-attached/presentation-dns-blockchain-ens-24jun19-en.pdf
)

IETF
GNU Name System: 2019 Edition (Grothoff, DINRG - IETF104, Prague) - -
https://datatracker.ietf.org/meeting/104/materials/slides-104-dinrg-gnu-name-system-00
Video introduction at correct time - https://youtu.be/OMHOyoJ5-_4?t=2715

GNU Name System (Sec Dispatch) -
https://www.ietf.org/proceedings/108/slides/slides-108-secdispatch-the-gnu-name-system-00
)
Special Use Domain Names of P2P Systems (IETF93) -
https://www.ietf.org/proceedings/93/slides/slides-93-dnsop-5.pdf




[1]:
https://www.youtube.com/watch?v=DjbBQDMGf9s&list=PLC86T-6ZTP5g_hEODKiZDeZTpr2Vxd2B3&t=7924s
- Joe Abley / Andrew Sullivan.
[2]: Actually, for giggles (and because I'm desperately procrastinating  at
this point in this email), I  just printed out some labels on my label
printer and put them on my socks, saying 'left.ietf' and 'right.ietf' — and
there is nothing you can do to stop me…