Since this I-D was submitted for early dnsdir review, the draft is
essentially a work in progress and much remains to be done.

I doubt this I-D will be a valuable addition to the DNS oeuvre that
merits WG attention. As written, it's a mixture of implementation
guidelines and a survey of current approaches to domain verification
techniques. These might be better as discrete documents on the ISE
track. However the I-D has been adopted by the WG. It's not adding or
changing the core protocol and therefore won't be a burden to the DNS
Camel.

There are quite a few gaps that need to be filled. Which is to be
expoected in early versions of a draft.

There isn't a clear enough problem statement or use case: what
problems does this I-D solve and how does it do that?

The I-D is unclear about the roles and responsibilities commonly found
in today's DNS where the domain name holder is not the controller or
administrator for the domain and neither provides authoritative DNS
service for it. How could/should domain verification work in these
settings?

The doc could be clearer on the semantics of these validation domain
RRs. ie Their presence only proves who had control of the domain when
these RRs were added or removed, not who holds the domain name or is
ultimately responsible for it. This is important, especially when so
many aspects of DNS operations are outsourced these days.

Section 1 describes how domain verification is performed today but
doesn't explain why. Or discuss the strengths and weaknesses of this
approach. Could non DNS-based approaches - some out of band method -
work or not? Are there scenarios where these could be better than
using something stored in the DNS? Or does the DNS-based approach
obliterate these?

A definition for the counterpart of Provider is missing. Client
perhaps?

Several Sections are missing. The I-D jumps directly from Definitions
to Recommendations! The authors need to show their working. In
detail. ;-) This should include details of which approaches were
considered and their advantages and disadvantages. There needs to be
an explanation why TXT records are RECOMMENDED and, by implication,
why other RRTypes are not. CERT records for instance could be a valid
alternative that offer additional security features. Section 3.2
explains (somewhat clunkily) why CNAMEs are unsuitable. But that's
only a small part of the story.

A Section on procedural/process issues is needed: how the Provider and
Client synchronise their updates, how this gets agreed and documented,
when/how validation domain names get added or removed, max/min TTL
values, problem escalation considerations, etc.

The discussion of the TXT record in Section 3.1 is defective. The
validation domain name probably needs to have a unique owner-name as
well as some unique token in the RDATA. There's no explanation or
justification for using a random token with at least 128 bits of
entropy. Why not 256 or 64 (say)? A small number of entropy bits could
be "good enough", for instance when the validation RRtype is
short-lived or only used once. Similar issues arise from mandating
SHA-256. One day that algorithm will be deprecated => updating this
prospective RFC. A "strong" hash algorithm isn't always necessary
either. That's also holds for RFC4086's randomness requirements.
Should the validation domain name include a timestamp to
detect/prevent replay attacks?

If these parameters are to be requirements and/or mandatory to
implement, the rationale for their adoption needs to be given.

Is this part of the I-D documenting one provider's approach? Should it
be defining a generalised, interoperable solution?

The last paragraph of 3.1 is in the wrong place. It belongs in a
section on implementation considerations. Some of the text is
fluffy. What would "offer detailed help pages that are accessible
without needing a login on the provider website" look like in
practice? What content should be in the detailed help pages? The
sentence beginning "Similarly, for clarity," is confusing. Who is
expected to provide the full DNS record? How? And in what format?

The Security Considerations Section needs a lot more work. It should
document the threat model which outlines roles and responsibilities as
well as potential attack vectors and how to mitigate them. These would
include MitM attacks, spoofing, (D)DoS, Client-side or Provider-side
bad actors, poorly chosen TTL values, replay attacks, securing the
Client-Provider channel(s), etc.

Appendix A is an excellent idea and much appreciated. Some of tha
material needs to go elswhere in the document though. A 1.3 and A1.4
should be in the main body of the I-D. It should not be in an appendix
which describes the domain verification techniques used by significant
Providers. The discussion of fragmentation also needs to move from
Appendix A. It should explain that using discrete owner-names for each
validation domain RR would avoid fragmentation concerns. Guidance on
the size of validation domain RRs - ie TXT records - and any
accompanying DNSSEC-related RRtypes might also help here.


Minor but annoying nits:

It's domain name holder, not domain name owner.

Standards documents shouldn't use personal pronouns: tThe "you"s in
Appendix A.