Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
Hiya, On 20/08/2022 01:55, Warren Kumari wrote: On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell wrote: Hiya, On 19/08/2022 20:43, Warren Kumari wrote: So, it is perfectly acceptable (in my view) for it to have: Reference Name - a-cool-document foo.alt another-document foo.alt yet-another-doc bar.alt I agree that such duplicate names are acceptable in this registry. I scanned the draft quickly and think it's good. (I'll try do a closer read in a few days.) Only thing with which I'd argue for now is that I think RFC required is a much simpler rule for the registry. My concern with this is that we may end up with lots of Internet Drafts which either need to be put in some WG or be AD sponsored, and have to go through IETF LC, and IESG Eval, and use RFC Editor resources and similar. For an informational only thing that seems like a lot of overhead. I'm also not very sure that IETF participants would really want to review yet another block-chain based name resolution system every N weeks… I agree wrt IETF review. My possibly wrong assumption was that most drafts looking for names in this registry might arrive via the ISE or IRTF, with few desiring all the fun of IETF processes. I guess I'd generally be ok with there being non-trivial hoops that need to be jumped-through for this registry, but yes, I know that increases the chances of squatting-like behaviour. I also recognise that reasonable people might make different predictions about this small bit of the future. Any other option will require some designated experts with some guidance for those DEs, and I'd expect it to be hard for us to agree what guidance to include in the draft or not, and I'd expect it to be hard to find DEs for this registry. Yup, that's a valid concern - IANA's site speaketh thusly: "If you choose Expert Review or Specification Required as the registration procedure for your new registry, it can be helpful to provide guidance to the “expert.” The idea is to provide the expert with guidance on naming, allocation and other issues related to the protocol registry. Sometimes Internet-Draft authors include the guidance directly in the draft. Other times, a Working Group will decide to collect guidance for a group of protocols together (for instance, see the PWE3 working group in RFC 4446)." — https://www.iana.org/help/protocol-registration I'd think that the guidance to the experts would be: 1: Is there a specification somewhere? RFC8126 (Spec Required) says that a specification should be a "document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value." Right. It's the "long after" and stability (for some random project) and sufficient detail (for academic pubs) I wonder about for the specification-required path. (I've no worries about the IESG approval path.) I figure we might be better off seeing how an RFC-required setup pans out for a bit, then, if it seems right, loosening that to the point where some DEs can ok adding entries after we've figured out what guidance to provide to those DEs. 2: Does it list a name that they'd be using? Great, done! [ insert the Oprah Winfrey "You get a registration and you get a registration" meme here — https://knowyourmeme.com/memes/oprahs-you-get-a-car ]. It is intended to be an informational registry to help people avoid conflicts, and potentially also figure out what to read to know more about foo.alt - IMO they can be handed out like candy. It's better to have it easy for people to get added than just squat… The current IANA Considerations bit says "Expert Review" or "IESG Approval" — the second bit is specifically incase there are issues with getting DEs… That said, I'd still be ok with progressing the draft if the registration rules stayed as they are now. Thank you - the registry is something I've gone back and forth on, because there are pros and cons… Sure - if it's only me arguing for RFC-required, then I'm fine with being in the rough on that aspect. Cheers, S. W Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell wrote: > Hiya, > > On 19/08/2022 20:43, Warren Kumari wrote: > > So, it is perfectly acceptable (in my view) for it to have: > > Reference Name > - > a-cool-document foo.alt > another-document foo.alt > yet-another-doc bar.alt > > I agree that such duplicate names are acceptable in this registry. > > I scanned the draft quickly and think it's good. (I'll try do a closer > read in a few days.) > > Only thing with which I'd argue for now is that I think RFC required is a > much simpler rule for the registry. > My concern with this is that we may end up with lots of Internet Drafts which either need to be put in some WG or be AD sponsored, and have to go through IETF LC, and IESG Eval, and use RFC Editor resources and similar. For an informational only thing that seems like a lot of overhead. I'm also not very sure that IETF participants would really want to review yet another block-chain based name resolution system every N weeks… > Any other option will require some designated experts with some guidance > for those DEs, and I'd expect it to be hard for us to agree what guidance > to include in the draft or not, and I'd expect it to be hard to find DEs > for this registry. > Yup, that's a valid concern - IANA's site speaketh thusly: "If you choose Expert Review or Specification Required as the registration procedure for your new registry, it can be helpful to provide guidance to the “expert.” The idea is to provide the expert with guidance on naming, allocation and other issues related to the protocol registry. Sometimes Internet-Draft authors include the guidance directly in the draft. Other times, a Working Group will decide to collect guidance for a group of protocols together (for instance, see the PWE3 working group in RFC 4446)." — https://www.iana.org/help/protocol-registration I'd think that the guidance to the experts would be: 1: Is there a specification somewhere? RFC8126 (Spec Required) says that a specification should be a "document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value." 2: Does it list a name that they'd be using? Great, done! [ insert the Oprah Winfrey "You get a registration and you get a registration" meme here — https://knowyourmeme.com/memes/oprahs-you-get-a-car ]. It is intended to be an informational registry to help people avoid conflicts, and potentially also figure out what to read to know more about foo.alt - IMO they can be handed out like candy. It's better to have it easy for people to get added than just squat… The current IANA Considerations bit says "Expert Review" or "IESG Approval" — the second bit is specifically incase there are issues with getting DEs… > That said, I'd still be ok with progressing the draft if the registration > rules stayed as they are now. > Thank you - the registry is something I've gone back and forth on, because there are pros and cons… W > Cheers, > S. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC8552 (7064)
The following errata report has been verified for RFC8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7064 -- Status: Verified Type: Editorial Reported by: Bernie Hoeneisen Date Reported: 2022-08-02 Verified by: Warren Kumari (Ops AD) (IESG) Section: 4.1.2. Original Text - | URI| _acct | [RFC6118] | Corrected Text -- | URI| _acct | [RFC7566] | Notes - Wrong reference. Note that is also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names --- Readers are encouraged to read the below email thread (and may also want to read RFC6118 for additional information): https://mailarchive.ietf.org/arch/msg/dnsop/TuoV8FmCf1l_pKr500Fo0AI8tVM/ -- RFC8552 (draft-ietf-dnsop-attrleaf-16) -- Title : Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Publication Date: March 2019 Author(s) : D. Crocker Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
Hiya, On 19/08/2022 20:43, Warren Kumari wrote: So, it is perfectly acceptable (in my view) for it to have: ReferenceName - a-cool-document foo.alt another-documentfoo.alt yet-another-doc bar.alt I agree that such duplicate names are acceptable in this registry. I scanned the draft quickly and think it's good. (I'll try do a closer read in a few days.) Only thing with which I'd argue for now is that I think RFC required is a much simpler rule for the registry. Any other option will require some designated experts with some guidance for those DEs, and I'd expect it to be hard for us to agree what guidance to include in the draft or not, and I'd expect it to be hard to find DEs for this registry. That said, I'd still be ok with progressing the draft if the registration rules stayed as they are now. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
On Fri, Aug 19, 2022 at 2:06 PM, Paul Wouters wrote: > On Fri, 19 Aug 2022, Paul Hoffman wrote: > > Support and opposition are welcome, but suggested text changes are even > more welcome. Once we get this right, Warren and I will ask for another WG > Last Call so that it can move on. > > NIT: I think the abstract should mention any IANA registries created. > > Section 2: > > DNS resolvers that serve the DNS protocol and non-DNS protocols at the > same time might consider .alt like an entry in the "Transport- Independent > Locally-Served DNS Zone Registry" that is part of IANA's > "Locally-Served DNS Zones" registry, except that .alt is always used to > denote names that are to be resolved by non-DNS protocols. > > I'm not sure what this is not written simpler: > > DNS resolvers that serve the DNS protocol and non-DNS protocols at the > same time MUST resolve .alt names using the non-DNS protocols. > > On wireformat, you say: > > Note that using .alt as a pseudo-TLD does not mandate how the non-DNS > protocol will handle the name. If the non-DNS protocol has a wire format > like the DNS wire format, it might append the null label at the end of the > name, but it also might not. This document does not make any suggestion for > how non-DNS protocols deal with the wire format of their names. > > My concren is if a DNS resolver supporting alt names makes it selection > based on wire format and not string (presentation format). We want to avoid > the string to be seen as a non-FQDN that needs an FQDN appended. So I think > we might need to be a little more subtle here? > > This document creates an IANA registry for specification documents that > use the .alt pseudo-TLD. > > I still believe the whole point of .alt is to give people a non-DNS space > that IETF stays out of. I do not think it should create or maintain a > registry for this. > I'll happily note that this was my original position, and, I think, Paul's as well. However, after a good discussion with Martin Schanzenbach (GNS) I was convinced otherwise and managed to convince or (perhaps browbeat?) Paul into agreeing. We are having all of these discussions because there is no (clear) way to differentiate names in one resolution context from those in another resolution context. I've personally thought that it would have been really nice if the resolution context had always been explicit, instead of default / implicit. We retrofitted this into some names already with things like 'printer.local' and 'facebookwkhp[...]fyd.onion', and, with this document, names that end in .alt. If we don't have a registry of some sort, we are simply recreating this problem, but "one level down"; I'd like to think that we've learnt something over the years. If I'm writing something like a browser, I'd sure like to be able to go look at some list somewhere, and have some sort of idea what module / library / similar might be able to understand what a name like foozlewhatzit.gns.alt means. Also, if I'm developing the Great Naming System, I might like to know that having my names end in gns.alt is a bad idea. In my view / expectation (and it should be clearer in the draft), the registry is simply an informational / advisory thing to help people avoid conflicts, explicitly not "this is yours". So, it is perfectly acceptable (in my view) for it to have: ReferenceName - a-cool-document foo.alt another-documentfoo.alt yet-another-doc bar.alt I'll once again note that I was originally of the opinion that there shouldn't be a registry[0], but was convinced otherwise by someone interested in using the space… but all that this shows is that I can be convinced to change my mind :-) W [0]: Or that someone somewhere would keep an informal one… > Security Considerations could say that .alt queries MUST NOT be forwarded > to other DNS servers for resolution. Or perhaps it could state DNS > resolvers MAY use special handling of .alt queries as to only query for the > non-existence of the .alt TLD and MUST NOT send second level domain queries > within the .alt TLD to other DNS servers. > > Paul > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review
On 8/19/2022 3:30 PM, Paul Hoffman wrote: DNS resolvers that serve the DNS protocol and non-DNS protocols at the same time MUST resolve .alt names using the non-DNS protocols. It was written the current way as a way to alert developers who are using the Locally-Served DNS Zones registry that this is like that, but not completely like that (because of the non-DNS part). We can take it out if that's too confusing Translation: "Name resolvers that resolve names with both the DNS protocol, and with other non-DNS protocols MUST only resolve .alt names using non-DNS protocols". But should .alt ever be resolved by anything other than non DNS? E.g.: "DNS resolvers MUST NOT resolve .alt terminated names and instead should return " or even "... MUST NOT resolve .alt, .onion, .home and .corp terminated names (case ignored")..." Mike ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review
On Aug 19, 2022, at 11:06 AM, Paul Wouters wrote: > Section 2: > > DNS resolvers that serve the DNS protocol and non-DNS protocols at > the same time might consider .alt like an entry in the "Transport- > Independent Locally-Served DNS Zone Registry" that is part of IANA's > "Locally-Served DNS Zones" registry, except that .alt is always used > to denote names that are to be resolved by non-DNS protocols. > > I'm not sure what this is not written simpler: > > DNS resolvers that serve the DNS protocol and non-DNS protocols at > the same time MUST resolve .alt names using the non-DNS protocols. It was written the current way as a way to alert developers who are using the Locally-Served DNS Zones registry that this is like that, but not completely like that (because of the non-DNS part). We can take it out if that's too confusing. > On wireformat, you say: > > Note that using .alt as a pseudo-TLD does not mandate how the non-DNS > protocol will handle the name. If the non-DNS protocol has a wire > format like the DNS wire format, it might append the null label at > the end of the name, but it also might not. This document does not > make any suggestion for how non-DNS protocols deal with the wire > format of their names. > > My concren is if a DNS resolver supporting alt names makes it selection > based on wire format and not string (presentation format). We want to > avoid the string to be seen as a non-FQDN that needs an FQDN appended. > So I think we might need to be a little more subtle here? More subtle, or more verbose? You are correct that the current wording could make it harder for an application that is only looking at the wire format to know what to do. I think saying more would be better. > This document creates an IANA registry for specification documents > that use the .alt pseudo-TLD. > > I still believe the whole point of .alt is to give people a non-DNS > space that IETF stays out of. I do not think it should create or > maintain a registry for this. Noted, but I heard lots of voices on the list that wanted the registry. There is nothing in the document that gives the IETF control over the new non-DNS namespace for .alt; the IETF is only involved if someone wants to be in the IANA registry. > Security Considerations could say that .alt queries MUST NOT be > forwarded to other DNS servers for resolution. Or perhaps it could > state DNS resolvers MAY use special handling of .alt queries as to > only query for the non-existence of the .alt TLD and MUST NOT send > second level domain queries within the .alt TLD to other DNS servers. That wording would indicate that, the moment this RFC is published, all current DNS resolvers are breaking a new MUST NOT requirement. I would hope that is not what we want to do. Are the security properties for any name that end in .alt any different than those of any name that is not in the root zone? If so, we should list them in the security considerations. Otherwise, we can just say something to the effect that .alt names have similar security issues to all other DNS names that do not exist in the global DNS. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review
On Fri, 19 Aug 2022, Paul Hoffman wrote: Support and opposition are welcome, but suggested text changes are even more welcome. Once we get this right, Warren and I will ask for another WG Last Call so that it can move on. NIT: I think the abstract should mention any IANA registries created. Section 2: DNS resolvers that serve the DNS protocol and non-DNS protocols at the same time might consider .alt like an entry in the "Transport- Independent Locally-Served DNS Zone Registry" that is part of IANA's "Locally-Served DNS Zones" registry, except that .alt is always used to denote names that are to be resolved by non-DNS protocols. I'm not sure what this is not written simpler: DNS resolvers that serve the DNS protocol and non-DNS protocols at the same time MUST resolve .alt names using the non-DNS protocols. On wireformat, you say: Note that using .alt as a pseudo-TLD does not mandate how the non-DNS protocol will handle the name. If the non-DNS protocol has a wire format like the DNS wire format, it might append the null label at the end of the name, but it also might not. This document does not make any suggestion for how non-DNS protocols deal with the wire format of their names. My concren is if a DNS resolver supporting alt names makes it selection based on wire format and not string (presentation format). We want to avoid the string to be seen as a non-FQDN that needs an FQDN appended. So I think we might need to be a little more subtle here? This document creates an IANA registry for specification documents that use the .alt pseudo-TLD. I still believe the whole point of .alt is to give people a non-DNS space that IETF stays out of. I do not think it should create or maintain a registry for this. Security Considerations could say that .alt queries MUST NOT be forwarded to other DNS servers for resolution. Or perhaps it could state DNS resolvers MAY use special handling of .alt queries as to only query for the non-existence of the .alt TLD and MUST NOT send second level domain queries within the .alt TLD to other DNS servers. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-schanzen-gns and namespace mechanisms
> On 19. Aug 2022, at 17:06, Schanzenbach, Martin > wrote: > > Signed PGP part > Hi Brian, > > thank you for the feedback. > >> On 19. Aug 2022, at 16:46, Brian Dickson >> 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
Re: [DNSOP] draft-schanzen-gns and namespace mechanisms
Hi Brian, thank you for the feedback. > On 19. Aug 2022, at 16:46, Brian Dickson > 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
Re: [DNSOP] draft-schanzen-gns and namespace mechanisms
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
[DNSOP] draft-ietf-dnsop-alt-tld-16: please review
Greetings again. The recent traffic on the list shows a strong interest in reviving draft-ietf-dnsop-alt-tld, hopefully to get it out of the WG and into the IETF, then publication as an RFC. In the past, the WG has gotten quite borked on some of the details in the draft, many of which were not actually relevant to "here's the string and here's what it can be used for". This version of the draft removes a lot of cruft, including the not-actually-honest 6761 template that is no longer required by the IESG for inclusion in the registry. We also added the new IANA registry that has been being contemplated on the list in the past few days. We hope we got the right balance of utility as a registry versus making it clear that the names in the registry don't have to be unique. Support and opposition are welcome, but suggested text changes are even more welcome. Once we get this right, Warren and I will ask for another WG Last Call so that it can move on. --Paul Hoffman (certainly not speaking for Warren) smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-16.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : The ALT Special Use Top Level Domain Authors : Warren Kumari Paul Hoffman Filename: draft-ietf-dnsop-alt-tld-16.txt Pages : 10 Date: 2022-08-19 Abstract: This document reserves a TLD label, "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-wkumari-dnsop-alt-tld. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-16 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
On Fri, 19 Aug 2022, Stephen Farrell wrote: domains at IANA. FWIW, that doesn't describe where I've so far landed on this. It omits the requirement that there be an RFC for each entry. As I've said several times, most recently yesterday, if we make people jump through hoops to put their names on the list, most quasi-DNS will continue to ignore us and squat wherever they are squatting now. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
Hiya, On 19/08/2022 14:35, Paul Wouters wrote: Okay, so I understood that you want to run a yellow pages for non-DNS domains at IANA. FWIW, that doesn't describe where I've so far landed on this. It omits the requirement that there be an RFC for each entry. That IMO does mean such a registry is within the purview of the IETF. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
On Fri, 19 Aug 2022, John R Levine wrote: I could have been clearer. The names can be duplicates, not the rest of the entry. So someone comes along and registers web.alt with a pointer to her thing, then someone else comes along with a different thing but also calls it web.alt, and we another entry in the registry. What does the registry do or prevent? Is it meant to be a Yellow Pages of non-IETF naming ? If so, why should we run it? If it accomplishes something else, what ? If people want to avoid collisions, it gives them an idea of what's already in use somewhere. Of if you run into ITU.ALT, you can (give or take link rot) find out what it is supposed to do. Okay, so I understood that you want to run a yellow pages for non-DNS domains at IANA. I do not think that is within the purvey of the IETF. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...
I could have been clearer. The names can be duplicates, not the rest of the entry. So someone comes along and registers web.alt with a pointer to her thing, then someone else comes along with a different thing but also calls it web.alt, and we another entry in the registry. What does the registry do or prevent? Is it meant to be a Yellow Pages of non-IETF naming ? If so, why should we run it? If it accomplishes something else, what ? If people want to avoid collisions, it gives them an idea of what's already in use somewhere. Of if you run into ITU.ALT, you can (give or take link rot) find out what it is supposed to do. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On ALT-TLD, GNS, and namespaces...
> On 08/18/2022 10:17 PM EDT Ben Schwartz > wrote: > > Perhaps you haven't been following the W3C DID process [1]? The > "registrable .alt" proposal closely resembles the functionality of the DID > "method" system, and you can see the registrations that have poured in > there [2]. I note that some of the registered names already raise some > notable potential for trademark collision or user confusion. How is that DID different than the IETF's URN? Maybe the W3C registration process has less friction or they respond to emails faster. One thing that gives me pause is a note on their DID specification registry page [1] it says: " Portions of the work on this specification have been funded by the United States Department of Homeland Security's Science and Technology Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, 70RSAT20T0010, and HSHQDC-17-C-00019." That last contract went to Digital Bazaar. My guess is they fall under the title Blockchain Applications for Homeland Security Analytics [2] which is to design and prototype an ecosystem to help law enforcment. [1] https://www.w3.org/TR/did-spec-registries/ [2] https://www.sbir.gov/node/867813 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
