This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document is a mature and straightforward mapping of DNS over QUIC, 
modeling a QUIC connection as equivalent to DNS over TCP with one query
per stream. 0-RTT and fallback design choices are reasonable and
well-explained. Security and privacy considerations are well-presented. 
All in all, a very good example of an application mapping over QUIC.

I have only a few nits here:

Editorial nits:

- in section 5.3.1, is STOP_SENDING spelled "STOP_SENDING" 
or "Stop Sending"? Please choose one.

- "These privacy issues are detailed in Section 9.2 and Section 9.1" 
is a weird order; please swap.

Content nit:

I understand the intent behind "Implementations MUST protect against the
traffic analysis attacks described in Section 9.5 by the judicious injection of
padding"; however (1) there is no interoperability risk from failing to comply
with this restriction, and (2) as an implementor, it would not be clear to me
how to prove my padding injection was "judicious". 

There is a reference to an experimental RFC 8467 that presumably defines
acceptable padding policies, but it is referenced as "should consider".

I would recommend one of the three following remedies:

- change this to a SHOULD (since verifying compliance is impossible as phrased),
- add a normative downref to 8467 and make it clear that that reference defines 
padding policies considered compliant, or
- provide some other guidance implementors can use do determine whether
they are padding enough to be considered compliant.

Further, traffic analysis threats are not limited to packet lengths, as section 9.5
acknowledges. Is there any equivalent MUST guidance regarding stream frame
timing for traffic analysis resistance that could be given here?