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

[Christian Huitema <[e-mail]>]

On 8/7/2022 9:17 PM, George Michaelson wrote:
> Not trying to say you're wrong,
>
> I just observe that if there is an omnibar, and people type names into
> it, then there is a latent problem of ordering lookup, and deciding,
> in names and more than one namespace. Pretty much all the hard stuff
> stems from there IMO.
>
> Names are hard. I think belief in the value of a unitary namespace as
> a commons probably always transcended the DNS specifically. We're just
> in denial what "it" is that we're fighting to defend.  DNSSEC made
> this perhaps more focally clear: the specific value here is (in my
> opinion) in "which TA do you respect" and how that goes to "which name
> do you believe" which in this case goes to "which namespace do you
> prefer, deciding which names to accept"

The name space is "almost" unitary. People deploy things like domain 
suffix search lists so that users can type "mailserver" and arrive at 
"mailserver.corp.example.com" -- or something else, depending where they 
started for. Which, if you squint really hard, is not all that different 
from the "pet names" scenario.

> The unitary namespace belief, goes pretty rapidly to "how many
> distinct, independently managed TA do you want to respect proving
> names" as a cross product with "when, in which order, and why, and
> what do you do if they collide or disagree"
>
> If GNS is glued into DNS as a sub-arc over a label we understand, the
> possibility of some unity, fusion of purpose exists. If it squats, or
> is pushed aside, then that possibility disappears.
>
> To me, thats the problem. Not that we're finding this is ugly, or we
> like or dislike a reserved label like this, or want to never invoke
> the method we documented to do this thing, or hate ICANN or a hundred
> other things: its the loss of fusion of behaviour, if we don't come to
> some sense of agreement in what names are, respecting locators (and
> addresses)

If users could be trained to type "!example.pet" or "..example.pet" to 
explicitly require resolution of a GNS name, then John's proposal would 
work. I am not sure that this can such training would work. I observe 
that when DNS and NetBIOS were used in parallel, the same hostname was 
typically used in both cases. It would have been good if users could be 
trained to type "mailserver.corp.example.com" instead of "MAILSERVER", 
but such evolution took a very long time.

Now, it may well be that training users to type "example.pet.arpa" or 
"example.test" is just as hard. Design proper user interactions is hard. 
I would much rather let the GNS developers make these decisions rather 
than have the IETF try to engineer user interactions on their behalf. If 
they have concluded that they just need a name suffix, I think we should 
take that at face value.

But then, the GNS interaction design should also be based on reality, 
i.e., a world in which the RFC 6761 process is not available.

-- Christian Huitema