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

Paul Vixie <> Wed, 04 April 2018 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D46F712D958; Wed, 4 Apr 2018 07:54:23 -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 pxYwdkA3jQld; Wed, 4 Apr 2018 07:54:22 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DD0412D94F; Wed, 4 Apr 2018 07:54:22 -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 323257594C; Wed, 4 Apr 2018 14:54:20 +0000 (UTC)
Message-ID: <>
Date: Wed, 04 Apr 2018 07:54:04 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: 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 14:54:24 -0000

ray, i won't engage on the question, should i want to do this. the 
working group mantra is interoperability -- as in, if you want to do 
this, here's an interoperable way. i'm not asking that the working group 
ratify the intent, or recommend the method. (as went ECS.)

the proxy is transparent. we list it in resolv.conf or as a forwarder. 
it regenerates the queries on the far side. it has to differentiate 
between tcp and udp because the unmodified client is making strategy 
decisions and implementing those using that transport choice.

this is not a service. DOH is a service. this is a proxy, which i would 
like to have be interoperable. please don't ask me to change what i want 
to build; that would be out-of-scope.



Ray Bellis wrote:
> On 04/04/2018 13:20, Paul Vixie wrote:
>> tcp and udp are the two ways a query might have reached the
>> initiating proxy, and that distinction is the only thing the
>> responding proxy needs to know.
> I disagree, I don't think that transport protocols should continue to be
> used as things that should be used for policy decisions.
> Per my previous message, they were a suitable proxy (no pun intended)
> for "this came from an unspoofable address", or "this channel can handle
> large responses" but there are other ways to achieve that now that
> aren't strictly transport.
> For example, presence of EDNS cookies satisfies the "unspoofable
> address" and therefore would permit RRL to be skipped for that client,
> but "UDP with Cookies" isn't a transport.
> [I appreciate that this isn't the best example because that cookie
> *might* get all the way through to the backend server anyway.  But it
> also might not].
>> if DOH becomes a standard transport, then we could add that
>> identifier as well -- but i don't think a client capable of DOH is
>> going to be using this particular proxy method.
> We already have DNS-over-TLS, DNS-over-DTLS, and folks are working on
> DNS-over-QUIC too.  None of those are true "transports", but server
> operators may wish to make policy decisions based on the resulting
> meta-properties of them.
> Ray
> _______________________________________________
> DNSOP mailing list

P Vixie