[Doh] DNS Camel thoughts: TC and message size

bert hubert <bert.hubert@powerdns.com> Wed, 06 June 2018 09:32 UTC

Return-Path: <bert@hubertnet.nl>
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 2E849130EE4 for <doh@ietfa.amsl.com>; Wed, 6 Jun 2018 02:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-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 ufzOe8XPpLUw for <doh@ietfa.amsl.com>; Wed, 6 Jun 2018 02:32:18 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05D3130EDB for <doh@ietf.org>; Wed, 6 Jun 2018 02:32:17 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 491799FB55 for <doh@ietf.org>; Wed, 6 Jun 2018 09:32:14 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 7C360AC34A8; Wed, 6 Jun 2018 11:32:12 +0200 (CEST)
Date: Wed, 6 Jun 2018 11:32:12 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: doh@ietf.org
Message-ID: <20180606093212.GA23880@server.ds9a.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/fpJSGWI1YtHeTFvmrS7pvB7ZnDA>
Subject: [Doh] DNS Camel thoughts: TC and message size
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 06 Jun 2018 09:32:19 -0000

Dear WG,

Briefly, the idea behind the 'DNS Camel' is that DNS is already very
complicated and that every new draft/RFC that touches it makes it even more
complex.  A summary of these thoughts can be found on
https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
and was presented at IETF 101.

A key insight is that every new feature is guaranteed to interact with many
existing features. This leads to an eventual combinatoric explosion because
"everything has to think about everything". This is often unintentional and
only apparent after a draft has turned into an RFC.

Notably BGP and C++ have recently reached similar conclusions in https://mailarchive.ietf.org/arch/msg/idr/z0L79p9WJkv3F6GgJ8J5LtiCpIQ
and http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf 

Version -05 of the DOH draft introduced this small sentence:

	Also note that while [RFC1035] says "Messages carried by UDP are
	restricted to 512 bytes", that was later updated by [RFC6891], and
	this protocol allows DNS on-the-wire format payloads of any size.

This is of course a laudable '640KB ought to be enough for everyone'-effort
based on our current 64KB limit imposed by TCP envelope size. 

However, with this single sentence, almost every DNS parser in existence has
become obsolete or at least untested!

No DNS message larger than 64KB has ever been possible.  The offset pointers
within a message are 14 bits long.  The EDNS payload receive size is 16 bits
long.  The TCP envelope size is 16 bit.  People can be forgiven therefore
for assuming 65536 bytes is the absolute limit.

Implementors of DOH will now have to find "32 bit safe" DNS message
parsers/generators, which may be in short supply.  Implementors of DOH
proxies will have to standardise alternate means of talking to TCP
nameservers so they can retrieve DNS messages larger than 64KB.  In effect
this means you can't write DOH proxies that sit in front of 'bare' TCP/IP
nameservers.

Where previously 64KB was the absolute limit, and there was therefore little
need to discuss the semantics of the TC bit on a response sent over TCP,
this has now become a real possibility if authoritative servers ever start
offering DOH.

Incidentally, all of a sudden we now have a big thread on the meaning of TC
within DOH.

So, the DNS Camel has a suggestion. Specify that DNS messages carried over
DOH can be up to 65536 bytes large and note that truncation should be
handled as if the response was carried over TCP/53.

Effectively this means that a TC response over DOH is almost always useless,
but this is no loss of functionality since it did not work over TCP/IP
either. We've not made anything worse here.

And in general this is what I hope that DOH will restrict itself to: provide
access to the DNS protocol over HTTPS and not change DNS itself.

Because based on the lack of clamor for >64KB DNS responses, I can not see
consensus being reached for extending the core DNS protocol for a new
transport protocol.  

Or to put it more strongly, I will not be part of that consensus, and I
suspect, neither will many implementors who have better things to do
already, like for example spending time on implementing quality DOH servers.

    Bert