Re: [dns-privacy] DNS-over-TLS query/answer framing.

[Tony Finch]

Simon Kelley  wrote:

> The current proposal is a huge pain, because 1035 framing only allows
> one query-in-flight per TCP/TLS connection.

No it doesn't. The reason DNS over TCP has query IDs like UDP is to
support pipelined queries and out-of-order responses. You can use adns to
try out query pipelining over TCP, and if you point it at BIND 9.11
(current pre-release git development branch) you will get out-of-order
responses. The performance of adns with one TCP connection to BIND 9.11 is
about the same as UDP.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] DNS-over-TLS query/answer framing.

[Simon Kelley]

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
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] DNS-over-TLS query/answer framing.

[Mankin, Allison]

Hi,

Having many queries in flight at once (aka pipelining) is a central 
recommendation of the DNSOP WG document
draft-ietf-dnsop-5966bis, and the DNS-over-TLS draft just cites that draft 
rather than repeating it.  We hope to cite it normatively
soon, once the DNSOP WG sends it to Last Call.  

Do you think DNS-over-TLS needs to mention a few more details from 5966bis in 
order to avoid confusion?

Allison

P.S. I wrote “we” due to being one of the authors on both DNS-over-TLS and 
5966bis...


> On Sep 8, 2015, at 5:18 PM, Simon Kelley  wrote:
> 
> 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
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy