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

[Vidhi Goel <[e-mail]>]

I support DoQ for the use cases that are based on non HTTP application protocol. DoQ implicitly provides benefits of QUIC which DoT doesn’t have.

Vidhi

> On Feb 6, 2020, at 8:47 AM, Ian Swett <ianswett=[e-mail]> wrote:
> 
> 
> +1 as well.  I think this work is worth doing, and I would hope it does not require the QUIC WG's active involvement.
> 
>> On Thu, Feb 6, 2020 at 11:13 AM Christopher Wood <[e-mail]> wrote:
>> 
>> 
>> On Thu, Feb 6, 2020, at 7:13 AM, Erik Nygren wrote:
>> > It sounds like a good path forwards might be to take the 
>> > draft-huitema-quic-dnsoquic 
>> > <https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07>
>> > to dprive in Vancouver and/or Madrid if the authors are interested and 
>> > willing?
>> 
>> +1 — I think taking it to DPRIVE makes sense.
>> 
>> Best,
>> Chris
>> 
>> > 
>> > For encrypting recursive-to-authoritative I'm hopefully that we can 
>> > pick one (or at most
>> > two) things as "MTI" for interop, and I suspect if we had a pros/cons 
>> > matrix for the various
>> > options that a DoQ solution has a good chance as being the contender 
>> > for being the preferred 
>> > option for reasons stated above, as well as for other functionality 
>> > that exists in QUIC
>> > that may make scaling and robustness easier for authority operators. 
>> > 
>> >  Erik
>> > 
>> > 
>> > 
>> > On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault <[e-mail]> wrote:
>> > > I support DoQ being done here or somewhere else to prevent including the attack surface of the web platform as well as to have a non HTTP use case for quic. I also expect that previous work on DoT, DoH will reduce the effort on DoQ. It is true one could question the advantages of having yet another transport, but on the other hand, it might be better we can have the choice now rather than later. 
>> > > Yours, 
>> > > Daniel
>> > > 
>> > > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema <[e-mail] <mailto:huitema@huitema..net>> wrote:
>> > >> 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
>> > >> 
>> > >> 
>> > >> 
>> > > 
>> > > 
>> > > -- 
>> > > Daniel Migault
>> > > Ericsson
>>