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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
