Hi, On Aug 23, 2022, at 4:18 AM, Schanzenbach, Martin <[email protected]> wrote: >> IMHO, if you want to be in a carve-out of the domain name space, you still >> need to play by the domain name space's technical rules, in a way that's >> backwards compatible with systems that don't know about the carve-out and >> will assume that veryverylonglabel.foo.alt _is_ a domain name.
Just to be clear, it IS a domain name. The magic terminal label “.alt” merely indicates (to applications that are aware) that the FQDN is not supposed to be submitted to the DNS for resolution. > I think the notion that there is strict "format" of a name and that if it is > not in that format is not actually part of the same namespace is already > behind us. Not as long as there are operating systems and applications that assume that a domain name is, well, a domain name. > If that were the case then we do not need .alt at all. > For example, GNS names are UTF-8. They are not LDH or any kind of > DNS-compliant wire format. You are mixing domain names, host names, and names to be resolved via the DNS together. If you want to create a GNS namespace that doesn’t "look like”, that is, interpreted by a users, application, or operating system as a domain name (e.g., フォオ:GNS), there is no need to discuss this within the context of DNSOP (or maybe even the IETF). As far as I know, that’s not what is being discussed here. The idea is that there is a "cut out” of the domain name namespace that will help users, applications, and operating systems to know that a particular partition of the domain name space is NOT to be resolved via the DNS, rather (if the last labels of the domain name are “gns” followed by “alt”) it is to be resolved via GNS. The key part is that it is a partition of the _domain name_ namespace. The question of LDH or UTF-8 is orthogonal. UTF-8 or random binary gibberish are perfectly acceptable within the domain name namespace. It is NOT acceptable for a “host name”, which is the subset of domain names used to identify hosts resolved via the DNS. Whether or not random binary gibberish is acceptable to end users is a separate question. > I think one way to look at is is that we try to solve a problem with the > display/presentation of names in alternate name systems and how they can be > confused by applications but also humans with DNS names. Yes. > Applications (to some degree) have to deal with malformed names anyway as > part of the user input handling. > If they consider the given .alt-name malformed because they only expect DNS > names, then that is within the expected behaviour. Of course, the vast majority of applications don’t try to parse the domain name. They take argv[n] and blindly throw it to gethostbyname() or whatever and if that routine returns an error, the application exits. > If the application crashes because of such a name, it would also crash > because of data corruption or faulty user input. > And that is a bug in the application, possibly even a security issue if it > leads to a buffer overflow etc. IIRC, the whole creation of punycode and IDNA was because of concerns that the use of UTF-8 in a host name context was going to break applications. I’m intrigued that these concerns are now just hand-waved away. Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
