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:
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.
Okay, the question was time line. I hope Unbound designers answer with an outline for time and design considerations. Whether a month or a year, some short term workaround may be useful. All workarounds (adjust cache and prefetch) are imperfect but may get by short term. At some reasonable cache rate, TLS connections will likely expire anyway before fresh data is needed. Neither server nor client will want excessive dangling connections. The gap in behavior may not be as big as it seems.