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

From: Erik Nygren <[email-masked]>
Date: Tue, 4 Feb 2020 16:05:03 -0500

On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham <[email-masked]> wrote:

> We've just put out Calls for Adoption for extensions to QUICv1, as we
> believe that the group has some capacity to discuss them as it finishes
> work on the core protocol.
>

Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg,
draft-huitema-quic-dnsoquic-07
<https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07>) as well,
presumably in coordination with the DNS community?

Getting a second protocol using QUIC might help make sure we work through
issues that may arise early, plus DNS-over-QUIC seems quite attractive as a
technology for resolver-to-authoritative communication if/when we go that
way.  ie, it seems strictly better than defining a DNS-over-DTLS and also
seems to have plenty of advantages over DoT.

The current charter also says:

This [HTTP] mapping will accommodate the extension mechanisms defined in
> the HTTP/2
> specification. Upon completion of that mapping, additional protocols
> may be added by updating this charter to include them.
>

Best,
     Erik

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 04 Feb 2020 16:17:03 -0800

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.

Best,
Tommy

> On Feb 4, 2020, at 1:05 PM, Erik Nygren <[email-masked]> wrote:
> 
> On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> We've just put out Calls for Adoption for extensions to QUICv1, as we believe that the group has some capacity to discuss them as it finishes work on the core protocol.
> 
> Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg, draft-huitema-quic-dnsoquic-07 <https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07>) as well, presumably in coordination with the DNS community?  
> 
> Getting a second protocol using QUIC might help make sure we work through issues that may arise early, plus DNS-over-QUIC seems quite attractive as a technology for resolver-to-authoritative communication if/when we go that way.  ie, it seems strictly better than defining a DNS-over-DTLS and also seems to have plenty of advantages over DoT. 
> 
> This [HTTP] mapping will accommodate the extension mechanisms defined in the HTTP/2

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Feb 2020 01:49:54 +0000

Erik was suggesting

  *   plus DNS-over-QUIC seems quite attractive as a technology for resolver-to-authoritative communication if/when we go that way.

I’d rather not see HTTP embedded in resolvers except to handle clients.  There’s no reason for the root servers, e.g., to have an HTTP stack.  Smaller attack surface.

DNS seems like a good fit for QUIC; it’s request/response, and it’d be great to not have to care about UDP vs TCP.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Feb 2020 21:52:51 -0800

> presumably in coordination with the DNS community?

I think it would be OK to define DoQ (though I share Tommy's question about
DoH/3, which needs no additional standardization) but I don't think that
should be done in the QUIC WG, any more than we define HTTP in TCPM. We
needed one driving study but now that the QUIC mapping is done, other
mappings should probably be done elsewhere.

> way.  ie, it seems strictly better than defining a DNS-over-DTLS
>

You might be interested in https://tools.ietf.org/html/rfc8094

-Ekr

> and also seems to have plenty of advantages over DoT.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Feb 2020 09:55:26 +0100

Hi Tommy,

On Wed, Feb 5, 2020 at 1:17 AM Tommy Pauly <tpauly=
[email-masked]> 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.
>

I think the deployment path here is really for folks who were on DoT (or
considered DoT) but want to have the advantages of QUIC.  As such, I
support the DNS over QUIC work.  I believe it is actually easier for folks
who want consistent semantics from DNS over UDP-->DNS over (D)TLS-->DNS
over QUIC, with none of the HTTP semantics entering the equation.

regards,

Ted Hardie

> 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.
>
> Best,
> Tommy
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 5 Feb 2020 10:33:24 +0100

I share Tommy’s and Ekr’s questions and thoughts on this. I think you are right Ted that DoQ is probably more straightforward and has less components. However, I also feel that the number of DNS query transport solutions is growing :-) and that it might be worthwhile for us to think about which of these have sufficient market demand. I thought DoH (and DoH3 as a natural version of that) had a standing, which other ones do?

Jari

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Feb 2020 09:59:54 +0000

Hi,

This will not be included in this rechartering. This one is targeted to enable
three specific work items. A larger recharter is planned to happen when the main
set of the v1 spec is done. 

Also, a DNS over QUIC specification could work that should happen in another WG.
My current thought is that QUIC will focus evolving the protocol, doing
extensions and updates. Thus additional protocol mappings should really only be
done if that mapping shows stress on QUIC which may require fixes or updates to
the protocol to resolve. 

But, please figure out if this is a reasonable piece of work to do anywhere in
the IETF. However, the right place may be a more DNS focused WG. 

Cheers

Magnus Westerlund

On Tue, 2020-02-04 at 16:05 -0500, Erik Nygren wrote:
> > believe that the group has some capacity to discuss them as it finishes work
> > on the core protocol.
> 
> draft-huitema-quic-dnsoquic-07) as well, presumably in coordination with the
> DNS community?  
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Feb 2020 10:32:45 +0000

> the IETF. However, the right place may be a more DNS focused WG. 

FWIW, I think doing this somewhere else seems better.
As dprive are considering recursise->authoritative,
I hope this option gets examination as part of that.
I'm not sure if it'd be better than DoT but if it
were, that'd perhaps provide a justification for
standardising DoQ.

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 6 Feb 2020 03:35:47 -0800

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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 6 Feb 2020 09:57:14 -0500

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

-- 
Daniel Migault
Ericsson

---

From: Erik Nygren <[email-masked]>
Date: Thu, 6 Feb 2020 10:13:33 -0500

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?

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Feb 2020 15:25:22 +0000

Agree very much with what Christian wrote.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 06 Feb 2020 08:12:35 -0800

> to dprive in Vancouver and/or Madrid if the authors are interested and 

+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
> 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
> > 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 <[email-masked] <mailto:huitema@huitema..net>> wrote:

---

From: Ian Swett <[email-masked]>
Date: Thu, 6 Feb 2020 11:46:34 -0500

+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 <[email-masked]>
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

---

From: Vidhi Goel <[email-masked]>
Date: Thu, 06 Feb 2020 09:26:46 -0800

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=[email-masked]> 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 <[email-masked]> wrote:
>> 
>> 
>> > >>  browser is sending queries for the pages that it visits.. But that's not

---

From: Paul Vixie <[email-masked]>
Date: Thu, 6 Feb 2020 22:16:42 +0100

Vidhi Goel wrote on 2020-02-06 18:26:
> 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.

i fear this may be off-topic for this mailing list; in which case, just 
tell me. i've been watching this thread carefully, and i think the 
concern about too many dns transports with no possible guidance to 
developers as to which one to try in what order. as a server operator i 
expect to have to support everything, which means arguments about threat 
surface in one transport vs. another are effectively null.

i can definitely see why the QUIC team might want more than one proof, 
it would help assure us all that there aren't HTTP assumptions designed 
in. and all of the reasons i never pushed for DNS over DTLS or DNS over 
SCTP are certainly addressed by DNS over QUIC.

however, my reasons for not pushing DNS over DTLS or DNS over SCTP are 
also addressed by DoT. i'd be grateful if you could explain what 
problems you think DoT has, which would beg us to invent another DNS 
transport profile such as DNS over QUIC.

i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond the 
fact that DNS is a convenient second example of how QUIC can be used. if 
there are use cases or failure modes not handled well by DoT, i'd like 
to learn more about those.

-- 
P Vixie

---

From: Erik Nygren <[email-masked]>
Date: Thu, 6 Feb 2020 16:27:14 -0500

> to learn more about those.

Some possible reasons (not comprehensive):

* Reduce the impact of head-of-line blocking during loss.  If packets are
lost, only the request(s) associated with the loss are impacted.
* Faster resumption and 0RTT behaviors (although you get some of these with
TFO + TLS 1.3 0RTT).  But this substantially reduces the performance impact
when new connections need to be established.
* The previous also means servers can be more aggressive about timing out
connections to reduce the state they need to keep, but while minimizing
perf impact, which can be critical at-scale.
* Better ability for load balancers at-scale to do creative things,
including being able to recover better when Anycast moves routes between
data centers.  (The server-supplied Connection ID means that options become
available to better recover without needing to reset re-establish
connections and without needing to share state between clusters.)
* QUIC provides a framework for future extensions that may be useful in the
DNS space.  For example, FEC might actually be useful for DNS in some cases.

I'm sure there are plenty more reasons...

     Erik

---

From: Erik Kline <[email-masked]>
Date: Thu, 6 Feb 2020 14:12:09 -0800

On Thu, Feb 6, 2020 at 1:17 PM Paul Vixie <[email-masked]> wrote:

> developers as to which one to try in what order.
>

I think the add charter might be aiming to address the advice to clients
concern (https://datatracker.ietf.org/doc/charter-ietf-add/).

---

From: Martin Duke <[email-masked]>
Date: Mon, 10 Feb 2020 19:57:58 +0100

As others have said, this is great work that should be done elsewhere. If
we've done a good job, the QUIC transport should be able to handle this use
case without a bunch of transport-re-engineering.

However, if it turns out you need a protocol tweak, please come back to us.