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

Paul Hoffman <paul.hoffman@icann.org> Tue, 05 June 2018 14:48 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 9CBBF1310BC for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:48:34 -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 zdBCd-MLSJp8 for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:48:33 -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 5D9691310A2 for <doh@ietf.org>; Tue, 5 Jun 2018 07:48:33 -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:48:31 -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:48:31 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Tony Finch <dot@dotat.at>
CC: "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Doh] [Ext] a tad confused on response sizes
Thread-Index: AQHT/Nf1Q8eIdA6YbUmlfXswbBzsLaRSNDGA
Date: Tue, 5 Jun 2018 14:48:30 +0000
Message-ID: <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org>
References: <20180605120510.GA29047@server.ds9a.nl> <CFEAAD6E-4F9D-4DB5-A362-21775D74F84A@icann.org> <alpine.DEB.2.11.1806051515510.1809@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.11.1806051515510.1809@grey.csi.cam.ac.uk>
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=_677AB471-185F-42E5-ABE5-B14CB9AF0819"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/SkFHTy6XTPvSuoEu_wCNNtC1tyk>
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:48:35 -0000

On Jun 5, 2018, at 7:17 AM, Tony Finch <dot@dotat.at>; wrote:
> 
> Paul Hoffman <paul.hoffman@icann.org>; wrote:
>> On Jun 5, 2018, at 5:05 AM, bert hubert <bert.hubert@powerdns.com>; wrote:
>>> 
>>> 	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.
> 
> Thinking about this further, I think this is a bug, because a DoH client
> doesn't have any way to recover from TC.

A non-DOH DNS client that can't get a TCP connection to the resolver open can't recover either. Also note that the second sentence indicates that the TC bit could indicate that the resolver itself couldn't get the full response. 

In both cases, the TC bit means "here's the best I got". 'Twas always thus.

--Paul Hoffman