Re: QUIC re-chartering: include DNS-over-QUIC?

[Christian Huitema <[e-mail]>]

On 2/4/2020 4:17 PM, Tommy Pauly wrote:

> My main question in doing DNS-over-QUIC is what benefit it provides
> over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical
> deployment model, since it allows relatively seamless upgrade from
> DoH2 to DoH3, and allows a resolver to support consistent semantics on
> both. The overhead of the HTTP layer is pretty minimal, and while I
> appreciate the desire to define a non-HTTP protocol over QUIC, I
> imagine there would be ones that would be more useful to adopt in the
> near term.

There are significant differences between DoQ and DoH. My main worry is
that protocol written to run over HTTP tend to be developed on top of
web platforms, and so you end up bringing the entire attack surface of
the web platforms in your DNS implementation. That's OK if your DNS
usage is directly dependent on your web traffic, for example if a
browser is sending queries for the pages that it visits. But that's not
so good for the resolver to authoritative scenario, in which a leaner
protocol seems safer.

But there are other issues. Look at the "M" scenario in the Quic Interop
runner, loading 2000 small files in parallel. It turns out that several
implementations had issues because when doing that they were hitting the
OS limit on the number of open files. The way you control that in Quic
is by limiting the number of open streams below the number of files that
you can maintain open. In a web-oriented implementation of H3 and Quic,
you will most likely do that. But you don't need to worry about that in
the DNS scenario, because you are certainly not going to write a file
for every DNS transaction. Doing an ad hoc application mapping avoids
this kind of issues.

-- Christian Huitema