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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 05 June 2018 15:13 UTC

Return-Path: <bortzmeyer@nic.fr>
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 E73001310DF for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 08:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 RkEPK-rmNkOj for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 08:13:39 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 84BEF131104 for <doh@ietf.org>; Tue, 5 Jun 2018 08:13:39 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D27FC2800F3; Tue, 5 Jun 2018 17:13:36 +0200 (CEST)
Received: by mx4.nic.fr (Postfix, from userid 500) id CCB592806CC; Tue, 5 Jun 2018 17:13:36 +0200 (CEST)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id C52BC2800F3; Tue, 5 Jun 2018 17:13:36 +0200 (CEST)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C22AA6424E40; Tue, 5 Jun 2018 17:13:36 +0200 (CEST)
Received: by b12.nic.fr (Postfix, from userid 1000) id B2481401BD; Tue, 5 Jun 2018 17:13:36 +0200 (CEST)
Date: Tue, 5 Jun 2018 17:13:36 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: doh@ietf.org
Message-ID: <20180605151336.3rgte7rbnghvnekq@nic.fr>
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> <20180605145029.GI3011@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180605145029.GI3011@mx4.yitter.info>
X-Operating-System: Debian GNU/Linux 9.4
X-Kernel: Linux 4.9.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000009, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.6.5.150316
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/d-OI9TxVs0TzbBebQ4ZwU-HTzb4>
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 15:13:45 -0000

On Tue, Jun 05, 2018 at 10:50:29AM -0400,
 Andrew Sullivan <ajs@anvilwalrusden.com>; wrote 
 a message of 17 lines which said:

> Except that in DNS there's a clearly defined path for what to do
> next,

Clearly defined, but certainly not implemented
everywhere. <vague>Many</vague> resolvers cannot retry over TCP.

(At this time, 'DNSKEY renater.fr' cannot be retrieved with a typical
EDNS buffer size. Try it.)

> whereas I am equally mystified what a DNS API client is supposed to
> do if it receives such a bit.

The way I understand it, it is a local decision by the client. Give in
for this data, or choose a better DoH server. I think that a DoH
server returning truncated answers is legal (RFC-compliant) but bad
and, as a client, I would prefer to switch to another one.

Practically speaking, for the RFC, what do you suggest? Forbidding TC?
Then, what would the client do if it still receives one? (The point of
DoH is to use DNS wire format, so a client has to be ready for
anything which is legal DNS.)