Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Martin Schanzenbach <[e-mail]>]

Excerpts from Stephane Bortzmeyer's message of 2022-08-01 17:29:38 +0200:
> On Mon, Aug 01, 2022 at 02:31:48PM +0200,
>  Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote 
>  a message of 89 lines which said:
> 
> > Whether that means using TLD labels that begin with _ or whether
> > that means suffixing them with ".ALT", I leave to you experts to
> > sort.  I do agree with Martin that it would be helpful to have some
> > registration of names so that conflicts between name spaces can be
> > avoided.  This would also encourage formal documentation of those
> > projects.
> 
> I agree and I think publication of these drafts would be a good idea
> (may be with status Experimental since, as Joe Abley said, there is
> clearly no IETF consensus). Note that I am skeptical about their use:
> most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will
> not read the RFC and, if they do, won't follow it. But at least we
> will be able to say that we tried and we have a solution (and not a
> ridiculous one such as "pay ICANN 185 000 US $").
> 

tl;dr:
I am a bit ambivalent towards the ".alt" approach.
For alternative name systems that are specified with status
"Informational"  the use of ".alt" seems highly unattractive as there is
absolutely no benefit in using it but at the same time there are
(obvious) disadvantages especially compared to other name systems which
do not (try to) publish in the RFC series.

---

Reasons:

With our draft you would have one system which references
this "solution", as opposed to specifying solution looking for a problem.
That being said, since our current draft is Informational, I do not
think the existence of an ".alt"-RFC would significantly alter our protocol
implementation or deployment for now.

There is just no benefit for a name system in using it. The benefit lies
solely with DNS and the existing infrastructure.
After all, a new "Standards Track" name system that could potentially be used as
a DNS-drop-in would not be designed or specified using ".alt", right?
That would be like requiring DoH servers to only process names under ".doh.alt".
But they do not and never have, because even though the technical
resolution process is different, it is still the same namespace.
So what if (yes I know very theoretical) ICANN and TLD-registrars
publish their zones in GNS? Is it still www.example.com.gns.alt or would
it be the _same_ namespace managed by the _same_ authorities resolved
through GNS and become www.example.com?
If the latter is the case, what is the purpose of ".gns.alt"?

Further, migration becomes more difficult with ".alt".
For example, is it possible to get X.509 certificates issued for those domains?
Not to mention that users have to deal with (significantly!) longer names as you need a
second-level indicator on which name system is asked for.
e.g.:
www.example.com.gns.alt vs
www.example.com

So unless IESG actually finds a conflict and we have to put it in the
specification as a requirement, I don't see why we (GNUnet) should use it
at all in practice for our implementation.
Since our draft is Informational, I also do not see any urgency.
But, I think it makes sense to have provisions in the draft that
discuss this issue and show how *in a deployment* this possible namespace
ambiguity may be avoided using ".alt" independently of how the currently
documented implementation operates.
Maybe we would add a ".alt"-RFC-compliance configuration option that
limits resolution to ".gns.alt" etc. (there would be no reason for any
user to set it, realistically)

Really, though, all this was just a matter of following RFC6761 IMO...

BR
Martin