On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> This document is a good idea, but it has some faults that need to be fixed > before it goes forwards. > > - In the Introduction, it says in essence that this is just using HTTP to > tunnel DNS and is not of use to web browsers. This is wrong, I believe. > JavaScript in browsers cannot create port 53 queries, but they can create > arbitrary HTTP/HTTPS queries. This protocol would allow JavaScript apps to > get DNS responses as long as they could cobble together the request bytes > and interpret the response. It would be ugly, yes, but so is a lot of stuff > I see in JavaScript these days. > > If it is feasible (or there is an technical requirement) that JavaScript can handle wire-format DNS massage over HTTP, it is no reason to exclude it. So the simple way to edit this is to get rid of such saying of denying web browser user. > - Using POST for queries goes against the design of HTTP. POST is for > requests that change state on the server, and DNS queries are not that. > This protocol should use GET. > Fair enough. > > - The lack of a common URI template will completely prevent > interoperability. You should instead use .well-known prefix for getting the > syntax as described in RFC 5785. > I agree we should end up with a fixed URI template which can be recognized by both client and server. Particularly in Proxy mode, the server proxy will leverage the 80/443 port with existing Web server, we should avoid conflicts with existing web service URIs. - Section 3.3 is completely unclear. Either prohibit the two-byte length > added for TCP queries, or require them all the time. Making them optional > will make interoperability difficult or impossible. > What we say in Section 3.3 is not including the two-byte field in the message sent to the server. Is the text not clear ? I will try to make it more clear > > - Having no security considerations for a protocol that has optional HTTPS > seems like a big oversight. > Yes. I admit it is a big oversight here. I will discuss with co-authors. Any suggestions ? > > Hope this helps! > > Thank you ! The original idea is to document how we implement the software and try to share the communication pattern with other developers. Now we should follow IETF way to formalized the document : ) Davey > --Paul Hoffman >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
