Re: [Doh] [Ext] a tad confused on response sizes

Paul Hoffman <paul.hoffman@icann.org> Tue, 05 June 2018 14:13 UTC

Return-Path: <paul.hoffman@icann.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 39ED013107D for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=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 ECD9jEp4EuyJ for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:13:04 -0700 (PDT)
Received: from out.west.pexch112.icann.org (unknown [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C246F131055 for <doh@ietf.org>; Tue, 5 Jun 2018 07:13:04 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Jun 2018 07:13:02 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Tue, 5 Jun 2018 07:13:02 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: bert hubert <bert.hubert@powerdns.com>
CC: "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Ext] [Doh] a tad confused on response sizes
Thread-Index: AQHT/MWCHKfSaHDR5060bxLSfOCW76RSKm2A
Date: Tue, 05 Jun 2018 14:13:02 +0000
Message-ID: <CFEAAD6E-4F9D-4DB5-A362-21775D74F84A@icann.org>
References: <20180605120510.GA29047@server.ds9a.nl>
In-Reply-To: <20180605120510.GA29047@server.ds9a.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_CB4ABEEA-5066-4A5C-8B19-97F2535D4C62"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Uy7GobdDMhvzQnhQyrzc0Qs1XzY>
Subject: Re: [Doh] [Ext] 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 14:13:06 -0000

On Jun 5, 2018, at 5:05 AM, bert hubert <bert.hubert@powerdns.com> wrote:
> 
> 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

Not at all. The first sentence is quite explicit. 

> , which implies
> a DNS API server should be willing to send 65 kilobyte answers.

...if it wants to, yes.

> 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.

Bridges and proxies and gateways, for any protocol, always have to make these kinds of decisions. 

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

Sure, please do.

--Paul Hoffman