Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

Mukund Sivaraman <muks@mukund.org> Tue, 20 November 2018 11:37 UTC

Return-Path: <muks@mukund.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E695F130DFA for <dns-privacy@ietfa.amsl.com>; Tue, 20 Nov 2018 03:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.414
X-Spam-Level:
X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 TWF9W1dP2HlL for <dns-privacy@ietfa.amsl.com>; Tue, 20 Nov 2018 03:37:21 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 80046130DFB for <dns-privacy@ietf.org>; Tue, 20 Nov 2018 03:37:21 -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 45FBF32C0F32; Tue, 20 Nov 2018 11:37:20 +0000 (UTC)
Date: Tue, 20 Nov 2018 17:07:17 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: dns-privacy@ietf.org
Message-ID: <20181120113717.GA17927@jurassic>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/hfWTmqyrHB2CjrWGW73GBUdUmh0>
Subject: Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2018 11:37:24 -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