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

["Vinny Parla (vparla)" <[e-mail]>]

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] <mailto:[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] <mailto: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] <mailto:tpauly=[e-mail]> > 
Sent: Wednesday, October 7, 2020 9:23 AM
To: James <[e-mail] <mailto:[e-mail]> >
Cc: Vinny Parla (vparla) <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/dns-privacy

_______________________________________________
dns-privacy mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/dns-privacy> https://www.ietf.org/mailman/listinfo/dns-privacy

 

 

_______________________________________________
dns-privacy mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/dns-privacy

_______________________________________________
dns-privacy mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/dns-privacy