Thanks for Typo fix suggestion. I have some explanation inline to your questions
> 3.2. Header Fields > I am trying to understand why the recursive server would care whether the > original query was UDP or TCP? Would it be concerned about source address > spoofing? > If the stub resolver is talking http directly, without a proxy, should it > put 'tcp' in this field? That should be made clear. > If the proxy server is running on a loopback address, would it make sense > to say 'tcp' even if the actual request was 'udp', assuming that address > spoofing is the concern, and would not happen with a loopback? > As the draft says, the Proxy-DNS-Transport header field used in proxy configuration in scenario 2 which help make the proxy transparent to the UDP/TCP transport. The proxy can help to maintain all the features TCP brings including source address spoofing. If stub resolver is talking http directly, there is not such field. client/server proxy may located in different servers from stub client and the far-end recursive server. So client/server proxy server can speak udp or tcp with them. 3.3. Message Body > end of second paragraph > "In the > context of HTTP, there is content-length header filed [section 3.3.2 > in RFC 7230 [RFC7230]]in which the field-value is the same with two > bytes length field in DNS over TCP." > "filed" should be "field" > Also, are you saying that the two bytes DNS length field should not be > included in the http body? It is not clear to me, I think we should say > that explicitly. > Yes, you are right. I should make it clear how to deal with the two-byte length field for TCP DNS massage. Generally, there are two choices to handle this. One is using HTTP header to wrap DNS massage with the two-byte length field when client proxy receive TCP DNS packet. Another approach is contain DNS massage without the two-byte length field and recalculate it when server proxy compose a new TCP DNS query packet. Both two approaches can work, but client proxy and server proxy should use the same approach to speak to each other. In the implementation we use the latter one. Davey -- > Bob Harold > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
