Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

[Warren Kumari <[e-mail]>]

[ No hats!]

On Sun, Aug 18, 2019 at 2:29 PM John Levine <[e-mail]> wrote:
>
> >So it would be helpful to know if you think the recommendations are in fact reasonable.
>
> I think they're reasonable but I would more clearly distinguish cases
> by where the protocol switch is, where I think these are the
> interesting ones:
>
> 1. Names handled totally unlike the DNS with nothing like an IP address (.onion)
>
> 2. Names handled through mutant DNS which can returns IP addresses (.local, .localhost, .homenet/.home.arpa)
>
> 3. Names that have other problems such as conflicting prior use (.test, .example, .invalid, also .home, .belkin)
>
> For 1, we can reserve if if there's a compelling argument and evidence
> of clear use.  This leads to a catch 22 where the only way to get the
> evidence is to squat on it, but I don't see any way around it.  I
> particularly do not want to reserve names just because someone claims
> to have a great plan.  I think this probably includes Warren's great
> plan for .alt.

... hey, that's my cue!

.alt was discussed at IETF 105, and it sounded to me like was good
support for progressing it / discussing it again.

A quick recap for those who've managed to swap out state on this...
"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."

For all sorts of reasons (compatibility with existing apps being the
main one!) people building alternate naming systems (like .onion, the
GNUnet naming system, many of the blockchain-based / type systems)
want to use names which follow the DNS convention. This means that
they can and do leak into the DNS - for example, if I send you email
with a link to https://facebookcorewwwi.onion/ and you don't have a
TOR browser / shim you'll end up asking the DNS. This ruins much of
the privacy they should be providing (and also being annoying :-), and
also leads to the possibility of collisions.

As John says, there isn't much that people who want to do this
responsibly *can* do - there isn't a path for them.
Reserving .alt will give people designing and using systems like this
a responsible option -- they choose something under .alt (e.g:
foo.alt).

Below is a FAQ to answer to some of the previously discussed questions.

FAQ:
1: Why not just suggest people choose something + <non-DNS-character>
(like ASCII 168)?
A: We need this to be usable with existing apps. e.g 'telnet
www.example.bar<0xA8>' results sadness. It's also makes the solution
really user-unfriendly.

2: Does this also get added to the"Locally Served DNS Zones"  registry?
A: "Earlier versions of this document requested that .ALT be added to
the  "Locally Served Zones" registry, and that a DNSSEC insecure
delegation (a delegation with no DS record) be created at the root.
Significant discussion on the DNSOP list (and an interim meeting)
generated the consensus that these names are specifically not DNS
names, and that them leaking into the DNS is an error.  This means
that the current (non-delegated) response of NXDOMAIN is correct as
there is no DNS domain .alt, and so the document was updated to remove
these requests.

3: Will there be a registry under .alt.
A: Not one run by ICANN / the IETF, no. There is the expectation that
people using this space will self-organize. A number of people have
also offered to publish an informal list.

4: What is the current status / history?
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/history/

There was a WGLC started 2017-03-16:
https://mailarchive.ietf.org/arch/msg/dnsop/tdp-OH3cYf6B9M0Kj1i7d2n6_KE

This was then extended 2017-04-07:
https://mailarchive.ietf.org/arch/msg/dnsop/zMchuCtfZU4jYFR5AEkAF1RB9wg

I believe that we've addressed all open comments from the WGLC.

It was marked as "Held by WG" (2018-07-17) while we dealt with the
Special-Use Domain Names Problem Statement (which became RFC8244)


It was discussed / presented at:
DNSOP Interim meeting on Special Use Names, RFC6761 (May 12, 2015) -
http://www.owl-stretching-time.com/presentations/IETF_DNSOP_Interim_May_2015.pdf

IETF92 - https://www.ietf.org/proceedings/92/slides/slides-92-dnsop-5.pdf
IETF95,
IETF96 - https://datatracker.ietf.org/doc/slides-96-dnsop-14/ (missing)

The Special Use Names interim:
http://www.owl-stretching-time.com/presentations/ALT_TLD_2017_Interim.pdf

It was also mentioned on the joint IETF DNSOP / ICANN interim to
discuss SUDN PS document, and ICANN was invited to participate in the
LC.

I've just posted a new version (bumped the version / date,
aggressive-nsec is now RFC8198, ) to revive it. I'd appreciate review
and comments; I personally believe that this document solves a real
issue, and I'd like to see it progress...

W


>
> For 2, we seem to agree that future reservations, if any, will go under .arpa.
>
> For 3, we already did .test, .invalid, and .example which seem to have
> solved that particular problem.  I think the question of what might be
> too cruddy to delegate is ICANN's problem.  As you know better than I
> do, ICANN has a big project to characterize "cruddy" and I don't see
> the IETF having anything to contribute there.
>
> R's,
> JOhn
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf