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

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 05 June 2018 16:43 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 6D21B13110C for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 09:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=ihYP9V+n; dkim=pass (1024-bit key) header.d=yitter.info header.b=UQuBbUUl
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 XqP8VsoChXdK for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 09:43:00 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31043126CB6 for <doh@ietf.org>; Tue, 5 Jun 2018 09:43:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 96E4BBDEF9 for <doh@ietf.org>; Tue, 5 Jun 2018 16:42:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528216949; bh=/Uz/dbjn+tm+WUKkXC2VYEfRnBjbQdkxu6PwRASTWHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ihYP9V+n1QM7zNYmFsVFFUKxKBFddJ/9QxTl70+hd8pvY36gnlYxgodYM3qBoHMPb xmIsIFevVVw/c31A74MBuFZ4y+gKM7XoasRL9aeI01SyZ6KYwOWggZMlreKCAY0bY+ knzwiSNEZKOU7KeVnIyCM0H/fhNe9WiPPi2MYiLY=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0nbdP6Rz2Eb for <doh@ietf.org>; Tue, 5 Jun 2018 16:42:28 +0000 (UTC)
Date: Tue, 5 Jun 2018 12:42:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528216948; bh=/Uz/dbjn+tm+WUKkXC2VYEfRnBjbQdkxu6PwRASTWHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UQuBbUUlAJYCfrgISxBkZ4lrdhwUA2CRKNrXZvho6eL2dJb7fG8fTbdqqFemlBKw2 vX3DffiIzC/yeG+KMAAASSBy4nQuxNfVCyaFBCdn8rl+DYCCViUzZEruZYvDOHdBLE zjmRysKMvpjEpKMvoSsR9mpIWOdL3KggNuSzHAwA=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180605164226.GN3011@mx4.yitter.info>
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> <20180605151336.3rgte7rbnghvnekq@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180605151336.3rgte7rbnghvnekq@nic.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/G9utG7WQZuBu8vTe_EFZVCOkq7o>
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 16:43:02 -0000

On Tue, Jun 05, 2018 at 05:13:36PM +0200, Stephane Bortzmeyer wrote:
> Clearly defined, but certainly not implemented
> everywhere. <vague>Many</vague> resolvers cannot retry over TCP.

Oh, for sure.  But I'm not trying to fault any document for developers
not implementing things :)  I'm just worried that this document
doesn't actually tell anyone what to do if they get such a bit, or if
it does I don't understand it.  (This could well be a failing in me,
please let me emphasise.)

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

I wonder whether the TC should be an indicator that the upstream
resolution process got a truncated response and was unable to fetch a
response that was not truncated.  In such a case, the DNS API client
can do whatever it would do in such cases otherwise.  (Some resolvers
in that case throw some kind of error, whereas others will happily
give you the truncated response and let you attempt to go ahead even
if you may well have poison, &c &c.)  I guess I don't have strong
feelings about the right answer, but I want the handling to be clear.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com