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

Paul Hoffman <paul.hoffman@icann.org> Tue, 05 June 2018 22:10 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 119B8130DEC for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 15:10:37 -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 Zr8F7y7u1oLB for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 15:10:36 -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 34DA5130DEB for <doh@ietf.org>; Tue, 5 Jun 2018 15:10:36 -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 15:10:34 -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 15:10:34 -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/Nf1Q8eIdA6YbUmlfXswbBzsLaRSNDGAgAAFXgCAAASIgIAADtUAgAAHioCAAAiOAIAACfOAgAAGO4CAAARtgIAAIO8AgAAdJAA=
Date: Tue, 05 Jun 2018 22:10:33 +0000
Message-ID: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@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> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <alpine.DEB.2.11.1806051604150.1809@grey.csi.cam.ac.uk> <20180605152355.6tlbeqvt7luklwjl@nic.fr> <alpine.DEB.2.11.1806051710290.1809@grey.csi.cam.ac.uk> <BYAPR19MB22489BE90FE768BCB13BD40B94660@BYAPR19MB2248.namprd19.prod.outlook.com> <alpine.DEB.2.11.1806051759430.1809@grey.csi.cam.ac.uk> <BYAPR19MB2248B0ADD763FF82E8C6C2E194660@BYAPR19MB2248.namprd19.prod.outlook.com> <alpine.DEB.2.11.1806051908040.1809@grey.csi.cam.ac.uk> <BYAPR19MB22489076D7E7A6780F78CCF094660@BYAPR19MB2248.namprd19.prod.outlook.com> <alpine.DEB.2.11.1806052125170.1809@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.11.1806052125170.1809@grey.csi.cam.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E18F11C7EB2A8645BFE2FEE860B6818B@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/2JPLdMa6eo01Ny9hs5K2u6_s7FA>
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 22:10:37 -0000

On Jun 5, 2018, at 1:26 PM, Tony Finch <dot@dotat.at> wrote:
> 
> Star Brilliant <m13253@hotmail.com> wrote:
>> 
>> In other words, a DoH with TC bit can happen, and that's a common error.
>> (Not as common as an unplugged network cable, but actually happens
>> really frequently on a busy recursion server.)
> 
> I would be interested to know of a query that produces a TC response over
> TCP.

Resolver 1 sends a query to a Resolver 2 (who allows forwarding) over TCP. Resolver 2 asks an authoritative,  gets a response with TC bit set on, tries on TCP, and gets a failure on TCP. Resolver 2 should send the partial answer it got over UDP to Resolver 1. That answer to Resolver 1 should have the TC bit set on, or not, depending on what you think that RFC 1035 "implies".

--Paul Hoffman