[Doh] a tad confused on response sizes

bert hubert <bert.hubert@powerdns.com> Tue, 05 June 2018 12:05 UTC

Return-Path: <bert@hubertnet.nl>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 53E42130FF6 for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 05:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vskuc4kDv6UR for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 05:05:25 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D3B131001 for <doh@ietf.org>; Tue, 5 Jun 2018 05:05:20 -0700 (PDT)
Received: from server.ds9a.nl (unknown []) by xs.powerdns.com (Postfix) with ESMTPS id B1CD59FB55 for <doh@ietf.org>; Tue, 5 Jun 2018 12:05:10 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 49713AC5B02; Tue, 5 Jun 2018 14:05:10 +0200 (CEST)
Date: Tue, 5 Jun 2018 14:05:10 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: doh@ietf.org
Message-ID: <20180605120510.GA29047@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/TSeUOFHHHUBtCvkPj0neE4m5cVU>
Subject: [Doh] a tad confused on response sizes
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: Tue, 05 Jun 2018 12:05:28 -0000

Dear DOH-people,

As I'm implementing DOH in dnsdist (expect something you can try later this
week), I am a bit confused.

The question is what maximum response size I should send in the absence of
an EDNS buffer size.  So let's say a query comes in without EDNS for
www.whitehouse.gov, but the answer exceeds 512 bytes.  Should I truncate?

I have read the draft and previous discussion, which has led to:

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

This is not explicit on what an implementation should do, only what the
protocol could support. Some further text:

	A DNS API server is allowed to answer queries with any valid DNS
	response.  For example, a valid DNS response might have the TC
	(truncation) bit set in the DNS header to indicate that the server
	was not able to retrieve a full answer for the query but is
	providing the best answer it could get.  A DNS API server can reply
	to queries with an HTTP error for queries that it cannot fulfill. 
	In this same example, a DNS API server could use an HTTP error
	instead of a non- error response that has the TC bit set.

This seems says sending a TC response is some kind of error, which implies
a DNS API server should be willing to send 65 kilobyte answers.

I think for the new usecases, this would be a fine default. However, there
might be UDP-to-DOH bridges which would then need to put explicit EDNS
buffersize of 512 in there if they get non-EDNS adorned UDP queries.

If the '65 kilobyte' interpretation is correct, I can supply text that will
hopefully make this explicit and unconfuse future implementers.