- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Fri, 5 May 2017 10:27:21 -0600
- To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
On 05/03/2017 06:38 PM, Daniel Kahn Gillmor wrote: > On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote: >> Think of the HTTP proxies, not just origin servers. > Here's a few things i think you might be saying: > > 0) A DNS client shouldn't expect this mechanism to work in the clear > over port 80, because existing transparent HTTP proxies that the > client doesn't know about will likely choke on it. I've noted this > as https://gitlab.com/dkg/hddemux/issues/3 > > 1) A DNS client shouldn't expect to use this mechanism through an > explicit HTTP proxy either, as the explicit proxy will also choke on > it. Yes, both. You can address (1) if you add support for HTTP proxies to the DNS client, but, at that point, you should just do the Right Thing and implement DNS-over-HTTP instead IMHO. > However, i'm not sure how this works for port 443. Due to the success of the "TLS everywhere" campaign, port 443 is nearly the same as port 80 from the deployment point of view these days. There are proxies that intercept and inspect port 443 traffic (just like they intercept and inspect port 80 traffic) and there are explicit proxies that inspect CONNECT tunnels, just like they inspect unencrypted HTTP messages. Needless to say, your DNS client may prohibit such inspections (like some HTTP sites/apps do) at the risk of being blocked or let the users/admin configure who to trust (like HTTP clients do). > Do you have suggestions of text for the draft that would address these > concerns? AFAICT, these concerns cannot be properly addressed in the proposed DNS-or-HTTP framework. They can only be addressed by a proper DNS-over-HTTP protocol. HTH, Alex.
Received on Friday, 5 May 2017 16:27:51 UTC