Early Review of draft-yao-dbound-identify-dns-boundary-01
review-yao-dbound-identify-dns-boundary-01-dnsdir-early-obser-2025-09-27-00

I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

I have been given 4 questions from the requester which I will answer
up front:
1. Is this approach appropriate as an independent submission [given
   that it was the topic of a WG and a bof that tried to revive the
   work]?
   On the one hand this draft feels like an end-run around the IETF
   process. It did not get traction twice before. On the other hand,
   it's informational and documents an idea that someone had, which
   seems acceptable.
   I'd rather see this work done in a wg, or if no consensus could be
   reached, the author getting the hint to drop the topic. But I don't
   think it's flat out inappropriate.
2. Is the approach unambiguous in terms of zone delegations?
   It's not specifying any normative behaviour for authoritative
   servers nor recursive resolvers. So it does not relate to zone
   delegation at all. However, it is hard to tell because it is
   unclear what problem the document is trying to solve and how it is
   trying to solve it.
3. Does the approach introduce any challenges relating to DNSSEC
   (DS/ZSKs/KSKs/...)
   No.
4. Is the draft well written?
   No. I'm sorry to be blunt, but no. It needs serious editorial work
   before a review of the content can be performed. I can't
   point at individual sentences, it's the whole document I'm afraid.
   The issue is that I either don't understand what the document tries
   to say, or at best I have to guess what the meaning is. An RFC
   has to be clear and avoid any guesswork on the reader's part.

Some more concrete points:

| Abstract
|
|    Two or more DNS names belonging to the same registrants may share the
|    same DNS administrative boundaries.
[...]
| 1.  Introduction
|
|    Two or more DNS [RFC1034] [RFC1035] names may have the same
|    administrative boundaries.  If they share the same DNS administrative
|    boundaries, we regard that they have a relationship.
[...]
| 2.  Terminology
|
|    The basic DNS terms used in this specification are defined in the
|    documents [RFC1034] and [RFC1035].  The shared administrative
|    boundaries of DNS names imply, at minimum, that such names are under
|    the control of either the same registrant or cooperating registrants.

I don't know what an "DNS administrative boundary" is, those sentences
do not clarify it.
As to terminology, RFC 9499 is a much better reference than pointing
to 1034/1035.

| Abstract
|
[...]
|    This document adds the function of lookup of domain name
|    administrative boundary to domain name system, which describes a new
|    method for using dbound resource record for determining domain name
|    administrative boundaries.

This sentence should make it clear that this document introduces the
DBOUND RR, it is not using an existing DBOUND RR for a new idea.

The document does not have a problem statement but refers to expired
drafts. Either those drafts need to be revived first (preferable) or
integrated into this draft. Lacking a problem statement makes it
difficult to review this draft.

|    As the ICANN new gTLD program has expanded, registrants frequently
|    obtain multiple domain names serving a common purpose.  Consequently,
|    there is a need to develop a mechanism for determining when two or
|    more domain names share administrative boundaries.

Lacking a problem statement, it is not clear why this needs to be
solved in DNS. Assuming there is a problem to be solved, why is it not
solved in EPP, whois or rdap?

| 3.  Framework
[...]
|    If flag=0, the Anchor Name / Name Collection is the anchor name, and
|    the anchor name will be the string of PSL.

This is the first use of PSL and it is not defined in the terminology
section. From context in the rest of the document it is also not clear
what it means. It seems to be fundamental to the document though.
Without it being defined it is impossible to review section 3 and 4.

| 4.  Application Algorithm for Dbound Query

It is not clear if there is one algorithm or 3 algorithms. Lacking a
problem statement, it is not clear what the algorithm does and if it
does it correctly. The description of the algorithm or algorithms
needs to be substantially improved. I could not understand the text at
all.

| 7.  Security Considerations
|    The introduction of the DBOUND (Domain Boundary) Resource Record (RR)
|    to identify administrative boundaries in the DNS raises several
|    security considerations that should be addressed.

I am sure secdir is going to point this out as well: The Security
Considerations section is the place to list the security issues that
the draft introduces and how they should be addressed. Just stating
that there are several security issues is not going to be good enough.