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

[Davey Song <[e-mail]>]

On 3 April 2018 at 15:33, Martin Thomson <[e-mail]> wrote:

> This is intended to do what?  Indicate where the response came from?
> Why does the client care?

To keep the proxy (API client and server) transparent and bypass the
middlebox along the path. Without the indicate, the API server has no clue
what transport the client use (or would like to use. because there maybe
cases that client would like to test TCP capablity of the far end resolver,
I don't know). If no such indicate, It is either always using UDP or TCP by
default (or by local configuration). It can be done as an choice for
software implementation, but for protocol design IMHO, a indicate should be
introduced to provide that information.


> I assume that it doesn't apply to requests,
> or that would get into draft-bellis-dnsop-xpf territory.
>
That's is the quesion whether the indicate should be carried in HTTP layer
or DNS layer. If we use HTTP as a tranparent tunnel without any
modification on upper layer message, I would prefer to use a HTTP indicate.


> BTW, you really need to drop UDP from the media type name now.
> application/dns-udpwireformat;original_transport=tcp is a bit of a
> contradiction.


I agree.  I find no harm defining a media type "application/dns-wireformat"
for DOH.

Davey