I have been assigned as the DNS Directorate reviewer of this draft.

Ready with Nits

It appears that the -11 version does address the issues raised in the previous
DNSDIR review.  

I do feel like the document is disjointed in the target audience. 
For example, section 3.1 discusses all the various misconfigurations, 
if the target audience is DNS Operators, I would hope a BCP would have examples
both good and bad perhaps in an appendix.  Or maybe the target audience is 
more advanced? 

Section 4: 


4.2 Guidelines for Recursive DNS Resolvers

   Every recursive DNS resolver SHOULD be dual-stack.

Why not MUST? This is a BCP, It should be a MUST or should explain why it is not? 


    Having zones served only by name servers reachable via one IP address
    family would fragment the DNS. Hence, the need for a way to avoid
    this fragmentation.

Not just fragment the DNS, but cause resolution failures.  I feel referring to it as fragmentation and not resolution failures isn't ideal.  But I can't come up with
better wording.



"Avoiding IP Fragmentation"

Questions about discussion of Fragmentation. This is brought up in sections 3.2 and 4.1 and seem to be mostly aligned but reading them:


   3.2 - Avoiding IP Fragmentation:

      Therefore, IP fragmentation SHOULD be avoided by following
      guidance on maximum DNS payload sizes [RFC9715] and providing TCP
      fall back options [RFC7766].  Furthermore, similar to the guidance
      in [RFC9715], authoritative DNS servers MAY set an MSS of either
      1388 (analogous to [RFC9715]) or 1220 (analogous to the
      [DNSFlagDay2020] suggestions) in TCP sessions carrying DNS
      responses.

either 1388 or 1220....

    4.1 - DNS-over-UDP packets requiring fragmentation

      In general, DNS servers SHOULD follow [RFC9715], which provides
      additional guidance on preventing fragmentation by ensuring that
      the maximum DNS/UDP payload size does not exceed 1400 octets.
      This can be accomplished by setting a corresponding EDNS(0) size,
      with most implementations using a lower EDNS(0) size of 1232
      octets as per the suggestions made by the [DNSFlagDay2020]
      initiative, to ensure that generated packets always fit into lower
      bound of the IPv6 MTU of 1280 octets, as defined in [RFC8200].
      Hence, DNS servers MAY also opt to set an EDNS(0) size of 1232
      octets as suggested by the [DNSFlagDay2020] initiative.


...does not exceed 1400...using a lower size of 1232 per ... or 1280 or 1232 

If I was an operator looking at this, I would be wondering why the differences? 
There are reasons, but they should be either be more descriptive or
combine the guidance in one place, and refer to it.  This is just me. 

I will not hold up the document based on this, but it feeds back to my thoughts
on the target audience. 

5 Security considerations

   *  Two resolvers handle queries for a set of clients, each of these
      resolvers support one and only one address family that is distinct
      from the address family supported by the other resolver;

Should this not be "Two recursive resolvers" ?  It would make sense if you are
making security considerations for authoritative servers, you should do so separately.