The draft addresses the longstanding problem of DNS using an insecure transport protocol in the way that it should have been addressed from the start - encrypting the UDP packets. It is an important and overdue addition to the network protocol stack.

The approach to using QUIC is about as straightforward as is possible given the legacy infrastructure. One area that is likely to require attention that is not addressed is the interaction of DNS and PKI and DHCP in the context of WiFi roaming networks.

The principled way to address this use case would be for WiFi networks requiring authentication and/or agreement to terms to advertise via a standardized interaction signaled through e.g. DHCP. But there being no such agreed standard, public WiFi access points engage in a wide variety of approaches to intercepting the user's attention. Many of these intercept DNS connections. Thus, the assumption that DNS is insecure is built into legacy systems.

While the incoherence of existing infrastructure is outside the remit of this specification. Guidance to implementers on this point might help reduce the amount of additional incoherence generated. Just noting that this is an issue might spur folk to correct this situation.

The security considerations section forwards to RFC7858. This specification is six years old and represents the state of knowledge before deployment of the specification. Further the scope of 7858 is stub-to-recursive traffic, the new draft discusses zone transfer which is far outside that scope.

The document has a privacy considerations section but all of the text would normally come under the 'confidentiality' heading in security considerations. The distinction is helpful in some cases but does not appear to add much in this one.

The section on traffic analysis states information can be gained from observing packet lengths. Given the sensitivity of DNS traffic to analysis, this seems like a significant oversight. Even if QUIC does not provide a convenient mechanism for doing this, it could easily be added within the DPRIVE binding.