On 23/08/2022 12:18, Schanzenbach, Martin wrote:
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.
If that were the case then we do not need .alt at all.
Arguably you do not, but unless there is some _other_ indicator that a
name is a GNS name (e.g. https+gns://) then we have a problem.
non-GNS-aware clients will send all those queries to the DNS.
But if the carve-out is done using the rightmost one or two labels as
proposed with ".alt", then existing code has to cope. Any application
that wants to parse a name _even if the nsswitch is .alt aware_ might
need to be modified to allow these domain-style names to get as far as
the system's resolver.
Conforming to a couple of (IMHO not particuarly onerous) restrictions on
total length and label length would go a long way to mitigate that.
For example, GNS names are UTF-8. They are not LDH or any kind of DNS-compliant
wire format.
DNS does not require LDH, or ASCII.
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.
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.
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.
I am not so concerned with crashes. I am concerned that there is a
semantic difference in the errors generated when a name cannot be parsed
vs when it does not exist.
Yes, the net result is that the resource cannot be found, but over the
years there have been significant issues caused by misinterpretation of
errors.
Ray
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
