Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

Mukund Sivaraman <muks@mukund.org> Sat, 09 June 2018 08:19 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 444BB130E1C for <doh@ietfa.amsl.com>; Sat, 9 Jun 2018 01:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Uvzz8u7Ai1Vc for <doh@ietfa.amsl.com>; Sat, 9 Jun 2018 01:19:04 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59812777C for <doh@ietf.org>; Sat, 9 Jun 2018 01:19:03 -0700 (PDT)
Received: from jurassic (unknown [14.194.233.101]) (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 DAE6C32C09D5; Sat, 9 Jun 2018 08:18:59 +0000 (UTC)
Date: Sat, 9 Jun 2018 13:48:52 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Dave Lawrence <tale@dd.org>
Cc: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= <olafur@cloudflare.com>, Mark Nottingham <mnot@mnot.net>, DoH WG <doh@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>, bert hubert <bert.hubert@powerdns.com>
Message-ID: <20180609081852.GA21347@jurassic>
References: <CAOdDvNq9g3ghbg9fkfhP+ZA4-6E5oDNFCGo6NN9bydqUX76cLA@mail.gmail.com> <20180607093647.GB32326@server.ds9a.nl> <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com> <23321.27027.73356.94056@gro.dd.org> <CAOdDvNr=kLHPCtCHRx4=rpA1oDogQqdAJ0nR156BWABiFP_bzA@mail.gmail.com> <20180607215851.GA32738@server.ds9a.nl> <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <CAN6NTqxA4PcrtS_3umwGERLt9WPoX4p0a0u8pL-O2=CKKTBfyA@mail.gmail.com> <23322.62892.251560.128565@gro.dd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <23322.62892.251560.128565@gro.dd.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/HSTvkb41abPWRgnbTRfNlNADhNk>
Subject: Re: [Doh] [Ext] 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: Sat, 09 Jun 2018 08:19:07 -0000

On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:
> Any software that is taking a DoH answer from an HTTPS channel is
> brand new software, not some legacy problem that we have to worry
> about.  If it imposes size limits before passing it on to whatever
> legacy code it wants to pass it on to, so be it.  The new software
> shouldn't be just blindly passing whatever data it gets into some
> legacy parser anyway, especially if the draft comes with an
> admonishment to be wary of that very thing.

Dave, I don't understand all the ways DoH will be used yet.

I have concerns about use of messages that come via this transport into
traditional DNS software [let's not call it legacy yet ;)].

There are current implementations that will parse a single message as a
"whole" in memory (i.e., not as a stream, in parts). With a 64k message
limit, there is an upper limit on derived objects from a single message.
Such code will have to be reviewed and rewritten when messages are
several megabytes or even gigabytes in size (such as a whole AXFR).

I understand that the >64kB message sizes need not apply to traditional
DNS software, but if we're retrofitting support for DoH into such
products, programmers are going to try to re-use a lot of the existing
code. This code is written with assumptions for traditional DNS, and it
may be very hard to do this based on the design.

On retrofitting, I'll give you an example - take pipelining (and out of
order processing) of queries over TCP. It is a *simple* concept to
describe, requiring not more than a page of text.  But if you wanted to
fit it into existing designs of resolvers (their client-side to auth
code) and authoritative servers, it takes a large amount of effort due
to the design. E.g., I know of a popular resolver that even now doesn't
implement pipelining completely.

Sometimes the benefits outweigh the effort, but as you say for the
opposing opinion, we should not hand wave it in as the effort has a
cost.

A DoH intermediate may not be able to split up a single large message
into multiple pieces, esp. when things like TSIG are involved, e.g., for
a large single AXFR message. It may also not be able to combine several
small ones into a large message. Do you envision such a large-message
AXFR to travel exclusively over DoH?

I'm all for a new protocol if the goal is to not worry about backwards
compatibility and work on something for the current age. Is this the
goal? If so, why even bother with the suboptimal DNS message format?

		Mukund