The introduction references RFC1035. This may have been exactly the
right thing to do, but RFC1035 is a fairly old representation of the
state of the art of the domain name system at this point. When it was
written, RFC1034 might have been a better entry point unless the
authors assumed that the readers would necessarily already be familiar
with it (a not unreasonable assumption).

However, in this modern time, I think that it might make sense to
reference RFC9499 first and RFC1035 second. That might sound like an
odd choice, but please read the introduction to RFC9499 before
dismissing it entirely! The particular reason I think this is relevant
is that RFC9499 doesn't update RFC1035, so the reader won't get a clue
to reference it from the metadata for RFC1035, and I think RFC 9499
adds significant value.

I don't feel strongly about this--I think it's likely that most
readers will already have the information they need. However, this
document updates a fairly core document in the suite of internet
standards, and so it might make sense to account for the occasional
naive reader. Needless to say, I leave it up to the authors and ADs
whether this is a good idea, but I think it might be.

---

Non-DNS question: why is the "SHOULD NOT" in paragraph 2 of 4.1.1.1
not a MUST NOT? What is the exception?

--

Section 5.1 doesn't say what to do with chained CNAMEs. It might be
worth saying more here. A strict reading of the spec here would I
think treat chained CNAMES correctly in the sense that if the target
of the CNAME is treated as the initial name, then each target would be
processed the same way, by first looking for a CNAME. And of course a
full-service resolver will do the CNAME work for the SMTP client. So
perhaps clarifying that the "resulting name" is the result of fully
following the CNAME as described in RFC1035 section 7.1. Or maybe this
is unnecessary--I leave this to the judgment of the authors and ADs.

--

Does section 5.1 need to talk about the NULL MX? This was discussed
earlier, but isn't mentioned here.

--

I found this text in 5.1 to be a bit more obscure than necessary:

   Any other
   response, specifically including a value that will return a CNAME
   record when queried, lies outside the scope of this Standard.

Why not just say that any other response, including a CNAME even if it
ultimately points to an A or AAAA record, is not a valid response and
MUST be ignored?

--

My general experience of this document as a DNS directorate reviewer
is that I found a lot of questions that had answers, and very few that
did not. :)