Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

[Jacques Latour <[e-mail]>]

+1 & I don't like the path is going as well, and specifically from an enterprise security point of view.  Having DNS resolution that can bypass traditional enterprise security mechanisms is adding another layer of complexity to manage, you can't have a free for all in domain name resolution in enterprise networks.  I could go on, but I just want to say " I don't like the path is going".

Jack

-----Original Message-----
From: dns-privacy <[e-mail]> On Behalf Of Mukund Sivaraman
Sent: November 20, 2018 6:37 AM
To: [e-mail]
Subject: Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?

On Mon, Nov 19, 2018 at 05:04:14PM +0100, bert hubert wrote:
> On Mon, Nov 19, 2018 at 03:39:16PM +0000, Paul Hoffman wrote:
> > > It does around 2 DNS queries per HTTPS connection on average 
> > > dnsdist-doh keeps open an HTTP/2 connection for 10 seconds if it becomes idle.
> > 
> > Thanks, that seems to be your problem.  Can the dnsdist DoH server 
> > package be configured to have an idle timeout that is more 
> > representative of typical browser use, such as on the order of minutes?
> 
> I have measured with timeout of 100 seconds and 300 seconds. In both 
> cases, the packets per query ratio drops to 12, from 22. This is still 
> around 6 times more than UDP, and I now carry around hundreds of 
> additional filedescriptors. But ok.

This is not specifically about DoH, but I don't like the path DNS is taking. I don't like the general push to heavy protocols for DNS and have often commented about it on dprive and dnsop.

DNS historically has been mostly a light-weight single-request single-response stateless protocol (TCP is used as a last resort vs. UDP that's used in preference). The addition of a privacy layer could add more weight, but we seem to be uninterested in exploring other stateless or low-state ideas, outside TLS and even QUIC.

After the resolver work, the phase-2 introduction for resolver<->auth communications[1] started with TLS which seemed illogical to me. There must be empirical studies of consequences before protocols push through to RFC. People such as Sara Dickinson at Sinodun have been studying the performance and scalability of the privacy layer in DNS implementations which is very commendable.

[1] https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01

Some people such as Brian Haberman have taken an initiative to gather requirements for resolver-auth privacy instead of jumping directly to design which is again commendable.

dnsop and dprive should study this before pushing drafts to RFCs. What is the worst case on resource utilization, number of round-trips and number of packets to implement these layers? What could happen on average in practice? Large operators who plan ahead ask these questions. Can <implementation> handle TCP and DNS over TLS and DNS over HTTPS in a future world at rates similar to UDP now?  I can picture the overhead for UDP and TCP, but it is a lot more complicated with the extra layers.

It's not ok to assume and hand-wave away that optimizations such as TCP fastopen will avoid roundtrips and make up for performance. A TCP client may not have a cookie for the average nameserver case for the SYN except if it is for a "CDN/cloud" concentrated nameserver. I'm afraid these things will encourage more concentration for performance vs. keeping the internet distributed.

Facilities such as TCP fastopen are also experimental and we should not rely on them until more time has passed. Server-side support for it is still turned off by default in current versions of popular Linux distributions (a system-level setting that can't be enabled by applications such as a nameserver). Resolvers such as BIND have not yet implemented TCP fastopen for making connections. fastopen also suggests downgrades globally to regular 3-way TCP handshake from fastopen when there is a flood, which is not an attack in the regular sense, but loses the fastopen optimization if DNS relies on it to perform satisfactorily.

DNS is not a special protocol, but it is at the head of every internet activity. It has to perform well and scale well. The chairs should encourage studies into stateless methods to do privacy with low roundtrip overhead. Other protocols pay heed to stateless methods, e.g., DNS COOKIE is stateless on the server side. TCP fastopen is also stateless on the server side.

There is unexpected advice in RFCs too. When TCP fastopen is available for the DNS over TCP case, it seems better for the TCP connection to be closed than it be kept open because the open connection would revert to slow-start phase after an idle period with typical DNS query traffic patterns (unlike replies to a browser's HTTP requests that are typically much larger and more in sequence) unless it is continually active. In a greedy world, closing idle connections is something that authoritative servers would prefer to do to get rid of state - resolvers can't rely on having long-lived connections.

This has become a rant but I'm unhappy about the process that is pushing new DNS features without sufficient evaluation. Modifying the transport of DNS without studies may affect performance and scalability that we may come to regret.

		Mukund

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