Hi Barry, we've uploaded a new version that should address your helpful comments: https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
On Mon, 3 Apr 2023 at 00:38, Barry Leiba via Datatracker <nore...@ietf.org> wrote: > Reviewer: Barry Leiba > Review result: Ready with Nits > > This is short and reasonably sweet, easily digested. I have a few minor > comments that I think will help make the document slightly clearer, and I > hope > you'll consider them: > > — Section 3.1 — > > I think this is generally understandable, but reuse of “it” does allow > room for > error. I suggest avoiding vagueness, possible ambiguity, and > misunderstanding > as follows: > > OLD > 1. Generate a Random Token with at least 128 bits of entropy. > > 2. Take the SHA-256 digest output [SHA256] of it. > > 3. base64url encode it. > > NEW > 1. Generate a Random Token with at least 128 bits of entropy. > > 2. Create a SHA-256 digest [SHA256] of the Random Token. > > 3. base64url encode the SHA-256 digest. > > END > > (And you might include RFC 4648 as a reference for base64url encoding.) > > One thing that I do find unclear is this: > > Providers MUST provide clear instructions on when a verifying record > can be removed. The user SHOULD de-provision the resource record > provisioned for a DNS-based domain verification challenge once the > one-time challenge is complete. These instructions SHOULD be encoded > in the RDATA via comma-separated ASCII key-value pairs [RFC1464] > using the key expiry. If this is done, the token should have a key > token. For example: > > _foo-challenge.example.com. IN TXT > "token=3419...3d206c4,expiry=2023-02-08T02:03:19+00:00" > > First: It’s unclear how a one-time challenge fits in with an “expiry” > key. Is > it meant to be the case that lack of an “expiry” key means that the > “token” is > meant for one-time use, and presence of “expiry” makes it time-based? Or > something else? I think this could be clearer. > > Second: “the token should have a key token” confused me until I finally > realized that you ought to be using quotes to identify the key names, thus: > > NEW > These instructions SHOULD be encoded > in the RDATA via comma-separated ASCII key-value pairs [RFC1464] > using the key “expiry”. If this is done, the token should have a key > “token”. > END > > That makes it clearer that the key names are not just words in the > explanatory > text. > > — Section 3.2 — > > In the newspaper business, what you’ve done here is called “burying the > lede”. > I suggest instead, leading with the recommendation and following with the > reasoning: > > NEW > Because CNAME records cannot co-exist with any other data, it is > NOT RECOMMENDED to use CNAMEs for DNS domain verification. > > Reasoning: What happens when both a CNAME and other records exist > depends on the DNS implementation, and might break in unexpected > ways. If a CNAME is added for continuous authorization, and for > another service a TXT record is added, the TXT record might work but > the CNAME record might break. Another issue with CNAME records is > that they must not point to another CNAME. But while this might be > true in an initial deployment, if the target that the CNAME points to > is changed from a non-CNAME record to a CNAME record, some DNS > software might no longer resolve this as expected. However, when > using a properly named prefix, existing CNAME records should never > conflict with regular CNAME records. > END > > Thanks, > Barry > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
