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

[Ian Swett <[e-mail]>]

+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
>
>