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= [email protected]> 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) <[email protected]> > *Sent:* Wednesday, October 7, 2020 1:05 PM > *To:* Vinny Parla (vparla) <[email protected]> > *Cc:* [email protected] > *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 <[email protected]> > 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) < > [email protected]> 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 <[email protected]> > *Sent:* Wednesday, October 7, 2020 9:23 AM > *To:* James <[email protected]> > *Cc:* Vinny Parla (vparla) <[email protected]>; [email protected] > *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 <[email protected]> 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= > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > > > > > > _______________________________________________ > > dns-privacy mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
