> On 19. Aug 2022, at 17:06, Schanzenbach, Martin <mschanzenb...@posteo.de> > wrote: > > Signed PGP part > Hi Brian, > > thank you for the feedback. > >> On 19. Aug 2022, at 16:46, Brian Dickson <brian.peter.dick...@gmail.com> >> wrote: >> >> 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. > > > A GNS implementation ships with a default configuration: The "Start Zone" > (https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#name-start-zones). > IF the user configured a suffix in the start zone that also exists in DNS, > then that is the users problem (see also, /etc/hosts). > So, the GNS nsswitch plugins functions similarly to the "files" plugin. It > also times out, at which point it returns notfound, however. > See also https://docs.gnunet.org/installing.html#nss-plugin-optional
Oh and I need to add here: The nsswitch plugin is a "GNS-aware" application. Which is why if there is NO "start zone" configuration that matches the suffix of the name, it DOES return "NXDOMAIN". > > IF the implementation ships a default configuration that has mappings that > also exist in DNS/others , then this may be a problem. > I would request a suggestion on different wording then (however, I think with > .alt this would be fixed anyway). > >> >> 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. > > We want the DNS vs GNS vs Other handling to be done by the application (the > OS resolver is an application from the perspective of the GNS > implementation). This IMO should not be part of our spec beyond some > non-normative guidance. > For example, we specifically consider nsswitch to be a crutch for > applications that cannot (yet) distinguish between name systems as part of > *possible* migration paths: > https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#appendix-A.4 > >> >> 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. > > Yes, but we have to distinguish between "GNS-aware" and "GNS-unaware" > applications. For example, applications such as browsers are not really > "nsswitch files plugin"-aware. > The browser will try the IP and TLS probably will not work if the server IPs > in DNS and hosts do not match. > > So, in order to applications to proactively handle GNS names, they need to > "know" what it is. But if they to, they can easily figure out the "start > zone" configuration of the user and compare it against the given name > according to > https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#name-start-zones > > However, I think you found a blind spot and I need to recheck the draft. I > remember that we intentionally left handling of the name by applications out > of the draft. > The primary reason for this initially was internationalisation and UTF-8, as > far as I remember. > Anyway, I think we may address this issue anyway should we incorporate > references to a possible .alt draft in the next revisions or so. > > BR > Martin > >> >> 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 > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
