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

Dave Lawrence <tale@dd.org> Thu, 22 March 2018 16:42 UTC

Return-Path: <tale@dd.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7EB124B17; Thu, 22 Mar 2018 09:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQhG3TBhV6ba; Thu, 22 Mar 2018 09:42:34 -0700 (PDT)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB631242F5; Thu, 22 Mar 2018 09:42:34 -0700 (PDT)
Received: by gro.dd.org (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: <23219.56569.2064.711002@gro.dd.org>
Date: Thu, 22 Mar 2018 12:42:33 -0400
From: Dave Lawrence <tale@dd.org>
To: dnsop <dnsop@ietf.org>, doh@ietf.org
In-Reply-To: <CAAObRX+xF5SwVd3x3iXSWd-A0Kpr_ubbOJzn0yTrSk8pc+tm6Q@mail.gmail.com>
References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <CAAObRXLm3c-p9rZkn6H6tcEoh3-UT5JW06NXQ_FMyyr2NFMmyw@mail.gmail.com> <23219.33838.166003.614689@gro.dd.org> <CAAObRX+xF5SwVd3x3iXSWd-A0Kpr_ubbOJzn0yTrSk8pc+tm6Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Kdg3wGGy9IumhDmcnSewfRBJy54>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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
   TCP"

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.