IETF Logo Mail Archive

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

Tommy Pauly <tpauly@apple.com> Wed, 05 February 2020 00:17 UTC

Return-Path: <tpauly@apple.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 2C15012018D for <quic@ietfa.amsl.com>; Tue, 4 Feb 2020 16:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 WzF-j52bRNww for <quic@ietfa.amsl.com>; Tue, 4 Feb 2020 16:17:11 -0800 (PST)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63E2120152 for <quic@ietf.org>; Tue, 4 Feb 2020 16:17:09 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 0150C7gF012107; Tue, 4 Feb 2020 16:17:05 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=ene2c6Ya8alzVG04kCAN3FCXnizPvk3Zyo23peSLQLM=; b=XbzPiLMYsgS/WBc+hbdxl62iEHxlHiTnZwG6Ld+2KKO8wEXIcLACXlulQu9Mca3/IFX6 Foa6/MqQuIPp/wHkJmJpP3lrg9WhCoDT4GMWxgxSxGK6gQ6ZpxviVjUBA9/3bRSX11m0 PdEAG7MDtuoz068AgkTF+PS14XmWIyGgiuX6sJhXGE9aOH18PUSBV+kvuNUqE+fFWbQY h+3lKNg1lHMx8rWROhKN2qd84zDpsP9vPVK41Kk4lXqfJWYCI3HhjsOT3TFwhGU7JK7u M3Rz+DMvMvRDFupaX8ZMBvcNAbdO1OQOYvjeoRDizl+wx3WslmeAWQL5I7FIo6eLlklF dg==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2xyhk1hafy-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 04 Feb 2020 16:17:05 -0800
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5700Q8ACSGZ450@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 04 Feb 2020 16:17:04 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5700G00C9G5H00@nwk-mmpp-sz13.apple.com>; Tue, 04 Feb 2020 16:17:04 -0800 (PST)
X-Va-A:
X-Va-T-CD: 3c405e4a76e9c4b391e73361135699a4
X-Va-E-CD: 6ca81ff41316a3e61e2ef30272efd66a
X-Va-R-CD: 300a1c5f914f022e7d32c9a02a47ecc6
X-Va-CD: 0
X-Va-ID: 6139513b-e985-444f-aa5d-a4cf5b12ad8e
X-V-A:
X-V-T-CD: 3c405e4a76e9c4b391e73361135699a4
X-V-E-CD: 6ca81ff41316a3e61e2ef30272efd66a
X-V-R-CD: 300a1c5f914f022e7d32c9a02a47ecc6
X-V-CD: 0
X-V-ID: 947f4da0-07ea-400b-9516-09f28f9968fe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-04_09:,, signatures=0
Received: from [17.234.11.169] (unknown [17.234.11.169]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q57006EHCSFU220@nwk-mmpp-sz13.apple.com>; Tue, 04 Feb 2020 16:17:03 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_D94D1B47-BB8E-4FCC-9E02-4E16D2B9471A"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
Date: Tue, 04 Feb 2020 16:17:03 -0800
In-reply-to: <CAKC-DJiuhJurq4ojJwPD0Ag3Eoz_4KwFssuuP5Ts1+EH6C9C2A@mail.gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
To: Erik Nygren <erik+ietf@nygren.org>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <CAKC-DJiuhJurq4ojJwPD0Ag3Eoz_4KwFssuuP5Ts1+EH6C9C2A@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/roPNRcYwKpHBaYjOuHxzqGTEWp0>
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: Wed, 05 Feb 2020 00:17:13 -0000

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 <erik+ietf@nygren.org> wrote:
> 
> On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> 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
>

v2.23.0 | Report a Bug | By Email