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

[Bob Harold <[e-mail]>]

On Thu, Mar 22, 2018 at 12:42 PM, Dave Lawrence <[e-mail]> wrote:

> 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.
>
>
Unfortunately, the resolver needs to make decisions based on the original
transport, for example if the transport is TCP, it can send any size
response.  But if UDP, it needs to fit in a smaller size, and it often
sends less info in the response.  Likewise, session signalling,
anti-spoofing decisions, etc depend on the transport.

That brings up another question.  Would it also need to know the MTU of the
original connection, or any other info?  (Assuming EDNS is not used)  In
that case, a different media type is not enough, and we need to change the
format to add some 'header" info.

-- 
Bob Harold