Re: QUIC re-chartering: include DNS-over-QUIC?
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sun, 12 April 2020 18:49 UTC
Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5FC3A24DE for <quic@ietfa.amsl.com>; Sun, 12 Apr 2020 11:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsWUNrgAU_PA for <quic@ietfa.amsl.com>; Sun, 12 Apr 2020 11:49:42 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4032B3A24DD for <quic@ietf.org>; Sun, 12 Apr 2020 11:49:42 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id f14so4148052ybr.13 for <quic@ietf.org>; Sun, 12 Apr 2020 11:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=u3loSrOO9AyV8lRWtLddrcH2MLWECSZaei/3VxmCDDk=; b=fIYgIz9qmtQUFf8q5ZAqBjwlJmC6QWc8x13kw+g70CDn+vKRoObufsPNp2CNPvwdvZ UB+nG3Vxltp+eXoVM5QsWSHXfpP9ZGfgbtOUNYbhiR+ryqamkSKfwOjB+upTq8DnN8l5 xYhMTEfUVzAP0ELQz8v8yutaJo2Yi5RoXwwfuWUTFMzo406jhw3mIKKtbbCXNEnLTkYy 2j0gs9twfWl2u3q+6fPlWxEYC/iKT6p4nXv9Vo1JLpaFVb12WMhgJ12nhKgotOK1NnG+ 8cggGx7YF0LG3xzSokK9tA5NgmakwAk1CL/XHedwr1oGmb42NorcviUbmI7rO5D/Vv7x fdRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=u3loSrOO9AyV8lRWtLddrcH2MLWECSZaei/3VxmCDDk=; b=PePHBNke9Ex1Z0y83RJyZMmAMscdP0l6qfEW11uUBxwijCi+oI0Ng8KTx1umhB66rF 6jSw5XikRqRID+KNWgCO2m4V3T7NIQIquPkpwsJkmGdyimiaTZDvneal8Ul16i7Y++4K WvxNhmX7mR9252cMLpwaJ+5B3JfMrR8bilNlv4sVT06260dEYhSTE1uaHTnopiBQcscK HWBQRIFz/YhqSrCceJoEiVxRsyqkIZgBTtJLvv2rgG+ylTrzDM9dH3WmgoAGLsOOEy3b qkL89jdZznnCHf0Vfp+/gr7OyLfHMDAFwT22mjvHdsbhEgddMtzQInJLNNd3it4Syiv7 r27A==
X-Gm-Message-State: AGi0PubDZGToLGLdRWq1jL0lKBC7hpEqd+xGa1FMiMzW5J3M3xw6fiBM g+VDinAF6VhsBm9HG/MuIFjNqRqgEFfuKU3+Fhp0+Q==
X-Google-Smtp-Source: APiQypLm9iYC30TMYXtWCpwBSJsidL6ybpwYr719ASD96WAFISk6oAGuBwKYZzxp5C1n1B/p80niFK2dkB1qIyb+Wqg=
X-Received: by 2002:a25:14d6:: with SMTP id 205mr22399309ybu.113.1586717381065; Sun, 12 Apr 2020 11:49:41 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 12 Apr 2020 11:49:40 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <21444935.R3TQEuPsEl@linux-9daj>
References: <CAKcm_gNf43tXizw9D2jdtTieh+=zS7PKVDiNNV-UEbP8Gw+mHg@mail.gmail.com> <de87e833-de54-ae5a-cd85-2f93565192f7@redbarn.org> <CAKC-DJjNbBYVzmN=KxnRKpxK_eJFcbGFvejx1Xms-X2iesBVrg@mail.gmail.com> <21444935.R3TQEuPsEl@linux-9daj>
MIME-Version: 1.0
Date: Sun, 12 Apr 2020 11:49:40 -0700
Message-ID: <CAN1APddZUy8Ae2cSi_RnfeftsOpS-7NUHHWZiXtR_dk6qgUCxQ@mail.gmail.com>
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000db7f1c05a31c6d84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/BoiQSZB9_XBX6WN1Sj646NSGFJs>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Apr 2020 18:49:45 -0000
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 (paul@redbarn.org) wrote: On Thursday, 6 February 2020 21:27:14 UTC Erik Nygren wrote: > On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <paul@redbarn.org> 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 <paul@redbarn.org> 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
- Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Jana Iyengar
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Salz, Rich
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Multipath (was: Re: Re-chartering for extension w… Lars Eggert
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Christian Huitema
- RE: Re-chartering for extension work Mike Bishop
- RE: Re-chartering for extension work Kuhn Nicolas
- Re: Re-chartering for extension work Ian Swett
- Re: [EToSat] Re-chartering for extension work Christian Huitema
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Multipath (was: Re: Re-chartering for extensi… Florin Baboescu
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Multipath (was: Re: Re-chartering for extensi… Ryan Hamilton
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Jana Iyengar
- RE:(2) Multipath (was: Re: Re-chartering for exte… Madhan Raj Kanagarathinam
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Lars Eggert
- RE: Re-chartering for extension work Roni Even (A)
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Kuhn Nicolas
- RE: [EToSat] Re-chartering for extension work Kuhn Nicolas
- Re: Multipath Gorry Fairhurst
- Re: Re-chartering for extension work Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Tommy Pauly
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- RE: Multipath (was: Re: Re-chartering for extensi… tim.costello
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Lucas Pardue
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Tommy Pauly
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Eric Rescorla
- Re: QUIC re-chartering: include DNS-over-QUIC? Ted Hardie
- Re: QUIC re-chartering: include DNS-over-QUIC? Jari Arkko
- Re: QUIC re-chartering: include DNS-over-QUIC? Magnus Westerlund
- Re: QUIC re-chartering: include DNS-over-QUIC? Stephen Farrell
- Re: QUIC re-chartering: include DNS-over-QUIC? Christian Huitema
- Re: QUIC re-chartering: include DNS-over-QUIC? Daniel Migault
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Christopher Wood
- Re: QUIC re-chartering: include DNS-over-QUIC? Ian Swett
- Re: QUIC re-chartering: include DNS-over-QUIC? Vidhi Goel
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Duke
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Mikkel Fahnøe Jørgensen
- Re: QUIC re-chartering: include DNS-over-QUIC? Lucas Pardue
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Thomson
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie