Overall I found this draft well-written, straightforward, and relatively easy to follow (although there are a lot of external RFC references).  

Some overall advice:

It would be helpful to put "ADN" in the list of terms (section 2).  It is defined in the introduction, but it is used liberally in the rest of the document and a reader might expect to be able to find in the terms section.

Additionally, "ADN-only" might be helpful to put in the list of terms.  This term is used less often, but it is repeated far enough away from section 3.1.6 to possibly be helpful in section 2.

I don't really want to suggest that you change the various option formats, but as a DNS person, I had an observation about them.

* The "ADN length" should not be necessary as wire-format DNS names are actually length encoded.  Providing the ADN length does, however, allow a parser to skip over the name without parsing the ADN itself which may be useful.
* The "ADN length" doesn't need to be 16-bits, and it isn't in the DHCPv4 format.  It is a little curious that the length of this field differs across the different option implementations.

Beyond that, I just had some language nits:

In section 3:

> This document describes how a DNS client can discover local encrypted DNS resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery protocol (Section 6): Encrypted DNS options.

This seems odd. I think this sentence could just end after "(Section 6)".

In section 3.2.1:

> To avoid adding a dependency on another server to resolve the ADN, the Encrypted DNS options return the IP address(es) to locate the encrypted DNS resolver. These encrypted DNS resolvers may be hosted on the same or distinct IP addresses. Such a decision is deployment specific.

I found this wording of the 2nd sentence hard to follow.  Hard enough to follow that I don't know what is trying to be said.  Maybe the 2nd and 3rd sentences could just be deleted?

In section 3.1.6:

Why is there a block quote here?  What is it quoting?

In section 3.1.8:

> The ADN is present and encoded as per Section 10 of [RFC8415].

In addition to providing the RFC reference, one could also describe the encoding as "uncompressed DNS wire format."