[Doh] AXFR as several messages Re: [Ext] DNS Camel thoughts: TC and message size

bert hubert <bert.hubert@powerdns.com> Fri, 08 June 2018 10:34 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 93C8F130E6E for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 03:34:01 -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 5Z4SC6vLg9Dg for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 03:34:00 -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 1E025130E5E for <doh@ietf.org>; Fri, 8 Jun 2018 03:33:59 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 0638D9FB55; Fri, 8 Jun 2018 10:33:56 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id E666DAC5B0A; Fri, 8 Jun 2018 12:33:55 +0200 (CEST)
Date: Fri, 8 Jun 2018 12:33:55 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: Ray Bellis <ray@bellis.me.uk>
Cc: doh@ietf.org
Message-ID: <20180608103355.GB19916@server.ds9a.nl>
References: <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org> <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> <4d37f79d-df25-7b23-eca3-fb9a69f0d1e2@bellis.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4d37f79d-df25-7b23-eca3-fb9a69f0d1e2@bellis.me.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/QbymPhtgqP0eglK_kBwqQ9Nm0jU>
Subject: [Doh] AXFR as several messages Re: [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: Fri, 08 Jun 2018 10:34:02 -0000

On Fri, Jun 08, 2018 at 11:27:17AM +0100, Ray Bellis wrote:
> I can allocate a buffer of 64kB, even on the stack, safe in the
> knowledge that it's "big enough".  It's a trivial amount of RAM by
> today's standards but it avoids a lot of dynamic buffer allocation
> and/or re-sizing.

Indeed. Another question is also, if 65kB is too small, what is a reasonable
limit, in other words, what can protocol users count on? Several megabytes?
I would expect people arguing for larger messages to come up with a
value they can defend. 

> I would be OK with special case treatment for AXFR in DOH, but *please*
> don't mess with the normal message size constraints for standard queries.

So interestingly enough, AXFR already consists of a series of DNS messages. A
DNS message does not actually need an envelope (as in TCP) since it knows
where it ends. 

So to do AXFR over DOH, simply return multiple DNS messages concatenated.

Interestingly this would make it very easy for existing authoritative
servers to support DOH for AXFR since this is exactly what they do already,
without the need for protocol action.

	Bert

(Oddly enough DNS over TCP could have been done without length fields, but
this was likely easier on the system calls.  )