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

Paul Vixie <paul@redbarn.org> Thu, 22 March 2018 17:02 UTC

Return-Path: <paul@redbarn.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 69447126D85; Thu, 22 Mar 2018 10:02:10 -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 xCrBaqrCx1Lt; Thu, 22 Mar 2018 10:02:07 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915A3126CF6; Thu, 22 Mar 2018 10:02:07 -0700 (PDT)
Received: from [10.8.2.102] (185.173.180.112.mixvoip.solutions [185.173.180.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9F5727594C; Thu, 22 Mar 2018 17:02:06 +0000 (UTC)
Message-ID: <5AB3E18A.1070109@redbarn.org>
Date: Thu, 22 Mar 2018 10:02:02 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: Dave Lawrence <tale@dd.org>
CC: dnsop <dnsop@ietf.org>, doh@ietf.org
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> <23219.56569.2064.711002@gro.dd.org>
In-Reply-To: <23219.56569.2064.711002@gro.dd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4BCyMk-AxuE_y0wB_C5N7P2cdWo>
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 17:02:10 -0000


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

nor i. apparently there were only worse choices, in the eyes of http folks.

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

yes.

   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?

i had originally proposed an http query header to inform the far end as 
to what transport the near end had received the question on. this was 
seen as "not http-friendly". thus we have the proposal you now see.

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

this is not a service, it's a proxy. that is, the far end should not 
start with udp (which is the usual dns initiator thing to do) and then 
make its own decision of whether to retry with tcp (for example on 
TC=1). the near end may already have tried udp and got TC=1. or the near 
end may have its own reasons for wanting to try tcp first.

if we were specifying a transport to a servive, like the DOH draft does, 
then we would not care about this. but this is a firewall bypass tool, 
not a dns-via-http service. thus, the near side of the proxy has to tell 
the far end of the proxy how we heard the query, so that it can use the 
same transport when it regenerates it for us on the far end.


-- 
P Vixie