TLS connection reuse implementation timeline (#4089)

[Eric Luehrsen]

On 07/05/2018 04:53 AM, nusenu via Unbound-users wrote:
> Hi,
> 
> Since unbound's missing TLS connection reuse feature
> is now used as a justification [1] why DoH [2] has better software
> than DoT I was wondering if you had any timeline
> for TLS connection reuse in unbound, which is already in your bugzilla:
> 
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089
> 
> I'm looking for a rough estimate, something like:
> will be released within
> - 3 month,
> - before the end of the year
> - in 2019
> 
> thanks!
> nusenu
> 
> 
> [1] https://twitter.com/FiloSottile/status/1014603362204028935
> [2] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1200
> 

Unbound current behavior may be a bit inefficient, but at least it is a 
robust and repeatable behavior. If Unbound cache and prefetch parameters 
are configured properly, they can mitigate the TLS handshake overhead. 
For the limited users of DOT (or DOH) this is not so awful.

I could see outstanding design decisions to make: what is a minimum time 
to wait for new queries before closing an idle connection? what is a 
maximum time to wait to drop and redo a connection? will minimum timer 
reset on any new query, or does it extend with some weight function? how 
will this affect the client and server relationship? how long should a 
public DNS accept a dangling connection (thinking about 1.1.1.1)?

As far as DOH vs DOT, the rhetoric is becoming a little silly. As with 
all things, there is and will be the right tool for the right job. It 
seems a minor stumble in deploying a specification should not be used as 
justification for another. That is, if we use a disciplined scientific 
method.

Eric