[getdns-api] Changing the getdns transport options

[Sara Dickinson]

> On 15 Jun 2015, at 14:49, Willem Toorop <willem at nlnetlabs.nl> wrote:
> 
> Op 10-06-15 om 17:28 schreef Sara Dickinson:
> 
>> — The DNSOP WG is in the process of discussing protocol options to
>> establish behaviour for long lived DNS-over-TCP connections. The
>> question is how best to handle this in the API in the short term. It is
>> likely that two useful configuration options for long-lived connections
>> will be the 'idle_time' and the 'max_transactions_per_connection'.
> 
> So what is now known internally as GETDNS_BASE_TRANSPORT_TCP_SINGLE
> would then have idle_time 0 and max_transactions_per_connection 1?

Yes, and I’m thinking that would only be used for the TC=1 fallback case. (Although there is an argument that once you have fallen back you should stay on TCP…..)

> 
> Would that be the default setting for GETDNS_TRANSPORT_TCP?  Because if
> not, how are those old "single query per connection" nameservers going
> to respond when they receive two queries right after each other?  Is it
> possible to detect support for more than one transactions per connection?

It is quite subtle, but it isn’t multiple queries per connection that is the problem - 
all name servers I have tested will handle connection re-use and pipelining. The problem comes if the clients
don’t close connections before the server idle timeout.  With a default idle time of 0 it should be the case
that clients will close connections once they have used it for all the queries they have on hand, but won’t keep
it open indefinitely. And having a max_transactions_per_connection puts an upper limit on how long a client will
keep the connection open even when it is has a lot of queries to send at once. You could alternatively specify
a session duration, but figuring out good defaults for either is tricky. This is a balance act, not an exact science :-)

> 
>> It is
>> more convenient for users if they are context settings (as the query
>> ‘timeout' and ‘limit_outstanding_queries’ are today), however we should
>> consider if such values are more suited to being per-upstream or
>> per-transport settings. 
> 
> How about defaults at the context level; idle_time: 0,
> max_transactions_per_connection: 1, perhaps?  

I think the right place to start is defaults at the context level, but perhaps idle_time:0, max_transactions_per_connection:50?

> And then allow these
> values to be overloaded per-upstream?  I don't have warm feelings for
> the per-transport level as of yet... there is nothing configurable at
> that level yet either.

We could delay adding this lower level override until we have some good use cases? 

>> Implementation Note
>> ---------------------------
>> In the 0.2 release, if multiple upstreams and multiple transport values
>> are both specified then the transport list take precedence over the
>> upstream list when initially sending queries. [This is in order to
>> maximise the chance of using an encrypted transport when fallback to an
>> unencrypted transport is allowed]. However on reply truncation (TC=1)
>> the message is re-tried over TCP to the same upstream if TCP is in the
>> transport list.
> 
> Probably a bad idea, but we could consider a capabilities setting for
> upstreams (defaulting to all transports) to have more control over this.

Yes, I didn’t delve into this too much but I think there are more options we could consider here too.. For short lived contexts it would reduce the ‘discovery’ steps of trying to send messages, but if we ever get to the point of having a connection pool manager then that manager could/should remember upstream capabilities for longer periods.

Sara. 
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org