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

[Lucas Pardue <[e-mail]>]

Mikkel, all,

Thanks for the healthy discussion on this thread. As suggested up thread,
this proposal was taken to the DPRIVE WG and presented at their interim
meeting last week.

DPRIVE have issued a call for adoption [1], I encourage continued
conversation over there.

Cheers
Lucas

[1]
https://mailarchive.ietf.org/arch/msg/dns-privacy/kXmy4lZ-MzUKCP5zrca9I4WmiVI/


On Sun, 12 Apr 2020, 19:49 Mikkel Fahnøe Jørgensen, <[e-mail]>
wrote:

> Late to the game. I support DoQ.
> Maybe there are too many DNS transports, and maybe DNS as such does not
> need it, but for all communication endpoints that invest in QUIC as the
> sole transport it would be very convenient to have DoQ. DNS is a low-level
> dependency for most QUIC application protocols so if you have a non-HTTP
> based application, why would you want to drag in HTTP just for the sake of
> DNS, disregarding attack surfaces? DoQ instead of UDP/TCP DNS handles
> privacy / security and avoids another dependency.
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 12 April 2020 at 01.46.25, Paul Vixie ([e-mail]) wrote:
>
> On Thursday, 6 February 2020 21:27:14 UTC Erik Nygren wrote:
> > On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[e-mail]> wrote:
> > > 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.
> >
> > Some possible reasons (not comprehensive):
>
> forgive the long delay in responding, please.
>
> > * Reduce the impact of head-of-line blocking during loss. If packets are
> > lost, only the request(s) associated with the loss are impacted.
>
> you're assuming that the loss isn't self-induced. sometimes slowing down
> is
> exactly what's needed. for example when a busy full resolver has a queue
> of
> hundreds or thousands of requests to be sent to a zone authority, rate
> limiting of UDP is necessary to prevent a meltdown. bandwidth is finite..
> we
> sometimes load-balance toward several of a zone's authority servers even
> including those known to not have low-ish RTT, just to avoid flooding one
> of
> them, or to avoid flooding our nearby links. moving to QUIC won't help
> with
> any of that.
>
> > * 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.
>
> in DNS, new connections rarely need to be established. the reason RFC 6013
> permitted connections to go into a quiet (resumable) state and keep the
> learned cwin in compressed state so that the cost of that state would be
> no
> worse than what was needed for syn flood protection. since you mentioned
> TFO i
> want to say two things, first it was insecure and can't be used, exactly
> as we
> predicted (william simpson and i), and second TCPCT allowed for payloads
> as
> part of the initial or resumptive segments to get exactly the 0RTT
> benefit.
> but i don't want to drone on like a sore loser. the point is, in DNS,
> novel
> connections are rare, and careful statekeeping to support resumption (such
> as
> DNS cookies as defined in RFC 7873) is already present in pre-QUIC DNS.
>
> > * 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.
>
> this reduces to a noop because the statekeeping is subject to botnet
> attacks.
> just as all TCP listeners have to implement syn flood protection, so it is
> that all stateful endpoints (whether DNS, TCPCT, TFO, or QUIC) have to be
> aggressive about timing out connections they need not keep fully open.
> QUIC
> has no special capabilities or requirements in this regard.
>
> > * 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.)
>
> while it's theoretically possible to share DNS cookie state (RFC 7873)
> across
> many instances of DNS Anycast, the cost:benefit of that complexity is less
> compelling than the cost:benefit of having to renegotiate during route
> changes
> either from mobile-ip or network-in-the-middle attacks. i don't think QUIC
> has
> different game theory than DNS cookies have in this regard. route changes
> are
> orders of magnitude less frequent than same-pair reuse, and always must
> be.
>
> > * 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...
>
> i appreciate the time you put into listing these initial motivations.
> however:
>
> > On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[e-mail]> wrote:
> > > 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.
>
> ....my question seems to stand. if the potential motivations you've listed
> so
> far were actual, then we'd have had DNS over SCTP decades ago, or
> something
> like DTLS that actually worked at scale rather than just in a lab, or we
> would
> have been able to get TCPCT the code point we needed to experiment
> globally,
> or we would have had UDP options by now.
>
> i consider DoQ inevitable, but for QUIC's purposes ("proof of broader
> applicability"), not DNS's purposes ("working better"). DNS is old and
> warty
> but it does move and it has evolved.
>
> --
> Paul
>
>
>