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] > <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 > <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 > <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 > <https://www.ietf.org/mailman/listinfo/dns-privacy>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
