Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

Dave Lawrence <> Thu, 22 March 2018 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E7EB124B17; Thu, 22 Mar 2018 09:42:36 -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 aQhG3TBhV6ba; Thu, 22 Mar 2018 09:42:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EB631242F5; Thu, 22 Mar 2018 09:42:34 -0700 (PDT)
Received: by (Postfix, from userid 102) id 0521A395B6; Thu, 22 Mar 2018 12:42:33 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Thu, 22 Mar 2018 12:42:33 -0400
From: Dave Lawrence <>
To: dnsop <>,
In-Reply-To: <>
References: <> <> <> <>
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
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: Thu, 22 Mar 2018 16:42:36 -0000

Davey Song writes:
> To keep the transparency of DOH proxy, the proxy server should use
> the same transport as the proxy client receive queries from
> stub-resolver, transports patterns like UDP-DOH-UDP, and
> TCP-DOH-TCP. So the proxy client should signal the proxy server the
> initial transport recieve from stub-client.

I'm really not digging this as a good use of a media type, especially
when the draft says:

  "If proxy client receives the query via TCP, then it
   will carry a new media type defined in this document "application/
   dns-tcpwireformat" and speak DOH with proxy server with the same
   DNS query without the two-byte length field defined in DNS over

So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte
identical on the wire, and you're just using it as a signal for the
transport you want the DOH Proxy Server to use when talking to a
resolver (if indeed it is talking to separate resolver at all), is
that right?  If a transparent DOH proxy client is talking to a
co-operating DOH proxy server, shouldn't they have a better signaling
mechanism than that?  Is there any other media type that directs a
server on transport issues?

The use case also doesn't really address why it is important to
preserve the stub's udp-vs-tcp choice to its presumptive resolver, but
rather only refers only vaguely to the transparency issue.  It would
be nice to have a clearer statement of what's driving this proposal.