Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

[Murtaza Aliakbar <[e-mail]>]

We at RethinkDNS deployed DNS over HTTP3 (not DoQ though) in August. Didn't
know there was a race going on :)

Sent from my Nexus

On Fri, Dec 18, 2020, 2:03 AM Vinny Parla (vparla) <vparla=
[e-mail]> wrote:

> Just reviving this thread with the recent news to see what folks think in
> terms of content and dns multiplexing.
>
> Ad-blocker AdGuard deploys world's first DNS-over-QUIC resolver | ZDNet
> <https://www.zdnet.com/article/ad-blocker-adguard-deploys-worlds-first-dns-over-quic-resolver/>
>
>
>
> *From:* Chris Box (BT) <[e-mail]>
> *Sent:* Wednesday, October 7, 2020 1:05 PM
> *To:* Vinny Parla (vparla) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>
>
>
> Vinny,
>
>
>
> Christian makes a number of good points. I will just add that your
> original question assumes that the client wishes to send most or all of its
> DNS queries directly to the content provider it is talking to. The ADD
> working group is founded on the concept of needing to discover recursive
> resolvers, and very often these are not the same endpoints that the web
> content is served from. This implies that reuse of an existing HTTP/3
> connection that was established for retrieving web content, will not be the
> end goal for DNS queries. Sometimes it'll happen, yes, but certainly not
> all the time. It is far more likely that DNS will continue to be an
> independent layer, served by its own set of servers that has only *some*
> overlap with the set that serves web content.
>
>
>
> Chris
>
>
>
>
>
>
>
> On Wed, 7 Oct 2020 at 17:25, Christian Huitema <[e-mail]>
> wrote:
>
> There is indeed some extra per request overhead for Doh over HTTP3 versus
> Dns over QUIC, but I don't think that is the deciding factor. I think that
> the two other decision factors are for the client the privacy risks linked
> to cookies and other forms of HTTP tracking, and for the server the
> additional attack surface caused by adding an HTTP server stack to the DNS
> service. These factors may play out differently in the stub to recursive
> scenario and in the recursive to authoritative scenario.
>
> In HTTP-3, each DNS request would be carried by as a POST command, which
> requires a Header Frame to carry the HTTP header parameters and a Data
> Frame that carries the actual data. Each reply also requires a Header Frame
> and a Data Frame. In the fairly minimal implementation of HTTP-3 in
> Picoquic, the HTTP header carries the name of the Request URL, the name of
> the Http Server, and the content type. The Data Frame header carries the
> content length. The typical overhead for a request would be 16 to 32 bytes,
> depending on the length of server name and URL; the overhead per response
> will be 21 bytes. A full implementation of HTTP-3 would use header
> compression to reduce the size of the query overhead, but might use an
> additional set of HTTP header elements, including cookies, so the Header
> Frames might be larger in both directions, with a range of header size from
> a few dozen to a few hundred bytes.
>
> Running over HTTP brings to the DNS the privacy issues of HTTP. Cookies
> and other headers are used to manage content and caches, but also identify
> the users and enable a variety of surveillance scenarios. If a DoH query is
> multiplexed inside a regular HTTP session, the query will be associated
> with all the user information gathered in the session, which creates an
> important privacy exposure. This is definitely a greater exposure than a
> regular DNS query, in which the main identifying information is an IP
> address.
>
> On the server side, running over HTTP implies running on top of an HTTP
> server engine. This brings in a lot of code, some of it complex. It might
> be well tested and well maintained code, typically much better tested and
> maintained than if a server operator attempted to develop a specialized
> implementation of HTTP, but this is still a very large additional attack
> surface. Moreover, the HTTP code only remains "well maintained" if the
> operators regularly apply updates, which adds an operational constraint.
>
> I think that the exposure and overhead issues imply that solutions like
> DoT or DoQ should be preferred to DoH in recursive to authoritative
> scenarios. They should also be preferred when the stub resolver is part of
> the operating system, because operating system resolvers would normally not
> mix their queries with existing HTTP sessions, and thus don't get any
> advantage from "integrating to the web" -- unless of course firewall
> traversal is a big issue.
>
> -- Christian Huitema
>
>
>
> On 10/7/2020 8:31 AM, Tommy Pauly wrote:
>
> DoH is designed to be multiplexed with other HTTP requests. This is
> already possible with HTTP/2, and HTTP/3 carries on that ability. In order
> to take advantage of multiplexing, even with QUIC, you need some
> application-layer awareness of the content of the streams, which is why
> this is more practical with DoH than DoQ.
>
>
>
> I’m not sure how prevalent the multiplexing is today. For example, in our
> system implementation on iOS/macOS, DoH connections are made by the system
> DNS daemon and thus are not easy to multiplex with requests. However,
> that’s just one model, and there are certainly cases where the application
> would know it could multiplex a priori (and thus do DoH in the
> application), or could recognize that DNS results point to the same address
> as the DoH server, and start multiplexing after the fact.
>
>
>
> Thanks,
>
> Tommy
>
>
>
> On Oct 7, 2020, at 7:39 AM, Vinny Parla (vparla) <
> vparla=[e-mail]> wrote:
>
>
>
> Hi,
>
>
>
> What I am driving at in my original question is do we envision mixing
> Content and DNS together in a multiplexed session or will DNS continue to
> be an entirely independent channel (whether over HTTP/2 /3 Do53 DoQ DoH).
>
>
>
> -Vinny
>
>
>
> *From:* Tommy Pauly <tpauly=[e-mail]>
> *Sent:* Wednesday, October 7, 2020 9:23 AM
> *To:* James <[e-mail]>
> *Cc:* Vinny Parla (vparla) <[e-mail]>; [e-mail]
> *Subject:* Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>
>
>
> Can you cite this claim about DNS over HTTP/3? The per-query cost once an
> HTTP/3 connection is established should be minimal. If you’re taking into
> account all setup overhead for an HTTPS connection as a “per query” cost,
> that’s not representative of how DoH is reasonably used (and would be a
> issue with existing DoH).
>
>
>
> Thanks,
>
> Tommy
>
>
>
> On Oct 6, 2020, at 2:03 PM, James <[e-mail]> wrote:
>
>
>
> My most recent observations of discussions around DNS over QUIC and HTTP/3
> was that some folks had attempted DNS over HTTP/3, however the overheads
> (~14KiB for a query at worst-case) made it impractical and infeasible. With
> regards to DNS over QUIC, the current dprive working group adopted draft
> [1] is focusing on stub to recursive, but not necessarily as a multiplex
> with an existing QUIC connection.
>
>
>
> - J
>
>
>
> 1: https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00
>
>
>
> On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=
> [e-mail]> wrote:
>
> Hi,
>
>
>
> It was suggested that I ask this question on the 3 lists:
>
>
>
> Now that QUIC & HTTP/3 is imminent…
>
>
>
> I would like to know what the opinion is of the community on the long term
> view of DNS.
>
> Would DNS remain an independent channel or would it be subsumed in a
> multiplexed stream via HTTP/3 in some future version?
>
>
>
> For example, would a browser perform DNS queries over a QUIC multiplexed
> session?
>
>  (e.g. similar to how today an http proxy can perform DNS queries on
> behalf of the client using that proxy)
>
>
>
> Would love to hear from implementors what their long term view is of this
> in particular.
>
>
>
> Thanks,
>
>
>
> -Vinny
>
>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
>
>
>
> _______________________________________________
>
> dns-privacy mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>