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