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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
