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