Excerpts from Brian Dickson's message of 2022-08-03 18:09:32 -0700: > 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. >
It is intended to resolve RFC8499 "domain names".
It could be used as an alternative to DNS to resolve DNS domain names.
If you want, we can make that clearer in the draft.
Actually, I have been pondering over that the last few days.
> So, why even use DNS-compatible label strings? That is an obviously
> conflict-causing choice, which is entirely avoidable.
>
Any (most?) domain names are DNS-compatible label strings.
How come that is no problem elsewhere?
> 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.
Please. The obvious choice is RFC6761.
You are hand-wavingly proposing to cripple the usability of the names
used in alternative name systems below which would also require us to define
in the draft what we mean by "name" instead of being able to point to
RFC8499.
How is that better than an established process that was applied very
recently. Twice.
>
> (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.)
>
The reason is usability and the often in this discussion invoked "user
expectation". A "." is just a lot easier to type, everything you propose
not only looks awkward but is also difficult to type.
Not to mention that a lot of applications that use domain names
expect domain names.
> 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.
Should that[1] be(come) consensus/the outcome of the IESG review I think we need
to discuss internally if we'd rather take the conflict as that would
significantly change the purpose of GNS.
Such an outcome would likely also stop this discussion permanently I
think. I guess you should get rid of RFC 6761 as well then at some point.
Please note that it is not us requesting a sub-namespace or TLD with our
draft.
Our current version of the draft proposes a technical protocol to resolve
domain names as defined in RFC8499.
Whether a deployment uses a sub-namespace or not is not really relevant.
In my opinion (but that is something that could be discussed), it is also a lot
cleaner to define the protocol in such a
way and not assigning a namespace along with it.
But, we would be happy to accomodate concerns regarding user safety
and namespace consistency *within reason*.
Note that .alt would not make it clear for an implementation if a given
name can or should be resolved in GNS as currently there is no registry for the
subdomains proposed.
So, while being adamant that this is a problem in DNS, it seems odd that
it would not immediate also be a concern for GNS.
In practice, I concede, this may not be a problem.
But in practice, I think the "DNS namespace in danger" discussion is smilarly
not
a problem.
Anyway, going to ICANN in order to collect a TLD is not a reasonable process for
publishing our draft.
We would not even know what the process would be (after the RFC? before
writing it? While writing it? What if ICANN denies a request? All the
work is moot?)
Similarly using "www.example.com!gns" et al. is not a reasonable change.
As that impairs usability and is incompatible with applications that
expect domain names.
BR
[1] "that" being that alternative name systems are not welcome and are
required to bake into their technical specifications "poison pills" that
make them unattractive to use.
>
> 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
> >
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
