Re: [Doh] [Ext] DNS over HTTP/3?
Mukund Sivaraman <muks@mukund.org> Tue, 20 November 2018 11:31 UTC
Return-Path: <muks@mukund.org>
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 1B715130DFD for <doh@ietfa.amsl.com>; Tue, 20 Nov 2018 03:31:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 1vPTXieV6_NE for <doh@ietfa.amsl.com>; Tue, 20 Nov 2018 03:31:03 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E459B130DF1 for <doh@ietf.org>; Tue, 20 Nov 2018 03:31:02 -0800 (PST)
Received: from jurassic (unknown [210.18.173.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id F18B032C0F32; Tue, 20 Nov 2018 11:31:00 +0000 (UTC)
Date: Tue, 20 Nov 2018 17:00:56 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: bert hubert <bert.hubert@powerdns.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "doh@ietf.org" <doh@ietf.org>
Message-ID: <20181120113056.GA17221@jurassic>
References: <20181119100954.GA6704@server.ds9a.nl> <5BE15B68-1C61-4462-AE84-901E2CF0F9F9@icann.org> <20181119151209.GC11506@server.ds9a.nl> <AB63D041-DF03-4137-8B8D-18A79CDD4208@icann.org> <20181119160414.GA20821@server.ds9a.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181119160414.GA20821@server.ds9a.nl>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/WLFV_aA2GX97AqXCyNu1oEfuDg0>
Subject: Re: [Doh] [Ext] DNS over HTTP/3?
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: Tue, 20 Nov 2018 11:31:07 -0000
On Mon, Nov 19, 2018 at 05:04:14PM +0100, bert hubert wrote: > On Mon, Nov 19, 2018 at 03:39:16PM +0000, Paul Hoffman wrote: > > > It does around 2 DNS queries per HTTPS connection on average dnsdist-doh > > > keeps open an HTTP/2 connection for 10 seconds if it becomes idle. > > > > Thanks, that seems to be your problem. Can the dnsdist DoH server package > > be configured to have an idle timeout that is more representative of > > typical browser use, such as on the order of minutes? > > I have measured with timeout of 100 seconds and 300 seconds. In both cases, > the packets per query ratio drops to 12, from 22. This is still around 6 > times more than UDP, and I now carry around hundreds of additional > filedescriptors. But ok. This is not specifically about DoH, but I don't like the path DNS is taking. I don't like the general push to heavy protocols for DNS and have often commented about it on dprive and dnsop. DNS historically has been mostly a light-weight single-request single-response stateless protocol (TCP is used as a last resort vs. UDP that's used in preference). The addition of a privacy layer could add more weight, but we seem to be uninterested in exploring other stateless or low-state ideas, outside TLS and even QUIC. After the resolver work, the phase-2 introduction for resolver<->auth communications[1] started with TLS which seemed illogical to me. There must be empirical studies of consequences before protocols push through to RFC. People such as Sara Dickinson at Sinodun have been studying the performance and scalability of the privacy layer in DNS implementations which is very commendable. [1] https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01 Some people such as Brian Haberman have taken an initiative to gather requirements for resolver-auth privacy instead of jumping directly to design which is again commendable. dnsop and dprive should study this before pushing drafts to RFCs. What is the worst case on resource utilization, number of round-trips and number of packets to implement these layers? What could happen on average in practice? Large operators who plan ahead ask these questions. Can <implementation> handle TCP and DNS over TLS and DNS over HTTPS in a future world at rates similar to UDP now? I can picture the overhead for UDP and TCP, but it is a lot more complicated with the extra layers. It's not ok to assume and hand-wave away that optimizations such as TCP fastopen will avoid roundtrips and make up for performance. A TCP client may not have a cookie for the average nameserver case for the SYN except if it is for a "CDN/cloud" concentrated nameserver. I'm afraid these things will encourage more concentration for performance vs. keeping the internet distributed. Facilities such as TCP fastopen are also experimental and we should not rely on them until more time has passed. Server-side support for it is still turned off by default in current versions of popular Linux distributions (a system-level setting that can't be enabled by applications such as a nameserver). Resolvers such as BIND have not yet implemented TCP fastopen for making connections. fastopen also suggests downgrades globally to regular 3-way TCP handshake from fastopen when there is a flood, which is not an attack in the regular sense, but loses the fastopen optimization if DNS relies on it to perform satisfactorily. DNS is not a special protocol, but it is at the head of every internet activity. It has to perform well and scale well. The chairs should encourage studies into stateless methods to do privacy with low roundtrip overhead. Other protocols pay heed to stateless methods, e.g., DNS COOKIE is stateless on the server side. TCP fastopen is also stateless on the server side. There is unexpected advice in RFCs too. When TCP fastopen is available for the DNS over TCP case, it seems better for the TCP connection to be closed than it be kept open because the open connection would revert to slow-start phase after an idle period with typical DNS query traffic patterns (unlike replies to a browser's HTTP requests that are typically much larger and more in sequence) unless it is continually active. In a greedy world, closing idle connections is something that authoritative servers would prefer to do to get rid of state - resolvers can't rely on having long-lived connections. This has become a rant but I'm unhappy about the process that is pushing new DNS features without sufficient evaluation. Modifying the transport of DNS without studies may affect performance and scalability that we may come to regret. Mukund
- [Doh] DNS over HTTP/3? bert hubert
- Re: [Doh] DNS over HTTP/3? Ralf Weber
- Re: [Doh] [Ext] DNS over HTTP/3? Paul Hoffman
- Re: [Doh] DNS over HTTP/3? Daniel Stenberg
- Re: [Doh] [Ext] DNS over HTTP/3? bert hubert
- Re: [Doh] [Ext] DNS over HTTP/3? Paul Hoffman
- Re: [Doh] [Ext] DNS over HTTP/3? bert hubert
- Re: [Doh] [Ext] DNS over HTTP/3? Ask Bjørn Hansen
- Re: [Doh] [Ext] DNS over HTTP/3? Ted Lemon
- Re: [Doh] [Ext] DNS over HTTP/3? bert hubert
- Re: [Doh] [Ext] DNS over HTTP/3? Daniel Stenberg
- Re: [Doh] [Ext] DNS over HTTP/3? Mukund Sivaraman
- Re: [Doh] DNS over HTTP/3? Az Mankin