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

Paul Vixie <> Wed, 04 April 2018 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A97E412D775; Wed, 4 Apr 2018 11:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1LWIqPc7IJWZ; Wed, 4 Apr 2018 11:35:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE60E126C0F; Wed, 4 Apr 2018 11:35:41 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 915E37594C; Wed, 4 Apr 2018 18:35:40 +0000 (UTC)
Message-ID: <>
Date: Wed, 04 Apr 2018 11:35:24 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <>
CC: Ray Bellis <>,,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Apr 2018 18:35:43 -0000

Ted Lemon wrote:
> On Apr 4, 2018, at 1:23 PM, Paul Vixie <
> <>> 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 intended this to be heard as "will otherwise be influenced by 

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

the proxy is transparent. from

> The proxy service does not interpret the DNS query or response in any
> way. It could be DNS, EDNS, or something not yet invented at the time
> of this writing. The only requirement is that each request message
> solicits exactly one response message. If anything at all goes wrong
> with the proxy service, the stub client will hear a DNS SERVFAIL
> response.

i intend that the endpoints (who are real dns speakers and listeners) be 
able to evolve, or never evolve, according to their own drumbeats.

the real middlebox that's otherwise in the way is in my hotel room or 
coffee shop, and knows that udp/53 is a service address, and 
policy-routes my dns traffic to its own agent, which thinks it knows 
what DNS has to look like, and can't handle modern (1999-era) extensions 
like EDNS.

by putting these messages inside https (a virtual high fidelity middle 
box), i make them invisible to the hotel's physical low fidelity middle 
box. and by respecting the originator's transport choice, i remain 
transparent to its strategy to use edns-512, edns-1280, tcp, dns, and so 
on, in whatever order it wants to do.

could this be done with a resolver using non-proxy DOH as a transport to 
its forwarder? sure. but that puts semantic intelligence in the middle, 
which will introduce configuration, logging, monitoring, diagnosis, 
upgrade, and patching costs. i don't want those here.

P Vixie