Re: [DNSOP] draft-schanzen-gns and namespace mechanisms

[Brian Dickson <[e-mail]>]

One tidbit that might have been overlooked, is that draft-schanzen-gns (and
the various documents it references, including stuff in github) has a
technical problem.

The TL;DR: is that nsswitch (and similar systems) depend on individual
resolution mechanisms (whatever those may be) returning NXDOMAIN (or the
equivalent) in order to fall through to the next mechanism.
GNS as currently specified will NEVER return NXDOMAIN. The draft says so
(about never returning NXDOMAIN) and explains why. The why doesn't matter,
the what matters.

What this means is, if nsswitch.conf has a line that looks like:
hosts: gns dns files
then the lookups will NEVER fall through to DNS or /etc/hosts. Changing the
order around to put "gns" at the end of the list will work, but would
result in DNS queries for GNS names always being done. This appears to not
do what the draft says it wants to do (i.e. allowing users to have both GNS
and DNS names in use, including allowing GNS to be preferred if a name
collision occurs.)

Here's the longer version:
If GNS never returns NXDOMAIN, then the only way GNS can interoperate with
the name resolution selectors such as nsswitch.conf is to use a namespace
identifier of some kind, and return NXDOMAIN for any names that are not
actual GNS names. (The identifier could be anything -- a suffix, a prefix,
a single character, etc.) This would allow GNS to be a first-class member
of the available resolution mechanisms, rather than being forced to always
be the last mechanism in a list.

Using some (any) mechanism that allows GNS names to be identifiable in such
a way as to either allow GNS to internally distinguish GNS from DNS (and
return NXDOMAIN for DNS names if the query sent to GNS is a DNS name), or
for GNS to handle both GNS and DNS names on a similar basis (do a GNS
resolve on GNS names, or do a DNS resolve on DNS names and return the
result from the DNS call).
Having DNS vs GNS ordering handled by the os-specific mechanism (such as
nsswitch.conf) might be better for linux/unix systems (and servers and
desktops generally), while mobile OS set-ups might use their own mechanisms.

The GNS specification might also want to change its design so that
applications make those decisions on resolution directly, and call
whichever mechanism is appropriate, ie. call either GNS or DNS for
resolution on the basis of the presence/absence of the GNS identifier.
Additionally, the applications (e.g. web browsers) might handle the
input/UI parts to default to either DNS or GNS, and "hide" the GNS
identifier (similar to how the "www" prefix and "https:" service identifier
are "hidden", but available for modification by users in the browser bar),
allowing advanced users to do "the other thing", as appropriate, or
whatever the GNS folks thing makes sense.

E.g. in the browser UI for the URI, what might appear to the user as
"foo.bar" might in fact be "https://www.foo.bar" (current DNS-as-default
browser), or could alternatively be "https://www.foo.bar.gns.alt" (modified
GNS-as-default browser). A user entering "foo.bar" would have that
transformation applied by default, but also be editable if the user desires.

Brian
P.S. To be clear, this is an observation on a deficiency, and suggested
possible fix, but it is not specifically advocating for the correction to
be done.