> On 11 Nov 2022, at 09:48, 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.
>
> 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.
>
> IMO we should write requirements to describe the behavior we want.
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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?].
Caching servers MUST NOT intercept DO=1 queries as the client
will not be able to validate such responses. The caching
recursive server MAY synthesise a provable NXDOMAIN response as
per RFC 8198. Caching servers SHOULD perform QNAME minimisation
as per RFC 7816 for the .alt namespace by default. Querying for
alt/DS or alt/NS will achieve this without leaking the query type.
> 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.
>
> 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.
>
> ======================================================================
>
> DW
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
