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

Tony Finch <dot@dotat.at> Tue, 05 June 2018 17:14 UTC

Return-Path: <dot@dotat.at>
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 F3C98131117 for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 10:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 YihWumk5GUyT for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 10:14:38 -0700 (PDT)
Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80B71277C8 for <doh@ietf.org>; Tue, 5 Jun 2018 10:14:38 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38668) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQFXY-0007uV-M2 (Exim 4.91) (return-path <dot@dotat.at>); Tue, 05 Jun 2018 18:14:36 +0100
Date: Tue, 5 Jun 2018 18:14:36 +0100
From: Tony Finch <dot@dotat.at>
To: Star Brilliant <m13253@hotmail.com>
cc: "doh@ietf.org" <doh@ietf.org>
In-Reply-To: <BYAPR19MB22489BE90FE768BCB13BD40B94660@BYAPR19MB2248.namprd19.prod.outlook.com>
Message-ID: <alpine.DEB.2.11.1806051759430.1809@grey.csi.cam.ac.uk>
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>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/8_35PEGGa1SeVF9QVBbk4nklKao>
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 17:14:40 -0000

Star Brilliant <m13253@hotmail.com>; wrote:
> Tony Finch <dot@dotat.at>; wrote:
> > Since https's permitted length is longer than a DNS message,
> > it is invalid for a DoH server to truncate.
>
> No, DoH server never truncates messages.
> It is the upstream server that truncates the message.

If a DoH server talks to an upstream resolver over a truncating transport,
the DoH server has to retry over a non-truncating transport.

> The fact is that there are TCP servers that do truncates messages.
> There are also servers that firewalls TCP by mistake so only UDP could pass.
> Some of them are even authoritative server that you have no other ways to bypass.

They are all broken and don't implement the protocol correctly.

> Yes, we know it is not RFC1035-compliant. But what can a DoH server do
> with this kind of malformed packet?
>
> 1) Ignore the TC bit and return the truncated answer to DoH client?
> 2) Take the TC bit and return the truncated answer to DoH client?
> 3) Return SERVFAIL and persuade users to give up your DoH service?

I think those are all reasonable. My DoH server just returns its
upstream's header verbatim. Its upstream resolver is responsible for
correct DNS semantics.

> You could do nothing but keep the TC bit. That is why DoH allows TC bit.

The point of this discussion is what the client is supposed to understand
by TC in a response. RFC 1035 implies that (over TCP) TC must not be set
by a server and must be ignored by a client. DoH should be the same.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
Biscay: Cyclonic 3 or 4. Slight. Thundery showers. Good, occasionally poor.