IETF Logo Mail Archive

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

Ted Hardie <ted.ietf@gmail.com> Wed, 05 February 2020 08:55 UTC

Return-Path: <ted.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 ED95912029C for <quic@ietfa.amsl.com>; Wed, 5 Feb 2020 00:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 fVFabnvRQYfL for <quic@ietfa.amsl.com>; Wed, 5 Feb 2020 00:55:52 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 D249B120271 for <quic@ietf.org>; Wed, 5 Feb 2020 00:55:52 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id j20so1240176otq.3 for <quic@ietf.org>; Wed, 05 Feb 2020 00:55:52 -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=PTPJE6w9PIlLME7oEwrifC4Rq/BU+MdlRet/QusavAY=; b=M8Km2Ti3MLm4WdJKREpM/fRCDhaPg4FMJTHDlNsRaI0TllVWattiUFw2nMb70Bz/KP IH5unY664l0dvoaaOhn4lYkI6l1KPUBprckpCZipKUshr1sFQAXuR2ZyUT647g8qZkxj g3PmaqeXIF8ISvzDz6QYm6EoilG7Qp2MJYkOhDphFc+WKzVPoQ0o5jwAEaRiPX2MAkpN e6KuTBHe/MLXqEwdZfRKJyxvyOZuXN70cxK5DXU3NIO6zrdbCv+ot5/EDOl+j4kfMbn9 pCi67Ea/aidCR20HlIxSh7ltw6EG6ojGziPhvioyDzDir5YbGEKucuyr4x0F7wMv7F2B aO+w==
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=PTPJE6w9PIlLME7oEwrifC4Rq/BU+MdlRet/QusavAY=; b=Xz/kTzr9F2mX7GHvAzamGvn0rx0r5eQRuHpdI80h/gIEAZKMGMzRRyD4pXYDkDXegY oU9BsxAUM+8JE+AvV4/8fSAppAU6+qRQvWMo3qG5XF2WXbO3Fk8QlM+q09WJxF0YmBH8 Q0CoQ0yvYTjJK4JauFUV/Ye/tygMIQ39x5wBsBq4og7xD6saQJB9lHP0E3o70tt48VOb tSuiqxVqaKmlaa+W5cyRbW3pmXZbzt4eusci6LX+B9B/QHHzv+4SJZlrJ7ntDye+NPrB 9+UlmTFInRThxwmmBvhG7X2wOFtINldWz6VlcAd6w7gzlcPFGZsJ9cqkwRka3Ngriap8 wWMg==
X-Gm-Message-State: APjAAAXOpMq+0WZ2ElnaK9vz9uBK5tug+F8DN25SpHqAp5t5riDXY9DL L8NDT+6Hoo4yRu+o+a7LPyobKc8QnkdGEY9jBXI=
X-Google-Smtp-Source: APXvYqy7o912j3yhiaKz3Ful+NPqh6E3QFeah1svifn/CxPfA6URjc+RY1swtQPF88MI16TYLU6PuAuvvtVbK0KCN8M=
X-Received: by 2002:a9d:6f0a:: with SMTP id n10mr26077574otq.54.1580892952147; Wed, 05 Feb 2020 00:55:52 -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>
In-Reply-To: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 05 Feb 2020 09:55:26 +0100
Message-ID: <CA+9kkMC_H0NTXCy+o+7MjH+RT0oB5UUQL0PiqKFVMiu9w2NExw@mail.gmail.com>
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: 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="000000000000d73b5a059dd052cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/PogtcXrfuzRkzrw9ywFnLOjM8ck>
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 08:55:56 -0000

Hi Tommy,

On Wed, Feb 5, 2020 at 1:17 AM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> 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.
>

I think the deployment path here is really for folks who were on DoT (or
considered DoT) but want to have the advantages of QUIC.  As such, I
support the DNS over QUIC work.  I believe it is actually easier for folks
who want consistent semantics from DNS over UDP-->DNS over (D)TLS-->DNS
over QUIC, with none of the HTTP semantics entering the equation.

regards,

Ted Hardie


> 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> 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