Responding to only one part: > > - 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 > A typical DNS query is less than 100 bytes, which means even > hex-encoded would be only a 200-byte URI. That would have the nice > effect of giving a URL that can be cut & paste for debugging and so on. > (We could also use base64 or base32, but I find that hex-encoding is > relatively easy to work with for humans should that ever be necessary.) > Anyway, it *is* more bytes, but I'm not sure it would result in more > packets which is probably more important. (This depends on HTTP > pipelining and the like.) > Let me discuss it with my co-authors and/or the dnsop working group and > we'll see what we think.
I had to search to be sure that the GET URL is encrypted, and found that there might be additional concerns if the user is using this with https for privacy. The web page at https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/ listed three concerns: 1. The URL would get logged in the web server logs. Including the DNS query. 2. If using a browser, the URL is saved in the browser history 3. If used in a web page, URLs are passed in Referrer headers I don't think #2 and #3 apply to DNS over HTTPS, but #1 might be a concern. However, the server is already getting the DNS query and might be logging queries at the DNS level, so maybe this is just an issue to mention to the server admin. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
