[getdns-api] Changing the getdns transport options

[Willem Toorop]

Op 10-06-15 om 17:28 schreef Sara Dickinson:
> API Notes
> --------
> 1) For all TCP based connections:
> 
>  — It is suggested from the default idle time should be 0. This is
> because several widely used server implementations (including BIND and
> Unbound) have a default configuration which cannot handle many
> long-lived TCP connections well. 

Sounds good to me.

>  — 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?

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
> 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?  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.

> 2) For STARTTLS/TLS connections I think we should also consider adding a
> per-upstream setting for “TLS Authentication data” and a context setting
> for “TLS versions/ciphers” in the future (current support is for TLS 1.2
> only). 

Yes, makes perfect sense to me.  TSIG authentication data is also at
that spot currently.

> 
> 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.


Regards,
-- Willem
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org