On Nov 11, 2022, at 9:48 AM, Wessels, Duane <dwessels=40verisign....@dmarc.ietf.org> wrote: > > I find the latest alt-tld draft to be inconsistent when it first > says “[alt names] should not be looked up in a DNS context” and > "DNS stub and recursive resolvers do not need to look them up in > the DNS context” but then later "Caching DNS servers will treat > [alt names] just as they would any other name whose TLD does not > appear in the global DNS root.” Since caching servers lookup names > with non existent TLDs in the DNS, then of course alt names will > also be looked up in the DNS context.
The first quote, “[alt names] should not be looked up in a DNS context”, is clearly meant to be about applications that act as stub resolvers or actual stub resolvers. That is, not that "it is bad to $x so don't do it", but "it is not designed to $x so don't do it". That should be made clearer in the text. The second quote, "DNS stub and recursive resolvers do not need to look them up in the DNS context” does not conflict with "Caching DNS servers will treat [alt names] just as they would any other name whose TLD does not appear in the global DNS root.” - A DNS stub or recursive resolver that knows about one alt name does not need to look up names from that namespace in the DNS context because it will look them up in the special context. - A DNS stub or recursive resolver that knows about one alt name does not need to look up names from an alt namespace it does not recognize in the DNS context because it can treat it like a DNS name if it wants to; it could also treat it as an inherently unknown name (due to alt) if it wants. In the latter case, it needs to follow DNSSEC processing rules. > I'm also struck how radically different the special use considerations > for .onion (RFC 7868) and .alt are. onion has multiple MUST-level > requirements for not leaking queries into the global DNS. The authors (and some of the WG) felt that the current wording was an improvement, so hopefully it would not strike you too hard. > IMO we should write requirements to describe the behavior we want. Yes. > Even though we know from experience that not all implementations > will adhere to the requirements it is appropriate to say that alt names > MUST NOT or (at least SHOULD NOT) not leak. That is only true if you weigh the cost of reducing leakage against the benefit. > And even if we don't end up with strong anti-leaking requirements, > then we should at least openly acknowledge that leaked queries > will happen (i.e., to root name servers). Yes. > Lastly, I'd like to see the special use considerations for .alt > formatted more like the examples given in that RFC 6761 and the one > in RFC 7686. Again, the current wording is considered an improvement over the requirements of RFC 6761 and the worked-out example in RFC 7686. If the WG wants the enumeration, we should be more careful about it. > I’d like to propose this new/updated text for the alt-tld draft: > > ====================================================================== > > 1. Users: Human users might or might not recognize that names > in the .alt pseudo-TLD are special. > > 2. Application Software: Applications that use alternative > namespaces in .alt MUST have their own processing > rules for their own names, probably in specialized resolver > APIs, libraries, and/or application software. This seems very wrong. I think it should be allowed, but definitely not required, for applications to have special processing rules. It is quite conceivable that naive applications would work fine if the special processing is done in the stub resolver they talk to. > 3. Name Resolution APIs and Libraries: Resolvers MUST NOT resolve > .alt names in a DNS context. They MAY respond to > queries for such names with NXDOMAIN. > > 4. Caching DNS Servers: Caching servers MUST [or SHOULD] NOT > attempt to resolve .alt names in the global DNS root. They > MAY respond to queries for such names with NXDOMAIN [or > REFUSED?]. See above. To me, it is natural to do the processing in a stub resolver, not in the applications. (Note that RFC 6761 doesn't talk about stub resolvers at all, so I'm assuming it would consider a stub resolver here not in #3.) For upstream recursive resolvers, saying "MUST" seems wrong because there is no significant effect if a resolver does not follow the specification. Saying "SHOULD" without explaining the exception is bad form. Further, Mark Andrews' observation about queries with DO set should bring pause to anyone wanting a MUST NOT for resolvers here. > 5. Authoritative DNS Servers: Authoritative servers MUST respond to > queries for .alt names with NXDOMAIN. > > 6. DNS Server Operators: Operators MUST NOT configure an > authoritative DNS server to answer queries for .alt. > > 7. DNS Registries/Registrars: Registries and Registrars MUST > NOT register .alt names because .alt will not exist in the > global DNS root. All such requests MUST be denied. It doesn't feel that the heavy-handedness of the above wording is justified by sending a slightly smaller number of queries to the root servers. > Note that despite the requirements given here, it is generally expected > that queries for .alt names will "leak" into the global DNS. The root > name servers [RFC 7720?] will receive leaked queries and respond with > NXDOMAIN. Techniques such as qname minimization, aggressive NSEC caching, > and root-on-loopback can reduce the amount of leaked queries received by > root name servers. This seems like a good addition even if we don't change the current 6761ish text. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
