On Fri, Aug 19, 2022 at 2:06 PM, Paul Wouters <p...@nohats.ca> 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: Reference Name --------------------------------- a-cool-document foo.alt another-document foo.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
