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 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
