draft-ietf-dprive-start-tls-for-dns-01 section 2.1.5 "DNS queries SHOULD take place, following DNS-over-TCP framing ([RFC1035], section 4.2.2)"
Plus lots of stuff about managing TCP connections, re-using TCP connections, etc etc. "Alternatively they may prefer to use UDP to a DNS-over-TLS enabled caching resolver on the same machine that then uses a system- wide TCP connection to the recursive resolver." I'm thinking here, very much in the context of such a caching resolver, talking to a recursive DNS server upstream, at an ISP or 8.8.8.8 etc. Mainly because I maintain the most common such caching resolver in real life. The current proposal is a huge pain, because 1035 framing only allows one query-in-flight per TCP/TLS connection. Take common scenario of hitting a busy web page: 50 DNS queries go to the system-wide resolver and wants to forward them all to the recursive server. To do that it has to open 50 TCP/TLS connections. Now the answers come back, and to avoid having to do the same for the next batch, it keeps those 50 connections open. Are ISP DNS servers or Google DNS going to scale from stateless UDP to 50 TLS sessions per client? Seems unlikely. Since DNS-over-TLS is distinguished from DNS-over-TCP, 1035-style, could it also elaborate the framing to allow multiple in-flight queries over _one_ TLS session. Maybe something as simple as prepending a tag to queries as well as the length, with the same tag prepended to answers. Now the system cache can send all the queries over one TLS session, and get back the answers as they become available. There would still be the need to maintain connections, handle hard closes, etc. but the task of optimising connections pools would be much simpler, and ISP-scale recursive servers would scale much better. Cheers, Simon. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
