Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

Paul Vixie <paul@redbarn.org> Wed, 04 April 2018 16:42 UTC

Return-Path: <paul@redbarn.org>
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 31500126D3F; Wed, 4 Apr 2018 09:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tnBpXST7zDO3; Wed, 4 Apr 2018 09:42:23 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97D8129C5D; Wed, 4 Apr 2018 09:42:23 -0700 (PDT)
Received: from [10.0.5.44] (unknown [38.100.27.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 271267594C; Wed, 4 Apr 2018 16:42:23 +0000 (UTC)
Message-ID: <5AC5006C.4050308@redbarn.org>
Date: Wed, 04 Apr 2018 09:42:20 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org, doh@ietf.org
References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <CA+nkc8ANQh2wAr6==eNuM82mbD+E2ELzHGizdqF_sGdY-kkOqg@mail.gmail.com> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <CABkgnnX2jGY_JpVbqJuQdDVUyVzsuM_2CDg4nppfqQHZQm0F+w@mail.gmail.com> <CAAObRXKHhk51DxNt5uiYB0gunJ=DNde2j9FJSU=Ky2m4Q1UkhQ@mail.gmail.com> <CABkgnnVL0XaUDS-WzDGaN9-kLx9p3x1+UVuWhvx=Zyo5oRos+w@mail.gmail.com> <19BED07A-942E-4A46-93A6-09770083EFF9@icann.org> <CABkgnnX-=n-reO9yjA8a2pHAD+JtoS5wX1w-dXMnDFdt4HXu-g@mail.gmail.com> <23236.18671.182273.977633@gro.dd.org> <28199575-e2e2-6966-fe17-f678f9f397f3@bellis.me.uk> <5AC4C2F7.7050906@redbarn.org> <3630b151-9628-235e-a5b1-c838b777d9d2@bellis.me.uk> <5AC4E70C.7020003@redbarn.org> <A0A55AED-0CB2-478C-913A-DCA678FBAC33@fugue.com> <5AC4F11F.3050009@redbarn.org> <602DF02A-3A85-4B3B-9E11-F7A701BD25B5@fugue.com> <5AC4F3F5.6080408@redbarn.org> <C2CAFEF1-7A0B-496E-9AE0-7229E4B4062F@fugue.com>
In-Reply-To: <C2CAFEF1-7A0B-496E-9AE0-7229E4B4062F@fugue.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/ApWOiKu1fvngpOTUkCCi8nH1a3c>
Subject: Re: [Doh] [DNSOP] [Ext] Re: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
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, 04 Apr 2018 16:42:25 -0000


Ted Lemon wrote:
> On Apr 4, 2018, at 11:49 AM, Paul Vixie <paul@redbarn.org
> <mailto:paul@redbarn.org>> wrote:
>> this is a far thinner solution than a full-service resolver, which
>> would require local configuration and monitoring and so on, as well as
>> topology stability that can't be guaranteed.
>
> For your laptop use case, why wouldn't you just have the thing running
> on the laptop do truncation if the answer is too long?

that would be low fidelity. i need to run clients whose internet 
experience will not be influenced by middleboxes.

> I admit that this is more code, but it's not a lot more code, and
> what you're doing instead is pretty hacky.

feel free to try it out:

https://github.com/BII-Lab/DNSoverHTTP

or:

https://github.com/BII-Lab/DNSoverHTTPinGO

these are out of date with respect to the current draft, but each works. 
i would like to see a standard that they can conform to, so that i'm 
safe building a larger infrastructure.

> The fact that it's not required to implement doesn't mean that it
> doesn't contribute to the camel problem.

are we at the point where any of us can call anything we see no use for 
part of the camel problem? i'm hoping not, and so i'm going to ignore 
your statement here.

"if you want to do this, here's an interoperable method" is this group's 
meme. it's not "this is the best engineering solution we were able to 
create for the problem we are willing to admit you might have."

-- 
P Vixie