IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Wed, 04 April 2018 17:30 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17D12D779 for <dnsop@ietfa.amsl.com>; Wed, 4 Apr 2018 10:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 35SiWQcaE62W for <dnsop@ietfa.amsl.com>; Wed, 4 Apr 2018 10:30:48 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F1812E049 for <dnsop@ietf.org>; Wed, 4 Apr 2018 10:30:48 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id u9so9898968qkk.11 for <dnsop@ietf.org>; Wed, 04 Apr 2018 10:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tkmWTuLjMd6OQ2pR0rkt2p2lK6k2NQNAgI7D+plf4eY=; b=zj2JXXzldfz7elWArbmhGKLxDETp0cnPKVopIl920WnN9u7EquG+8FFJVaNPt1llo7 lOW2JlMQxTsxqRIRUWm3VRFaZIeAu67m/+Ae2gigW6/17nTsyJdPiIfnHpM2Pu+fVWE6 tbnYcOohYe6uvuhRCXhPdf6uajOA/yaOMtjc2Jd+q0xq9btbR2i9s5aCitVyk+3r3gmj dcMgTX+owhFW9PFOOEC9NJAdk08N7GI8lGBGDWIxHjeLUtPis5/33Q80aMx8iWRj/fGg MzURQZdUvuJ5ByfhKMDdWqO3J4QZgON3X0iwPpNRoaHp8rpRHFpLuJ7DEGdjAfKWqmUy lRFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tkmWTuLjMd6OQ2pR0rkt2p2lK6k2NQNAgI7D+plf4eY=; b=GvXwlkj58QLEj2WS3onLhorzB41x1YWwFF2mXEI+6TAUnPLH6MLDbgBREyJdj2zP1n UkJz8dAk7E8fmgk3YW/X2+Gk3zgNzV10mwhmnECt5bY+5iu5lrnUju/Lv4it8uS6oKB5 C7Nr2X7prm+/C37HdFSJ2os+FTkM4/opC2f/8M8/LqNJZKyBcNCP77f4vmt87r1+gx0u 4nxfnRBSTQGbOugZTuQZ5BFZH4IbiLkk4Z3G/Xi6nvF6+tAEY2pb99gEBh1agstT6cOa SJfRRog52xIesA+sI2tviSRKsirCFAQQWVzDOSGct9H+Gjp+TRSXlS3xAwL5GC/4M1c0 f8yQ==
X-Gm-Message-State: ALQs6tBOwl3kMRxnn+LUW/dip3bPJJxvuH3Jsit2UBQY3N44GEIACCzu kBMfc7iXaebhP6legLz7+Y4d0A==
X-Google-Smtp-Source: AIpwx49R84fa/BGybUKlkiNPvUzuLiFNSdKQA8MVoQZtCAl7T8H1+4YkR472re2o1/RZJ0b7Kw3KFw==
X-Received: by 10.55.195.92 with SMTP id a89mr24610707qkj.33.1522863047699; Wed, 04 Apr 2018 10:30:47 -0700 (PDT)
Received: from [192.168.1.144] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j19sm4719387qtf.21.2018.04.04.10.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:30:47 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <7E0DD069-A6C4-473F-B51D-5902C7E96A5C@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A6637F7-6D8A-492D-B010-4F92E95A0595"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Wed, 04 Apr 2018 13:30:45 -0400
In-Reply-To: <5AC50A04.6030407@redbarn.org>
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org, doh@ietf.org
To: Paul Vixie <paul@redbarn.org>
References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.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> <5AC5006C.4050308@redbarn.org> <5307DF51-689E-41C3-AB4A-59611EAD4DA3@fugue.com> <5AC50A04.6030407@redbarn.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/c5UB7oKkpiBlsN36E7j32-KA2Pw>
Subject: Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2018 17:30:54 -0000

On Apr 4, 2018, at 1:23 PM, Paul Vixie <paul@redbarn.org> wrote:
> you've cut too much context. my answer was to "just truncate". your followup is about "which middlebox."

Here's what I was replying to:

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

So you've said that the client's experience will be influenced by middleboxes.   I'm trying to understand what the scenario is where this would happen.   Hence my diagram:

LAPTOP<----link a---->DNS-over-https-proxy<---link b--->Full Service Resolver<---internet--->Authoritative servers

That is, what is the problem you are trying to avoid that requires the proxy to transparently tunnel rather than simply answering the query?

v2.23.0 | Report a Bug | By Email