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

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 06 June 2018 06:24 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 4FA7B130EB3 for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 23:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-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=k4WHIX/Y; dkim=pass (1024-bit key) header.d=yitter.info header.b=E+JWFudf
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 Y1mMhErIrCli for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 23:24:28 -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 D02E1130EAC for <doh@ietf.org>; Tue, 5 Jun 2018 23:24:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id CBB32BDEF9 for <doh@ietf.org>; Wed, 6 Jun 2018 06:23:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528266235; bh=3kjn+73e1JQR3sySOhAwJyL9Wi6315TB1W6+sTHcm4E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=k4WHIX/Y8hAKqO0PzW0HwxLMe9fxMKZ7rV5GTDMlRGqBG2xnY1fv8sn/XfqrLH2Sf m88DZKOOn7ImH8S1jo/luyxxNYb0pmGIl/SLeOOc0pl/XYNRyAbLPDOzKYZb2qbLuA 6hYVFkjhXggCXXVFrYfN7hfUgRIqXG4aFFJSi2Kk=
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 pS6Xf394_B3w for <doh@ietf.org>; Wed, 6 Jun 2018 06:23:54 +0000 (UTC)
Date: Wed, 06 Jun 2018 02:23:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528266234; bh=3kjn+73e1JQR3sySOhAwJyL9Wi6315TB1W6+sTHcm4E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=E+JWFudfg8u7HrR+2NcEuOC64MZID6qz23c/T0W1qQ2hcLF/DsPvw4azwy1o8+/2h KqrQRMpCg7YcHZ+fc5iXdbdbAVbBhc+1GwAUPaty3KGvk6P0+sk0zytS2pX2xfyKpk y2A2hNEYV+dRK+xYHa7Zt7TzRysYOLxTpdiS43n4=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180606062352.GD3011@mx4.yitter.info>
References: <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> <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> <BYAPR19MB2248C54302A11BB5967F529994650@BYAPR19MB2248.namprd19.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BYAPR19MB2248C54302A11BB5967F529994650@BYAPR19MB2248.namprd19.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/wiOQERQ0XmBTT6iGK_Rb8wYwpF8>
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: Wed, 06 Jun 2018 06:24:31 -0000

Dear colleagues,

I gather our colleague Star Brilliant has given up on this thread, but
I think there is still an issue here.

On Wed, Jun 06, 2018 at 04:37:21AM +0000, Star Brilliant wrote:

> RFC 2181 defines what a DNS server and a DNS client should do, *not a DoH server or client*.

I think what Tony has been saying, and certainly what I have attempted
to say, is that this sort of dismissal of ordinary DNS assumptions is
just not helpful, because some portion of the audience of this
document will be people coming at HTTP(S) from a DNS background.
They're going to import DNS assumptions, and if we haven't dealt with
them in the document we'll get less-interoperable implementations.

The document as near as I can tell does a lot of work to align nicely
with HTTP "normal stuff".  But I think it ought to be a serious
problem that people with fairly deep expertise in DNS implementation
and deployment keep asking pointed questions.  I don't think anyone
asking these questions is attempting to slow progress or prevent
deployment (people may say what they will of me, but neither Bert nor
Sara nor Tony are, in my books, part of the "get off my lawn" crowd).
It's just that there are well-understood sharp corners in the DNS, and
people who are looking at the current I-D from the point of view of
general purpose resolution are trying to figure out, "How does that
$familiar_thing work?" and coming up with no answer.

The WG can perfectly reasonably conclude, "Yep, that part of DNS
resolution already sucks, and you DNS people ought to burn in hell."
But that needs to go in the document, not be something that people
have to infer.  There's already _way too much_ inference in how
name resolution on the Internet works, and I would like us to make
that better rather than worse.

So, I'd like to understand what the document ought to say about some
things.  In particular,

> A DoH server *never* touches the TC bit, it's the buggy upstream DNS server that sets the TC bit on a TCP connection. (It's their fault, not DoH's.)
> A DoH client *never* reads the TC bit, it just verbatim passes the response to the downstream DNS client. It's the downstream's responsibility to either drop or consume the response.

This is just a completely useless response, unless that is literally
placed into the document.  Because what it means to me is that any
TC-bit-containing DOH message is almost certainly garbage that needs
to be resolved via a different path, and it's therefore pretty hard
for me to see why this isn't just an error condition.  If someone (or
the document or ideally both) wants to explain why I'm wrong, that
would also be helpful.  But at the moment, I think I agree with Tony.
If there's a TC in a DOH message received by a DNS API client, that
client needs to be able to decide what to do.  _I_ think it's an
indication that DOH resolution has failed and the client needs to do
something else, but I can see arguments about two-sided systems
(effectively "full service DNS API servers") that might want to pass
on anyway.

> P.S. I'm not going to talk about this issue any more since I don't think the current specification is inappropriate. Also practice shows it is working..

I am pleased to observe that someone has surveyed the population of
all possible DOH resolution systems, and concluded that the current
text will ensure they'll all work.  I am sceptical of the result,
however, and would like another report from the possible worlds.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com