IETF Logo Mail Archive

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

Erik Nygren <erik+ietf@nygren.org> Tue, 04 February 2020 21:05 UTC

Return-Path: <nygren@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 8189C120170 for <quic@ietfa.amsl.com>; Tue, 4 Feb 2020 13:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 WQoqTNOOfX_y for <quic@ietfa.amsl.com>; Tue, 4 Feb 2020 13:05:16 -0800 (PST)
Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 17F5F12020A for <quic@ietf.org>; Tue, 4 Feb 2020 13:05:16 -0800 (PST)
Received: by mail-wr1-f46.google.com with SMTP id t2so24948221wrr.1 for <quic@ietf.org>; Tue, 04 Feb 2020 13:05:16 -0800 (PST)
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=+gIQZSukE2mRZHrEE2i5nAKNztVTdzArwBY1lFBFA1c=; b=i+5PE8+2o6bnRT7QZ6TE1385Ohbi4NRgB+kfwtR6h9ZHI0pOB7fa3zEyH/X3n4mIJ4 a8Zb8A+xGWi3aDWnlbWCHP5umSMW/Uf0H5UkGCD9pvebnwLNdzKh6XEqP9io7skJGceX qg0PXcP7PA+WxvchandoOB3I9Pfh+/OYbCkafOXpPs9BQJVVE5O2F98zj1Dgu50FEd1n MJ296qQqBRpEIBDJgXRgFIqNKifOS9FRMhkFhyhJ+YgOhT6AiBAZulMTbZNVWSwUWZf6 7/2p37YgUxyBoepNeA7bjtAeeuBbSmwMinWIa7rJ/iOglYGW9snwehID1mC0vL3qzaB6 RmGw==
X-Gm-Message-State: APjAAAW++MMwJ4okt1vE18zgNoN3Cd/i/EQCrQjqaI82XqJMMaRtC4AA /ObZoGNltoLXVznJ8Xzhi3U8tO5/dvkYhM862bCoMqLImHs=
X-Google-Smtp-Source: APXvYqyNi7JIo2JV++mL/CDL7Qr8UGSAJYtT/ix7mbc5I12KusCVgQL/brIGpR4rQN9okiIhAlihYnhMjuqaFI84YgM=
X-Received: by 2002:adf:e686:: with SMTP id r6mr24123553wrm.177.1580850314535; Tue, 04 Feb 2020 13:05:14 -0800 (PST)
MIME-Version: 1.0
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net>
In-Reply-To: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Tue, 04 Feb 2020 16:05:03 -0500
Message-ID: <CAKC-DJiuhJurq4ojJwPD0Ag3Eoz_4KwFssuuP5Ts1+EH6C9C2A@mail.gmail.com>
Subject: QUIC re-chartering: include DNS-over-QUIC?
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Content-Type: multipart/alternative; boundary="00000000000070e70b059dc665b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/u2KccvzVIawhcX8ZaEbTfT4WmII>
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: Tue, 04 Feb 2020 21:05:17 -0000

On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham <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