Subject: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

From: [email-masked]
Date: Mon, 21 Jun 2021 10:48:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : The ALT Special Use Top Level Domain
        Authors         : Warren Kumari
                          Andrew Sullivan
	Filename        : draft-ietf-dnsop-alt-tld-13.txt
	Pages           : 11
	Date            : 2021-06-21

Abstract:
   This document reserves a string (ALT) to be used as a TLD label in
   non-DNS contexts.  It also provides advice and guidance to developers
   developing alternative namespaces.

   [Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.  This document is
   being collaborated on in Github at: https://github.com/wkumari/draft-
   wkumari-dnsop-alt-tld.  The most recent version of the document, open
   issues, etc should all be available here.  The authors (gratefully)
   accept pull requests. ]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-13

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 21 Jun 2021 13:56:46 -0400

I think the "Privacy Considerations" section should probably mention QNAME
minimization, which ought to help a little.

I would also be interested in seeing some guidance about interaction
between the relative form (.alt) and good old-fashioned search domains.  It
seems to me that the interaction there is poor... perhaps bad enough to
recommend using the absolute form only.

On Mon, Jun 21, 2021 at 1:49 PM <[email-masked]> wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 24 Jun 2021 14:37:42 -0400

>minimization, which ought to help a little.

I'd also like it to say more clearly up front that .ALT is for names that are
totally outside the DNS protocols, not for names handled locally using DNS protocols.
It's for things like .onion, not like .local.

>recommend using the absolute form only.

I thought we all agreed that search lists are bad when .CS was added to the root.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Thu, 24 Jun 2021 17:30:51 -0400

> It's for things like .onion, not like .local.

Yup, what John said.

The important part is: "This document reserves a string (ALT) to be
used as a TLD label **in non-DNS contexts.**" (emphasis added).

There are a bunch of different name resolution mechanisms - DNS is the
most common, but there are also an increasing number of things like
.onion, various blockchain-based systems (some of which have some cool
privacy features), etc.
For obvious reasons "alternate"[0] resolution systems use the same
format/style of names as the DNS (LDH, case insensitivity, etc) -
people want to be able to enter the identifiers into "normal"
applications and have them just work (e.g things like "foo:bar:baz"
don't work - ssh[1] for example won't pass this to a resolution call).
There are similar issues with defining new schemas, etc; there is a
reason that it's e.g http://www.facebookcorewwwi.onion/ and not
http://www.facebookcorewwwi.¯\_(ツ)_/¯/ or
hQQp://www.facebookcorewwwi.onion/.

Unfortunately, having multiple resolution systems using the same
namespace and syntax does not provide a signal to denote which
resolution mechanism should be used - clearly .com is "in the DNS" and
.onion isn't -- but this doesn't scale, and simply saying "the DNS is
the only resolution system" doesn't either....

I'm guessing that everyone knows all this, but we had lots of *long*
discussions around the various options in ~2014 - 2017, and I figured
that much of the state might have been paged out...
Some other background:
https://www.iab.org/activities/workshops/explicit-internet-naming-systems-ename/
https://www.ietf.org/blog/ename-workshop/

> I thought we all agreed that search lists are bad when .CS was added to the root.

Yup. There should indeed be some more text around search-lists and
search-list processing; much of the purpose of this is to be able to
differentiate the namespaces, and search-lists are a place where they
may bump into each other again.
John's right again -- we *did* all agree that search lists are bad
when .CS was added... and also in RFC 1123 (specifically, section
6.1.4.3 (2)), RFC 1535, and RFC 1536.
Andrew McConachie and I even started writing "DNS Search Lists
Considered Dangerous", before deciding that this was probably tilting
at windmills...

W
[0]: This isn't intended to be pejorative, I'm just trying to separate
these from what we normally assume in this community when we talk
about a name resolution system
[1]: OpenSSH_8.6p1, OpenSSL 1.1.1k  25 Mar 2021

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Joe Abley <[email-masked]>
Date: Thu, 24 Jun 2021 17:41:17 -0400

> It's for things like .onion, not like .local.

Both .onion and .local use protocols other than the DNS, acknowledging of course that the protocol used for names under .local is quite DNS-like.

More generally, if the intention of the .ALT proposal is to anchor namespaces that don't use the DNS protocol then I'm confused. I thought it was intended exactly to anchor namespaces that use the DNS protocol, just in a way that deliberately didn't provide any guarantee of uniqueness. The -13 text says otherwise in the introduction, however, so either my memory is more faulty than I thought or the direction has changed.

Did I miss the conversation where the working group decided to pivot? (Not a rhetorical question! I am very prepared for the answer to be yes :-) If anybody has a handy pointer to the relevant part of the mailing list archive I'd appreciate it.

ObReviewContribution: the authors list includes one A. Sullivan; let it be known that Mr Sullivan no longer works for Oracle.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 24 Jun 2021 19:17:41 -0400

> the only resolution system" doesn't either....

It would have been nice if ToR used onion://drugmart rather than 
http://drugmart.onion, but we lost that fight a long time ago.

I have occasionally wondered whether we could define an agreed set of 
levels for DNS-ish name semantics, e.g.:

* application data stream (onion)

* resolve to a perhaps nonroutable IP address that can connect to 
a data stream (various LAN level proxy hacks)

* resove to an IP address that acts like a real IP address (most DNS 
resolution behind a NAT)

* resolve to a real IP address (DNS resolution without a NAT)

These are just examples, please consdider the overall idea, not the color 
of the bikeshed.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 24 Jun 2021 19:21:38 -0400

> Both .onion and .local use protocols other than the DNS, acknowledging of course that the protocol used for names under .local is quite DNS-like.

My wording wasn't great -- .local resolves to an IP address while .alt 
doesn't.

> Did I miss the conversation where the working group decided to pivot? 
> (Not a rhetorical question! I am very prepared for the answer to be yes 
> :-) If anybody has a handy pointer to the relevant part of the mailing 
> list archive I'd appreciate it.

If you mean draft-arends-private-use-tld, that was tilting at a different 
windmill.

Regards,

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jun 2021 10:22:24 -0400

On 24 Jun 2021, at 19:21, John R Levine <[email-masked]> wrote:

> My wording wasn't great -- .local resolves to an IP address while .alt doesn't.

I'm not sure that helps. Some (but, sure, perhaps not all) non-DNS resolution protocols can certainly be used to identify IP addresses. Not all queries under .local are for addresses, either. PTR, SRV and TXT are common, for example.

> If you mean draft-arends-private-use-tld, that was tilting at a different windmill.

I'm quite familiar with draft-ietf-dnsop-private-use-tld; I'm a co-author.

draft-ietf-dnsop-alt-tld was adopted by the working group as a way to anchor a set of possible namespaces that had no requirements to be globally unique, or had no "meaning on the global context" or were not "delegated in the DNS".

   In order to avoid the above issues, we reserve the ALT label.  Unless
   the name desired is globally unique, has meaning on the global
   context and is delegated in the DNS, it should be considered an
   alternate namespace, and follow the ALT label scheme outlined below.
   The ALT label MAY be used in any domain name as a pseudo-TLD to
   signify that this is an alternate (non-DNS) namespace.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/00/ section 3

The document doesn't call it out as an explicit example, but I thought it was intended that the set of candidate namespaces included private-use (non-globally-unique) namespaces that use the DNS, as well as namespaces that use other resolution protocols.

alt-tld-13 makes it much more explicit that .ALT is not intended for namespaces that use the DNS. So this is a change from the original document.

It looks like this change happened between -07 and -08 (e.g. "Made it clear that this is only for non-DNS" in Appendix A) but I don't recall any conversation about reducing the scope on the mailing list. That's what I was asking about.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 Jun 2021 14:02:54 -0400

> It looks like this change happened between -07 and -08 (e.g. "Made it clear that this is only for non-DNS" in Appendix A) but I don't recall any conversation about reducing the scope on the mailing…

This required some archeology...

The WGLC for the document was started on March 12, 2017:
https://mailarchive.ietf.org/arch/msg/dnsop/tdp-OH3cYf6B9M0Kj1i7d2n6_KE
and said  (emphasis mine):
"Per the discussion in our interim meeting a couple of weeks ago, the
editors have revised this document and the chairs are opening a
Working Group Last Call.

Please let us know, on the list, whether you support advancing
draft-dnsop-alt-tld-08 to the IESG for publication.

The document has been stable for awhile except for one significant
change in the new version. *** As discussed in the interim, it now
clarifies that “.alt” is intended for use with domain names intended
to be resolved outside of the DNS protocol.***

With IETF 98 upon us, we’re giving this a little extra time (3 weeks).

Starts: 13 March 2017
Ends:  3 April 2017
"

Looking back through slides  and email and such:
We had a DNSOP Interim Meeting on Feb 16 2017
(https://datatracker.ietf.org/meeting/interim-2017-dnsop-01/session/dnsop
and [0]).  I've posted a copy of the slides here:
http://www.owl-stretching-time.com/presentations/ALT_TLD_2017_Interim.pdf

Slide 8 says: "Reserves a string (ALT) to be used as a TLD label in
non-DNS contexts, or for names that have no meaning in a global
context.
  • Text in red seems incorrect. This was intended to be for names
outside the DNS protocol - like .onion" (with the 'or for names that
have no meaning in a global context.' in red).

The meeting summary is posted here:
https://mailarchive.ietf.org/arch/msg/dnsop/23_KtO4BLQP9vZMFwA75FKEKYV8

So, the  change was in response to feedback from the Feb 16th 2017
joint DNSOP interim meeting. I can look further to try and find the
emails, but hopefully this is clear enough?

W
[0]: https://mailarchive.ietf.org/arch/msg/dnsop/O7jF1F6bgR6VAjlMzm-9TctCSXs

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Jun 2021 22:12:43 +0100

John Levine <[email-masked]> wrote:
>
> I'd also like it to say more clearly up front that .ALT is for names
> that are totally outside the DNS protocols, not for names handled
> locally using DNS protocols. It's for things like .onion, not like
> .local.

.local is a tricky example because it is used for mDNS (as discussed in
the other replies) but it also has a history of being used as an ad-hoc
RFC 1918-style domain. Microsoft recommended .local for use in Active
Directory domain names for their Small Business Server, back in the days
when you couldn't reasonably expect their target customers to register a
real domain name. There are ugly hacks in mDNS implementations such as
Avahi that try to work out what a network connection uses .local for.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Lundy, Fastnet, Irish Sea, Shannon: North or northwest, becoming
northeast later, 4 to 6. Slight or moderate, becoming smooth or slight
in Irish Sea. Showers. Good, occasionally poor.