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
- Re: [Doh] [Ext] a tad confused on response sizes Star Brilliant
- Re: [Doh] [Ext] a tad confused on response sizes Andrew Sullivan
- Re: [Doh] [Ext] a tad confused on response sizes Patrick McManus
- Re: [Doh] [Ext] a tad confused on response sizes Massimiliano Fantuzzi
- Re: [Doh] [Ext] a tad confused on response sizes Ray Bellis
- [Doh] a tad confused on response sizes bert hubert
- Re: [Doh] a tad confused on response sizes Dave Lawrence
- Re: [Doh] [Ext] a tad confused on response sizes Paul Hoffman
- Re: [Doh] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Paul Hoffman
- Re: [Doh] [Ext] a tad confused on response sizes Andrew Sullivan
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Stephane Bortzmeyer
- Re: [Doh] [Ext] a tad confused on response sizes Stephane Bortzmeyer
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Andrew Sullivan
- Re: [Doh] [Ext] a tad confused on response sizes Star Brilliant
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Paul Hoffman
- Re: [Doh] [Ext] a tad confused on response sizes Dave Lawrence
- Re: [Doh] [Ext] a tad confused on response sizes Dave Lawrence
- Re: [Doh] [Ext] a tad confused on response sizes Star Brilliant
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Star Brilliant
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch
- Re: [Doh] [Ext] a tad confused on response sizes Paul Hoffman
- Re: [Doh] [Ext] a tad confused on response sizes Andrew Sullivan
- Re: [Doh] [Ext] a tad confused on response sizes Tony Finch