Skip to main content

The .alt Special-Use Top-Level Domain
draft-ietf-dnsop-alt-tld-25

Yes

Erik Kline
(Robert Wilton)

No Objection

Jim Guichard
(Andrew Alston)

Recuse


Note: This ballot was opened for revision 23 and is now closed.

Erik Kline
Yes
Paul Wouters
Yes
Comment (2023-04-23 for -23) Sent
Some of my comments might be DISCUSS-worthy (my apologies), but I really don't want to block this document for any further time. But please do take my comments into considerations if you can do a quick ref update.

The term pseudo-TLD as defined here is not how I've seen the term
used. A pseudo TLD as I've seen it used is a TLD that's one step
below a real TLD and runs as a general GTLD (open registration),
eg "uk.com". I guess I would qualify the use in this document
more as "fake TLD", but I can see how that might come over as
even more perogative. So I am fine with the current definition
and use case. Perhaps a "to be confused with" note could
be added, but is not strictly required.


        4. Caching DNS servers SHOULD NOT recognize names in the .alt
        pseudo-TLD as special and SHOULD NOT perform any special handling
        with them.

There is value for a recursor to "pre-load" the proof of non-existence
of ".alt" (the entire branch in the hierarchy) to avoid any potential
leakage of subdomains within alt. It could potentially also reduce error
message logs if someone starts using .alt not as a real hierarchy or using
non-DNS valid characters in their name, eg Ulabel stuff or even binary stuff
like 0x00010001000000003616c7400. They could also just return NXDOMAIN instead
of forwarding the query to the root servers to avoid a privacy leak. Or it
could modify the question foo "foo.alt" and only send "alt" to the root. I
see no reason such additional protection mechanisms need to violate this
"SHOULD NOT" clause. Why not flip the statement around?

        4. Caching DNS servers MAY recognize names in the .alt pseudo-TLD
        as special and MAY perform special privacy preserving methods to
        return (DNSSEC signed) NXDOMAIN answers to prevent leaking entries
        under the .alt pseudo-TLD into the global DNS.

        5. Authoritative DNS servers SHOULD NOT recognize names in the
        .alt pseudo-TLD as special and should not perform any special
        handling with them.

Any reason the second "should not" is lowercase ?
Note that I do agree here, and would even say MUST NOT so that people
can use DNS technology even if not rooted in the global DNS for their
.alt names without having to modify existing DNS software (eg run a
shadow .alt using DNS on port 666 or something)

        6. DNS server operators will treat names in ...

I find the use of "will" here a little odd. Perhaps:

        6. DNS servers and operators, which whave no special handling
           for the .alt pseudo-TLD will end up treating names in ...



        7. DNS registries/registrars for the global DNS will never
        register names in the .alt pseudo-TLD because .alt will not
        exist in the global DNS root

"will never" seems wishful thinking. I've seen some very fraudulent stuff
happen with DNS registries/registrars. eg what if one of them will support
pseudo-TLDs along with real DNS domains, and includes bogus .alt registrations?
Perhaps:

        7. DNS registries/registrars for the global DNS can never legitimately
        register names in the .alt pseudo-TLD because .alt will never exist in
        the global DNS root

Again, my apologies to Warren for not balloting a blanc YES :)
Éric Vyncke
Yes
Comment (2023-04-24 for -23) Sent
Thanks to the authors and the DNSOP working group, and of course to Suzanne for a detailed shepherd's write-up.

Important document to bring some clarity for some use cases.

Just two minor comments:

1/ I support Paul Wouters' issue with the name "pseudo-TLD", it is both too late and a bike-shedding exercice... "ghost-TLD" or "filler-TLD" or "dummy-TLD" would have been better

2/ in section 2, s/because .alt, by definition, is not a DNS name./because .alt, by this specification, is not a DNS name./ ?

Regards

-éric
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2023-04-26 for -23) Sent
One comment -- Section 3.2 has "DNS server operators MAY be aware that queries for name ending in .alt are not DNS names, and queries for those names were leaked into the DNS context." The RFC 2119 MAY appears misused in this context.

(Also, in that quote, s/queries for name/queries for names/)
Roman Danyliw
No Objection
Comment (2023-04-25 for -23) Sent
Thank you to Linda Dunbar for the SECDIR review.

** Section 2.
   Currently deployed projects and protocols that are using pseudo-TLDs
   are recommended to move under the .alt pseudo-TLD, but this is not a
   requirement.

I don’t understand the basis of this recommendation.  Projects and protocols using pseudo-TLDs (outside of https://www.iana.org/domains/reserved) are already not following published guidance.  Why is there an expectation that this document can change behavior?

Section 3.2.  Item #3. Editorial.  s/Writers of name resolution APIs/Creators of name resolution APIs/.  Or “developers”, “implementers, or “designers” 

** Section 3.2.  Item #7
   7.  DNS registries/registrars for the global DNS will never register
   names in the .alt pseudo-TLD because .alt will not exist in the
   global DNS root.

Items #4 – 6 on this list use RFC2119 language to make the expected behavior clear.  This text seems to be written in an aspiration form describing what registries/registrars will do, without explicitly prohibiting them with normative language.  Is there a reason for that?
Zaheduzzaman Sarker
No Objection
Comment (2023-04-26 for -23) Not sent
Thanks for working on this document.
Warren Kumari
Recuse
Comment (2023-04-18 for -23) Not sent
'm a nauthor...
Robert Wilton Former IESG member
Yes
Yes (for -23) Unknown

                            
Andrew Alston Former IESG member
No Objection
No Objection (for -23) Not sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (2023-04-24 for -23) Sent
# GEN AD review of draft-ietf-dnsop-alt-tld-23

CC @larseggert

Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1LB6_ujGseyZRWPgTQZrP2pS8zk).

## Comments

### DOWNREFs

DOWNREF `[RFC8244]` from this Proposed Standard to Informational `RFC8244`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

I think RFC8244 could be cited informatively?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 2, paragraph 7
```
 performing aggressive use of DNSSEC- validated caches (described in [RFC8198
                              ^^^^^^^^^^^^^^^^^
```
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

#### Section 2, paragraph 8
```
will cover all names under .alt. Currently deployed projects and protocols t
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 7.1, paragraph 2
```
and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, 
                                ^^^^^^^^^^^^
```
Do not mix variants of the same word ("minimisation" and "minimization") within
a single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool