On Sun, 16 Oct 2022, Suzanne Woolf wrote:

1. As far as I can tell, this draft does not comply with RFC 6761. This is a 
problem for two reasons.

One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.

For example, the draft says that DNS resolvers seeing .alt names "do not need 
to look them up in the DNS context”,
but a big part of the point of codifying these names is the assumption that 
queries will leak and DNS servers will
see them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is 
simply not in the public DNS root
zone and the root servers (or better yet, any intermediate resolver) should 
answer “name error”/NXDOMAIN for such
queries. But this should probably be said explicitly, because people who 
configure DNS servers and services
shouldn’t have to guess what’s being implied here. (The WG discussed the 
possibility that such queries should be
blackholed and not answered at all, which is in some ways an obvious answer. 
Clarification of why this was discarded
might also be helpful.)

I think it draft would be better if it said something along the lines
of:

No code changes are required to properly handle leaked queries for .alt
into the DNS, but:

1) Implementations MAY handle .alt specially by (pre)fetching the proofs
   of non-existence of .alt and serve these for all .alt queries.
2) implementations MAY rely on their query minimalization to accomplish 1)
3) or MAY do nothing special, which should work fine but might leak SLD
   queries to the root if the implementation and its querier didn't do query
   minimalization)
4) MAY return FORMERR on .alt queries that in some ways violate the DNS
   specification (so that no code changes are mandatory to support the
   madness .alt queries could bring in, eg >63 SLD names)

2. Having the IETF maintain a registry of pseudo-SLDs concerns me

Me too, I really do believe that the IETF should not do this. It is an
anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
Some alternative sysytems might even use .alt without SLD. Basically,
.alt is what IETF recommends you should not do, and we should not keep
a registry of entries within it.

But also, IETF maintaining a list might open it up for legal liabilities
with alternative naming systems. The whole idea of the ICANN/IETF split
is that ICANN does money and legal stuff, and IETF does codepoints and
running code (with no money) :P

So I disagree with Eliot who prefered some kind of FCFS registry that
requires RFCs to get an entry. We do not want alternative naming systems
to require (and burden) the IETF with RFCs.

3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term 
“registered” differently than common usage.
Judging from searches on RFC 6761 and RFC 8499, it’s ambiguous for DNS naming 
and resolution, and “registered” can
definitely mean something different to a registry or registrar than it does to 
a DNS operator. To people who operate
TLD registries, a name can be “registered” and still may or may not be 
delegated. (“Label” is defined in 8499,
“register” and “delegate” are not.) And, in the reference to “TLD,” it feels 
strange to expand the acronym to
“Top-level label” even if “label” is the right word for what you’re talking 
about.

"pseudo-TLD" is not a good word here to refer to .alt, as other common
SLD's that are open to generic registration are often called
pseudo-TLDs, such as .uk.com.

Paul

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to