Re: [Doh] Authoritative DoT or DoH
Ted Hardie <ted.ietf@gmail.com> Fri, 15 March 2019 16:06 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F81129BBF for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 09:06:43 -0700 (PDT)
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_PASS=-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 lYVSKWc3Ehlg for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 09:06:40 -0700 (PDT)
Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 3FCCC1279E6 for <doh@ietf.org>; Fri, 15 Mar 2019 09:06:40 -0700 (PDT)
Received: by mail-io1-xd42.google.com with SMTP id v4so7659572ioj.5 for <doh@ietf.org>; Fri, 15 Mar 2019 09:06:40 -0700 (PDT)
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=tUTggQc4ce5olrwKcikdCigAWq6EfOkPXww8MgECOB4=; b=eaHwjovMG7aF/mIGY5Y3ITTdU4jOqIgT0ge60PqWmb7rKJPYkScOEHabDwFIF1YjpD fEY33EtRGpmzmU4fgcpzOsCP3mBRJBKha+uoVmUmUKbEA1jqM3BqcokuqFR8FP1aypTz DZxnnxnF2RepuF4YokxfmVseDP0vR07Pp2mO0hhvYdBWy3wagKb6nj+1Vf/7xDM+HkRD N+s6YLm+KRqq2xfxiE1qwR9pNCZ/n2Csza6KlUbRg/QI2Gdeinbj5hDbQqhLqLg+qK1V G/vuiPniCzMK47WZ5rtZJeFU/lvtfBePglazx8m+np6atMAYp6gqIIE0VeDcz+MdIs1m ZobA==
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=tUTggQc4ce5olrwKcikdCigAWq6EfOkPXww8MgECOB4=; b=UJgZhhY9YKDV5urc2gxKu6zovld/dkFVJvcv9pq1rlrhwxY0Bmn4/E6OVnov/aXTUY 20tIuy3vuI4DbZ66kKE04Iahk+kjqaiT2t4F13rCCD6wo/h5N2x7jWVg0Ccak/W6qsTK oPdjYBRDWZ3TUyNxgGUX5AYUkey4tXAHoq8P4cuRTbVio7UFlqo9VNNNznyW7ELrEcey pqGCZX1vL0yHegBNfQENTbuS/jwd4+jq+VGp6gtp3qPSPKE8/vws2VzCL4g9tlbeIoAh DLh3Zg1hCVFjenxBAdpJm97c8mtI0JB0fDYVA/rDJWBvTApeeUeeN2V935hjcAa6psmO sU4w==
X-Gm-Message-State: APjAAAU9lbk0r5B0TUSgi/Yrw2bfSLzdTdksvRon/nqmpk6a9iq3rK8e 0X2ryKRdYuUhLGbfve4Qeq0mv0xeF9YkRg3ZiK4=
X-Google-Smtp-Source: APXvYqwfj/2V8SGWLMvtg3HN2Aunw9vuY2mf1RoSVdOi5mtdsvbTKpR5LTsaho3V4UO38J1lxEdzM6TKneL7fhks9rc=
X-Received: by 2002:a5e:9b0e:: with SMTP id j14mr2807596iok.35.1552665999393; Fri, 15 Mar 2019 09:06:39 -0700 (PDT)
MIME-Version: 1.0
References: <C8284F2D-F46A-484E-A145-99C0D8ADBC58@verisign.com> <73eb005a-da34-41cb-a05d-1cb8268060d2@www.fastmail.com> <CAAedzxqFMe_tZkBbXSWjfAgajaO1v=sX6umzcpfv+OaaQKOn6g@mail.gmail.com> <2f18ea6a-89e7-418b-82cf-70a8af70e8c1@www.fastmail.com> <CAKcm_gPyE6DaWc4YrTO3_-dRrBpnZA2GUW9aK=Lse-7gM_U8Sg@mail.gmail.com>
In-Reply-To: <CAKcm_gPyE6DaWc4YrTO3_-dRrBpnZA2GUW9aK=Lse-7gM_U8Sg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 15 Mar 2019 09:06:13 -0700
Message-ID: <CA+9kkMCNSF_XYX85i=9jmGhhN7UaT+623K8bALPfMTsLHhMWgQ@mail.gmail.com>
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: Martin Thomson <mt@lowentropy.net>, DoH WG <doh@ietf.org>, Erik Kline <ek@loon.co>
Content-Type: multipart/alternative; boundary="00000000000059493705842439d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/JsRz0mXjuwz_6HOipN5GC_RDX7k>
Subject: Re: [Doh] Authoritative DoT or DoH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2019 16:06:44 -0000
Speaking about DNS over QUIC, not DNS over HTTP over QUIC, a comment in-line On Fri, Mar 15, 2019 at 7:56 AM Ian Swett <ianswett= 40google.com@dmarc.ietf.org> wrote: > For a DNS or DoH heavy workload, I'd expect QUIC CPU usage to be very > comparable to DoT or DoH over HTTP/2, but obviously crypto isn't free, so > it would be more expensive than plain DNS. > > For the client-to-recursive-resolver case, the big advantage is that the traffic bursts of queries can work well with both the multiplexing of QUIC and with 0-RTT. You can have a burst of queries each resolved on an independent stream without head of line blocking, then either a low-effort quiescent connection or 0-RTT resumption. For an authoritative server of a large flat zone (like a TLD), you could get a similar advantage by having the recursive resolvers talk to anycast instances which would be able to multiplex parallel queries or use 0-RTT to lower the latency of using the encrypted transport. For authoritative servers with deep hierarchies or low utilization, DNS over TLS seems a better fit, since they are less likely to need the multiplexing (and will get 0-RTT with TLS 1.3). regards, Ted > QUIC CPU really suffers when sending(and to a lesser extent receiving) > huge payloads. > > On Fri, Mar 15, 2019 at 7:04 AM Martin Thomson <mt@lowentropy.net> wrote: > >> DNS over QUIC (either directly, or as DoH with HTTP/3) will likely >> exacerbate load problems. QUIC isn't great about its CPU usage at the >> current time. That comes with some advantages, like sharing an encryption >> context for multiple requests without the head of line blocking inherent in >> HTTP/2, but it's unlikely to be a total slam dunk. >> >> On Fri, Mar 15, 2019, at 14:23, Erik Kline wrote: >> > And on account of the load management issues I would expect some folks >> > to prefer to try out DoQ (DNS over QUIC), does actually bring things >> > back around to DoH. >> > >> > On Thu, 14 Mar 2019 at 19:27, Martin Thomson <mt@lowentropy.net> wrote: >> > > There is far less reason to use DoH for connections to authoritative >> servers. DoT seems far more appropriate (than both DoH and the unencrypted >> variants). >> > > >> > > I expect there to be a lot of discussion about DoS (not DNS over >> SCTP, sadly) and load management in any such document. I don't see much of >> the stuff that has generated so much heat lately to be relevant in the >> authoritative context. >> > > >> > > On Fri, Mar 15, 2019, at 06:18, Henderson, Karl wrote: >> > > > >> > > > In the last couple of days there has been a lot of activity >> concerning >> > > > DNS over HTTPS (DoH) - Hoffman and Alibaba presentations at ICANN >> and >> > > > IETF drafts: >> > > > >> draft-reid-doh-operator/draft-livingood-doh-implementation-risks-issues/draft-betola-bcp-doh-clients. >> > > > >> > > > >> > > > These discussions have focused on DoH for client (typically web >> > > > browser) communication with recursive resolvers, and its >> comparisons >> > > > with DoT for this purpose. >> > > > >> > > > >> > > > Is there any compelling reason at this point to be considering DoH >> for >> > > > recursive resolver-to-authoritative name server communications? >> > > > >> > > > >> > > > As I noted at the DPRIVE interim meeting, the working group needs >> > > > empirical studies looking at performance and attack vectors for >> > > > authoritative DNS encryption. >> > > > >> > > > >> > > > Unless there are compelling reasons to consider Authoritative DoH, >> I >> > > > propose the working group focus its authoritative DNS encryption >> > > > assessments around Authoritative DoT. >> > > > >> > > > >> > > > In support, I am willing to co-author an Authoritative DoT >> operational >> > > > consideration draft in order to outline the operational challenges >> the >> > > > community needs to address - similar to the >> draft-reid-doh-operator >> > > > draft between client and recursive. >> > > > >> > > > >> > > > _______________________________________________ >> > > > Doh mailing list >> > > > Doh@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/doh >> > > > >> > > >> > > _______________________________________________ >> > > Doh mailing list >> > > Doh@ietf.org >> > > https://www.ietf.org/mailman/listinfo/doh >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh >
- [Doh] Authoritative DoT or DoH Henderson, Karl
- Re: [Doh] Authoritative DoT or DoH Martin Thomson
- Re: [Doh] Authoritative DoT or DoH Erik Kline
- Re: [Doh] Authoritative DoT or DoH Martin Thomson
- Re: [Doh] Authoritative DoT or DoH Ian Swett
- Re: [Doh] Authoritative DoT or DoH Ted Hardie