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