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

Ray Bellis <> Wed, 04 April 2018 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 266AA127601; Wed, 4 Apr 2018 07:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I3Z5bVXtcVeG; Wed, 4 Apr 2018 07:22:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0A7F12025C; Wed, 4 Apr 2018 07:22:02 -0700 (PDT)
Received: from ([]:55900 helo=rays-mbp.local) by ([]:465) with esmtpsa ( (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1f3jIV-0005rz-Ab (Exim 4.72) (return-path <>); Wed, 04 Apr 2018 15:21:59 +0100
To: Paul Vixie <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Ray Bellis <>
Message-ID: <>
Date: Wed, 04 Apr 2018 15:22:00 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
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:22:05 -0000

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.