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

[Paul Vixie <[e-mail]>]

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