Hi guys, Thanks for the comments and discussion. I catch up them after holidays :)
I reply in line and cc Paul's comments to DNSOP WG mailing list, so that we can continue to comment follow the same context in this mailing list. Best regards, Davey. On 30 April 2016 at 06:23, Paul Vixie <p...@redbarn.org> wrote: > > > Shane Kerr wrote: > >> specific semantics, such as the HTTP request method, specific >>>> request-target, HTTP-version, and HTTP header field, all of which >>>> have impact on interoperability as well as performance. >>>> >>>> In HTTP 1.1 specification section 3 in RFC 7230 [RFC7230], an HTTP >>>> message consists of three parts: start-line, header fields, and >>>> message body with an empty line between header fields and message >>>> body. The DNS over HTTP message also contains these parts. >>>> >>> Otherwise, it wouldn't be HTTP/1.1, right. FWIW, if you make this >>> requirement here, you wouldn't be able to use HTTP/2. >>> >> >> Of all your observations, this one is the trickiest. :( >> >> Right now the protocol is clearly based on HTTP/1.1, although we have >> an implementation that works fine with HTTP/2 since the Go HTTP library >> supports it (basically) transparently. >> >> Let me talk with my co-authors and see what they think! >> > > as a named co-author, i think the http version number is irrelevant, and > that we should not describe http/1.1 in our spec. that is, we should not > mention headers, lines, or bodies. those are syntactic elements meant to be > parsed to find semantic elements: request action, request headers, and > request body. (or similar.) how those elements are encoded is not important > to proxy-dns, nor to any other web-carried app. > > we should restate our specification in terms that are portable to http/2 > and every http protocol thereafter. the encoding of our blobs into http, > and the decoding of an http message into the blobgs we need, is an > implementation detail. > > The HTTP version is mentioned because the difference of http/1.1 and http/2 is relevant to DNS performance, if http is used as an alternative transport protocol. It is worthwhile to encourage people to use modern HTTP protocol. > - Note that choosing POST (not GET) as the request method for DNS >>>> wire-format over HTTP is mainly based on two reasons. One is that >>>> the protocol is designed using HTTP as a tunnel-like technology >>>> carrying data from one side to another, not a web service with >>>> RESTful framework. Another is that from the view of implementation >>>> some servers may ignore undefined entity-body if using GET; and HTTP >>>> libs vary on supporting GET with payload. >>>> >>> GET with payload would indeed be a bad idea. However you could use the >>> request URI for the payload; was this discussed? >>> >> >> So you mean encoding the entire DNS query packet as a long URL? >> >> That was *not* discussed, and is actually quite a clever idea. :-D >> > > it was discussed. it was dismissed. > > a text/dns format should be defined, likely being json, that can carry a > dns message. a dns-request URI format should be defined, so that we can > send a normal GET, subject to HTTP caching and proxying. > > but this is not that. those things should be defined -- elsewhere, by > someone who has a lot more appetite for work than we do. that other > specification can peacefully co-exist with this one -- and will be widely > intercepted by middleboxes, just as udp/53 and tcp/53 are today. the use > case for that specification is completely different from the use case for > this specification. > > please do not lose focus on the purpose of this specification, for which > POST was chosen deliberately, and for which POST is correct, and ideal. > > ... >> Let me discuss it with my co-authors and/or the dnsop working group and >> we'll see what we think. >> > > please pass the above comments on to anyone else, and any other forum, > where you have opened this discussion. it is vital that we not turn this > proxy-dns spec into a general-dns-over-http spec. > > RFC 5785 [RFC5785], it begins with the characters "/.well-known/" and >>>> the name "dns-wireformat". So the request-target for DNS >>>> wire-format >>>> over HTTP SHOULD be '/.well-known/dns-wireformat'. >>>> >>> No reason for a "SHOULD" here. Just define the well-known URI. >>> >> >> I'm not sure how this works. Clearly developers and operators don't >> need to use the well-known port, but we think that they should unless >> they have a good reason not to. Is this not the use case for the >> "SHOULD" key word? >> > > his comment was editorial. don't say SHOULD BE. say IS. > > Proxy-DNS-Transport: xyz >>>> >>>> Where xyz is either UDP or TCP, which is the client's indication of >>>> how it received the underlying DNS query, and which the server will >>>> use when sending the query to the far-end DNS server. This means if >>>> a stub DNS client asks for TCP, then that's what the far-end DNS >>>> server will see, and likewise for UDP. This header field is used >>>> for >>>> both request and response, for all DNS over HTTP message. >>>> >>>> Exposing the transport protocol of the query allows the HTTP server >>>> proxy to send DNS queries to the recursive resolver that look like >>>> those that the DNS client is sending to the client proxy. If the >>>> stub resolver sent a UDP packet, then this allows the recursive >>>> resolver to implement the logic of truncating the packet properly, >>>> instead of requiring that the HTTP client proxy somehow manage that >>>> functionality. >>>> >>>> For a stub resolver that connect directly via HTTP to the HTTP >>>> server >>>> proxy then this flag should be set to TCP, as the entire response >>>> can >>>> always be delivered so truncation is never required. >>>> >>>> The client MUST include this option. If it is missing then it is an >>>> error and the server should respond with HTTP code 400 (bad >>>> request). >>>> >>> I'm not sure why it's needed, but if it's needed it would be simpler to >>> just define two well-known URIs. >>> >> > that feels like a layering violation to me. > > -- > P Vixie >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
