IETF Logo Mail Archive

Re: [Doh] [DNSOP] [Ext] Re: 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: 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 C916412E878 for <doh@ietfa.amsl.com>; Wed, 4 Apr 2018 10:30:50 -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=ham 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 FtDnK91WORuu for <doh@ietfa.amsl.com>; Wed, 4 Apr 2018 10:30:48 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 A4FB612E04A for <doh@ietf.org>; Wed, 4 Apr 2018 10:30:48 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id o205so23341687qke.3 for <doh@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=j6Xi5N9icGhOJXKnYoTc+chNwHLYAwIV3GpcKCU6yMKsfi5IBSbCWcSJEmBasoGjWl ZeNv5MLwjjifTvhMr6Xhv5L18sswLGSDp9J/HldRAB0qkP3em7SWYjOZuDacKBkS4EmZ Uy6fGeD9m3KLGtxc6/ElW1YB/Lw5Ckmy/nwEROHjlsnrvVL4L8mTHupT4TCLpWKfwejg wbVtpBeB4kvb4p1ok0goYVPgJiMPwCneGNM6nrA/oHuLcg3zow21+fHYMoABNQvy81O+ 2xipnY66GN/cIwiaPuKFWaYj6V7jmfnKieo2fODtUswmdGokxq78ZeR3ZaEPHG3XpJzz G7NQ==
X-Gm-Message-State: ALQs6tCis4bdmsKDeJ04deRwla5ONzdGeV/9V5HJDCtRPs5iaAOyRMyf RlrSOqnNtXrJLm8KYzD+DLRh3A==
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/doh/slGAr6c5hU2td9Q-7xiXsDZM5SA>
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 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