W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

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>
Message-ID: <26d3a30c-02bd-faca-5bc8-a7d9748a753c@measurement-factory.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC