Top-reply (not apologizing for doing so, either):
If I read the actual draft correctly, it is _not_ intended to be a DNS
drop-in replacement.
Instead, it is meant to be an _alternative_ to DNS.
So, why even use DNS-compatible label strings? That is an obviously
conflict-causing choice, which is entirely avoidable.
Most of the references in this thread to IETF documents or ICANN documents,
are within the context of DNS-compatible naming schemes, that themselves
lead to such conflicts.
The obvious choice, to me, would be for GNS to use a DNS-incompatible
suffix, that is short and memorable in some way.
(That rules out .alt and something.arpa obviously, and probably anything
that starts with underscore or even contains the asterisk character).
So, pretty much pick any other UTF-8 string that is not a potential DNS
label, and is easy to type, short, and unambiguously "NOT DNS".
Choice is left as an exercise to those wanting to paint the bike shed.
The mnemonic of "!" would be clear, meaning "not", or possibly "~",
which is a different kind of "not", or even "^" as another "not".
Other non-shift key candidates ",/=;" or any of "[]\`'" (but less favorable
due to interaction with the unix shell).
Similar one-character shift-key options have various
pros/cons: @#$%&():"{}|<>?"
Basically, pick any of the above, but not any of ".+@-_*", and you are good
to go.
If it makes a DNS resolver complain, it is a good choice.
(Even "**" would be okay, as it is not a legal DNS label.)
At which point, no conflict exists, ISE and DNSOP are all happy, your draft
can be published (with the proviso that this suffix MUST be used always)
and we can stop having this discussion, permanently.
Brian
On Mon, Aug 1, 2022 at 10:11 AM Martin Schanzenbach <mschanzenb...@posteo.de>
wrote:
> 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) <rfc-...@rfc-editor.org>
> 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
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
