Re: QUIC re-chartering: include DNS-over-QUIC?
Daniel Migault <mglt.ietf@gmail.com> Thu, 06 February 2020 14:57 UTC
Return-Path: <mglt.ietf@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 0CBDC12006D for <quic@ietfa.amsl.com>; Thu, 6 Feb 2020 06:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SOMCZVAnTQ8r for <quic@ietfa.amsl.com>; Thu, 6 Feb 2020 06:57:28 -0800 (PST)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 291D412004E for <quic@ietf.org>; Thu, 6 Feb 2020 06:57:27 -0800 (PST)
Received: by mail-vs1-xe29.google.com with SMTP id g23so3933408vsr.7 for <quic@ietf.org>; Thu, 06 Feb 2020 06:57:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NWLnv1q2whbYxe0dWVva0EdMbZEAbcra1Y+KSsosGoY=; b=Tb4mFpbyUXKafSyXX0H67jDeBsxsuX4WnT480IQDlHkSQu1pUPRUrpiB/gGdLbN76g NqqvsE4W2yh6D+WvkP2q5JN9HGtkpT6VARuCOXUpbhZoqL6p6E2DpfuXBs04o7TZMXMw 4Rn5XFsDYqV2TNEjtieJVaLZu6y5thsKpLLTZDnlwPtsgaBKF4Dq7GmR2IwgQyjPg012 kE2XVoYdBJOTJTQTUQDvnyUWjaR98p8oPiCa7T/LDWi2h8pj00ngIlAOvBsB25mN5FYp UV7WSPYoIp0bsDh1scf+kCFnvFo0sWkfh8F46NVi2luJrIjeGBDEGflAwX6e8KvIGlx6 xfoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NWLnv1q2whbYxe0dWVva0EdMbZEAbcra1Y+KSsosGoY=; b=QtHFhP0ZCs/nxGaszkg+YXBiUZwdqVSgMeXDxAQTb2J599tcj0bBDIyPquM5/I6/u7 3bk/4OaHibDtWcKazB1mh/5KkBIFpaeoOfqSfddZLG0GlAl05qJ9g+6x21u9VZMQUyod yAWZ828cK5fHYe4kCQNhM1Lqa1RTvR4Yx0mzoAE2u2l+4e/kXrsGcVZvlUMCKmT1pXC3 cWqdZuiYrVRAexfxXNywEUcZm35djGteAbtcxgyszKkmxTe+nJ9sEEpFxJ4eVuQnnU/m fVt+KgO7BMuapQhzSBdqg2kU9gAlGobZPNtfma3b5nQakyEm7fDbAYO0Ye4BDmmtR0XQ HhJA==
X-Gm-Message-State: APjAAAWSk7TmL38YjsQtArNODWoFY2pvo4KScnfw+Uwz/fIv60QsmWSH nwkbFXZ3TRJUFUSQRI8l1eoThTe/OIbr51tSiFJqyzcE
X-Google-Smtp-Source: APXvYqx7CMXPyKWoWhcXGFyBw2aTQ982thUMzvn1XPJnqbs6GEYG2YWXLDfunjySJB9tKY/D06tev33rmg/O/yGmjsg=
X-Received: by 2002:a67:89c4:: with SMTP id l187mr1861419vsd.31.1581001045776; Thu, 06 Feb 2020 06:57:25 -0800 (PST)
MIME-Version: 1.0
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <CAKC-DJiuhJurq4ojJwPD0Ag3Eoz_4KwFssuuP5Ts1+EH6C9C2A@mail.gmail.com> <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net>
In-Reply-To: <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Thu, 06 Feb 2020 09:57:14 -0500
Message-ID: <CADZyTkk1LYaEQWeniqbN_iq2SMZ=nqHaSn-bYb8wQjvx2B6m2g@mail.gmail.com>
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
To: Christian Huitema <huitema@huitema.net>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Erik Nygren <erik+ietf@nygren.org>, Lars Eggert <lars@eggert.org>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b91d74059de97d8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/uoj58mG_TsjpUfjFY7IZYhfF_U0>
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: Thu, 06 Feb 2020 14:57:32 -0000
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 <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
- 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