On Aug 19, 2022, at 11:06 AM, Paul Wouters <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
