From willem at nlnetlabs.nl Thu Apr 6 21:39:41 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 6 Apr 2017 23:39:41 +0200 Subject: [getdns-users] Second release candidate for getdns-1.1.0 Message-ID: Dear all, We have a second release candidate for the new feature release version 1.1.0 of getdns. The first release has been extensively tested and used in the IETF98 Hackathon, which has let to some great hacks!, and also revealed some improvement potentials and even some bugs. This second release candidate addresses those things: * The return_call_reporting extension now also returns the remote end's certificate if the interaction was over TLS. * Stateful connections with and idle_timeout > 0 will not be closed after doing a synchronous request any more. This also involved a bugfix for naked timeout events with Windows. * Stability of the DNSSEC extensions in combination with stateful transports have been improved (and a bugfix in which this combination hang). * A default edns0 padding policy contributed by DKG. * A new function getdns_context_unset_edns_maximum_udp_payload_size() to reset to the default behaviour to have a maximum UDP payload size dependent on the address family; 1432 for IPv4 and 1232 for IPv6 to maximize receptivity. Please review this release candidate carefully, if all is well, the actual release will follow Thursday the 13th of April. link : https://getdnsapi.net/dist/getdns-1.1.0-rc2.tar.gz pgp : https://getdnsapi.net/dist/getdns-1.1.0-rc2.tar.gz sha256: d91ec104b33880ac901f36b8cc01b22f9086fcf7d4ab94c0cbc56336d1f6bec0 ChangeLog ========= * 2017-04-??: Version 1.1.0 * bugfix: Reschedule request timeout when getting the DNSSEC chain. * getdns_context_unset_edns_maximum_udp_payload_size() to reset to default IPv4/IPv6 dependent edns max udp payload size. * Implement sensible default edns0 padding policy. Thanks DKG. * Keep connections open with sync requests too. * Fix of event loops so they do not give up with naked timers with windows. Thanks Christian Huitema. * Include peer certificate with DNS-over-TLS in combination with the return_call_reporting extension. * 2017-03-23: Version 1.1.0-rc1 * More fine grained control over TLS upstream retry and back off behaviour with getdns_context_set_tls_backoff_time() and getdns_context_set_tls_connection_retries(). * New round robin over the available upstreams feaure. Enable with getdns_context_set_round_robin_upstreams() * Bugfix: Queue requests when no sockets available for outgoing queries. * Obey the outstanding query limit with STUB resolution mode too. * Updated stubby config file * Draft MDNS client implementation by Christian Huitema. Enable with --enable-draft-mdns-support to configure * bugfix: Let synchronous queries use fds > MAX_FDSETSIZE; By moving default eventloop from select to poll Thanks Neil Cook * bugfix: authentication failure for self signed cert + only pinset * bugfix: issue with session re-use making authentication appear to fail * 2016-10-19: Version 1.1.0-a2 * Improved TLS connection management * OpenSSL 1.1 support * Stubby, Server version of getdns_query that by default listens on 127.0.0.1 and ::1 and reads config from /etc/stubby.conf and $HOME/.stubby.conf * 2016-07-14: Version 1.1.0a1 * Conversion functions from text strings to getdns native types: getdns_str2dict(), getdns_str2list(), getdns_str2bindata() and getdns_str2int() * A getdns_context_config() function that configures a context with settings given in a getdns_dict * A a getdns_context_set_listen_addresses() function and companion getdns_reply() function to construct simple name servers. * Relocate getdns_query to src/tools and build by default * Enhancements to the logic used to select connection based upstream transports (TCP, TLS) to improve robustness and re-use of connections/upstreams. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 829 bytes Desc: OpenPGP digital signature URL: From sca at andreasschulze.de Mon Apr 10 15:38:19 2017 From: sca at andreasschulze.de (A. Schulze) Date: Mon, 10 Apr 2017 17:38:19 +0200 Subject: [getdns-users] client authentication Message-ID: <5b33639d-8f8a-1ff1-7189-da0e3614cca9@andreasschulze.de> Hello, as a client I could now query a TLS aware Resolver via DNS-over-TLS. I could prove to talk to the right server by checking the pin. $ getdns_query -s yeti-ns.datev.net aaaa -l L -m -K 'pin-sha256="QFWn+jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg="' @2a00:e50:f15c:1000::2:53 ... Response code was: GOOD. Status was: At least one response was returned So far so good. But from the resolver operators view I like to know "who is my client?" Usually resolver aren't run to serve anybody (like 8.8.8.8 does) but are limited to answer requests from a trusted network only. With TLS it may be an option to limit the service to clients presenting a certificate from my own CA. like in the "Webworld" where it's simply a client certificate based authentication+authorization. Does DNS-over-TLS offer a similar setup? Andreas From dkg at fifthhorseman.net Mon Apr 10 20:06:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 10 Apr 2017 16:06:09 -0400 Subject: [getdns-users] client authentication In-Reply-To: <5b33639d-8f8a-1ff1-7189-da0e3614cca9@andreasschulze.de> References: <5b33639d-8f8a-1ff1-7189-da0e3614cca9@andreasschulze.de> Message-ID: <87h91wauz2.fsf@fifthhorseman.net> On Mon 2017-04-10 17:38:19 +0200, A. Schulze wrote: > as a client I could now query a TLS aware Resolver via DNS-over-TLS. I could prove to talk to the right server by checking the pin. > > $ getdns_query -s yeti-ns.datev.net aaaa -l L -m -K 'pin-sha256="QFWn+jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg="' @2a00:e50:f15c:1000::2:53 > ... > Response code was: GOOD. Status was: At least one response was returned > > So far so good. But from the resolver operators view I like to know "who is my client?" > Usually resolver aren't run to serve anybody (like 8.8.8.8 does) but are limited to answer requests from a trusted network only. > With TLS it may be an option to limit the service to clients presenting a certificate from my own CA. > like in the "Webworld" where it's simply a client certificate based authentication+authorization. > > Does DNS-over-TLS offer a similar setup? I strongly discourage the operators of DNS recursive resolvers from implementing client authentication. For TLS 1.2 and earlier (i.e. all formalized versions of TLS today) the client certificate is visible in the clear over the network during the handshake. This exposes your client's individual location information to any passive network monitor, which is not a good thing for a protocol that is intended to enhance user privacy. RFC 7858 (which specifies DNS-over-TLS) does not contemplate client authentication at all, which i think is a fine thing. If you were limiting client connection on the basis of IP address, you can continue to do so over TLS, right? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From shuque at gmail.com Mon Apr 10 20:38:18 2017 From: shuque at gmail.com (Shumon Huque) Date: Mon, 10 Apr 2017 16:38:18 -0400 Subject: [getdns-users] client authentication In-Reply-To: <87h91wauz2.fsf@fifthhorseman.net> References: <5b33639d-8f8a-1ff1-7189-da0e3614cca9@andreasschulze.de> <87h91wauz2.fsf@fifthhorseman.net> Message-ID: On Mon, Apr 10, 2017 at 4:06 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-04-10 17:38:19 +0200, A. Schulze wrote: > > > as a client I could now query a TLS aware Resolver via DNS-over-TLS. I > could prove to talk to the right server by checking the pin. > > > > $ getdns_query -s yeti-ns.datev.net aaaa -l L -m -K 'pin-sha256="QFWn+ > jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg="' @2a00:e50:f15c:1000::2:53 > > ... > > Response code was: GOOD. Status was: At least one response was returned > > > > So far so good. But from the resolver operators view I like to know "who > is my client?" > > Usually resolver aren't run to serve anybody (like 8.8.8.8 does) but are > limited to answer requests from a trusted network only. > > With TLS it may be an option to limit the service to clients presenting > a certificate from my own CA. > > like in the "Webworld" where it's simply a client certificate based > authentication+authorization. > > > > Does DNS-over-TLS offer a similar setup? > > I strongly discourage the operators of DNS recursive resolvers from > implementing client authentication. > For TLS 1.2 and earlier (i.e. all formalized versions of TLS today) the > client certificate is visible in the clear over the network during the > handshake. This exposes your client's individual location information > to any passive network monitor, which is not a good thing for a protocol > that is intended to enhance user privacy. > Client authentication does not necessarily mean identifying a specific client though - this authentication could use a group credential to provide access control to the DNS privacy server to that group, without needing to identify specific clients or users. Perhaps someone wants to run a DNS over TLS server for his/her set of colleagues all over the Internet, where access control by IP address would not work. In TLS, this could be accomplished with pre-shared key, shared raw public key, or even a shared client certificate credential with a generic identity. This might also be possible via Transaction Signature keys - at the DNS layer, but that carries an additional per DNS message overhead. > RFC 7858 (which specifies DNS-over-TLS) does not contemplate client > authentication at all, which i think is a fine thing. If you were > limiting client connection on the basis of IP address, you can continue > to do so over TLS, right? > I think I generally agree that per-client authentication and logging for DNS privacy should not be recommended for all the reasons cited. But should it be prohibited outright? I'm sympathetic to Christian's concerns that this might rule out some folks who might have otherwise deployed DNS over TLS. So if folks want to do it, perhaps we should examine what the best methods are, and make sure those methods aren't leaking any client identities in the clear. Does TLS 1.3 protect the client certificate? To Christian's question about alternatives to per-client certificate authentication in TLS, there are a few, but they are unfortunately seldom used today (Pre-shared key; SRP; Kerberos - spec deprecated; OpenPGP keys, etc). At the DNS layer, per-client authentication is possible with GSS-TSIG, but it's very complex to set up. -- Shumon Huque -------------- next part -------------- An HTML attachment was scrubbed... URL: From huitema at huitema.net Mon Apr 10 22:30:44 2017 From: huitema at huitema.net (Christian Huitema) Date: Mon, 10 Apr 2017 15:30:44 -0700 Subject: [getdns-users] client authentication In-Reply-To: References: <5b33639d-8f8a-1ff1-7189-da0e3614cca9@andreasschulze.de> <87h91wauz2.fsf@fifthhorseman.net> Message-ID: <8b76bc3a-3b59-68fb-8f44-73a1485cf85c@huitema.net> On 4/10/2017 1:38 PM, Shumon Huque wrote: > On Mon, Apr 10, 2017 at 4:06 PM, Daniel Kahn Gillmor > > wrote: > > ... > > > For TLS 1.2 and earlier (i.e. all formalized versions of TLS > today) the > client certificate is visible in the clear over the network during the > handshake. This exposes your client's individual location information > to any passive network monitor, which is not a good thing for a > protocol > that is intended to enhance user privacy. > Yes. That's why TLS client authentication is probably a bad idea. The identity leak is kinda fixed in TLS 1.3, but only if the client refuses to negotiate down to 1.2, and that's not practical. > ... > Does TLS 1.3 protect the client certificate? To Christian's question > about > alternatives to per-client certificate authentication in TLS, there > are a few, but > they are unfortunately seldom used today (Pre-shared key; SRP; Kerberos - > spec deprecated; OpenPGP keys, etc). At the DNS layer, per-client > authentication > is possible with GSS-TSIG, but it's very complex to set up. Pretty much all the TLS client authentication schemes share the "identity leak in clear text" issue that DKG is mentioning. If we really need client auth, we need to look at a DNS level solution, or maybe DNS over TLS specific solution. If GSS-TSIG works, that may be it. If it doesn't, maybe use something else, like some TBD EDNS transaction. But first, we have to be really convinced that we do need client auth! -- Christian Huitema -------------- next part -------------- An HTML attachment was scrubbed... URL: From shuque at gmail.com Mon Apr 10 23:36:29 2017 From: shuque at gmail.com (Shumon Huque) Date: Mon, 10 Apr 2017 19:36:29 -0400 Subject: [getdns-users] client authentication In-Reply-To: <8b76bc3a-3b59-68fb-8f44-73a1485cf85c@huitema.net> References: <5b33639d-8f8a-1ff1-7189-da0e3614cca9@andreasschulze.de> <87h91wauz2.fsf@fifthhorseman.net> <8b76bc3a-3b59-68fb-8f44-73a1485cf85c@huitema.net> Message-ID: On Mon, Apr 10, 2017 at 6:30 PM, Christian Huitema wrote: > > On 4/10/2017 1:38 PM, Shumon Huque wrote: > > On Mon, Apr 10, 2017 at 4:06 PM, Daniel Kahn Gillmor < > dkg at fifthhorseman.net> wrote: > >> ... > > >> For TLS 1.2 and earlier (i.e. all formalized versions of TLS today) the >> client certificate is visible in the clear over the network during the >> handshake. This exposes your client's individual location information >> to any passive network monitor, which is not a good thing for a protocol >> that is intended to enhance user privacy. >> > > Yes. That's why TLS client authentication is probably a bad idea. The > identity leak is kinda fixed in TLS 1.3, but only if the client refuses to > negotiate down to 1.2, and that's not practical. > Although DNS over TLS might be enough of a green field application that perhaps TLS 1.3 only out of the gate might be plausible if there were new requirements. > ... > Does TLS 1.3 protect the client certificate? To Christian's question about > alternatives to per-client certificate authentication in TLS, there are a > few, but > they are unfortunately seldom used today (Pre-shared key; SRP; Kerberos - > spec deprecated; OpenPGP keys, etc). At the DNS layer, per-client > authentication > is possible with GSS-TSIG, but it's very complex to set up. > > > Pretty much all the TLS client authentication schemes share the "identity > leak in clear text" issue that DKG is mentioning. If we really need client > auth, we need to look at a DNS level solution, or maybe DNS over TLS > specific solution. If GSS-TSIG works, that may be it. If it doesn't, maybe > use something else, like some TBD EDNS transaction. > Yeah, it's a bit challenging. One problem with the DNS level solution is that the server is paying the full price of a TLS handshake before deciding whether or not to allow access, which doesn't seem very desirable. > But first, we have to be really convinced that we do need client auth! Right! -- Shumon Huque -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Thu Apr 13 19:19:01 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 13 Apr 2017 21:19:01 +0200 Subject: [getdns-users] getdns-1.1.0 released Message-ID: Dear all, We are pleased to announce release 1.1.0 of our library implementation of the getdns API. This version comes with the DNS Privacy stub resolver Stubby. Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is in the early stages of development but is suitable for technical/advanced users. A more generally user-friendly version is on the way! More information about Stubby is here: https://getdnsapi.net/blog/dns-privacy-daemon-stubby/ Stubby will be build by default and will be installed in the ${PREFIX}/bin directory. Also the getdns_query test tool will be build and installed by default now. If you want the library only, you can disable building and installation of those programs with the --without-stubby and --without-getdns_query options to configure. getdns_query (and Stubby) have had functionality added which was not part of the original API specification, but which we think is useful for other applications as well. This includes functions that have been added to deal with parsing and configuring getdns with a configuration file, and functions to serve DNS requests. To handle configuration files, functions were added to convert strings to getdns native types, getdns_str2dict(), getdns_str2list(), getdns_str2bindata() and getdns_str2int(); A getdns_context can then be configured with a resulting getdns_dict with the new getdns_context_config() function. This can reduce the amount of code needed to setup a context in a C program. It also provides default values for extensions and allows the trust anchor and root hints files to be directly specified. For example, the following piece of C code would configure the context to do DNSSEC roadblock avoidance (i.e. validate DNSSEC as stub, fallback to full recursive with hampering middleboxes), with alternative trust-anchor and root-hints. if (GETDNS_RETURN_GOOD == getdns_str2dict( "{ dnssec_roadblock_avoidance: GETDNS_EXTENSION_TRUE" ", dns_root_servers: \"/etc/yeti/named.cache\"" ", dnssec_trust_anchors: \"/etc/yeti/KSK.pub\"" "}", &config_dict)) getdns_context_config(context, config_dict); More detailed (doxygen) documentation about the string to getdns data structure functions, and about configuring getdns_contexts with getdns_dicts is here: https://getdnsapi.net/doxygen/group__Ustring2getdns__data.html https://getdnsapi.net/functions/getdns_context_config.html The getdns_context_set_listen_addresses() function, allows the user to register a request handler function and list of addresses that will be listened on when the eventloop is run. The request handler function will be called when a DNS requests arrives, with the request in getdns reply dict format. The request handler may construct a response to the request and eventually has to call getdns_reply() with that response to answer the request (or NULL to cancel). I will try to provide and example blog post on the website for this functionality shortly. For now, we have the doxygen documentation and the IETF97 hackathon project delaydns which was using this functionality: https://getdnsapi.net/doxygen/group__UServerFunctions.html https://github.com/IETF-Hackathon/delaydns Besides these new functions, we have much improved and more stable and robust scheduling of requests: * The default event loop, which is also used for synchronous requests, is now based on poll() instead of select() and does not inherit select()'s limits any more. * The limit on number of outstanding queries, set with the getdns_context_limit_outstanding_queries() function, will now also be obeyed in stub mode. This was an ommision from the 1.0.0 release. * getdns will now queue up requests that could not be scheduled because of resource limitations, to be rescheduled when resources become available again. We now also have: * a new modus for stub resolving in which queries are scheduled round robin over the upstreams. This can be enabled with the getdns_context_set_round_robin_upstreams() function. * more fine grained control over how TLS upstreams are retried with the getdns_context_set_tls_backoff_time() and the getdns_context_set_tls_connection_retries() function. and * Much improved doxygen documentation. Have a look here: https://getdnsapi.net/doxygen/ Finally, we have a new draft MDNS-client implementation by Christian Huitema. To enable it, use the --enable-draft-mdns-client option to configure. Happy Easter! link : https://getdnsapi.net/dist/getdns-1.1.0.tar.gz pgp : https://getdnsapi.net/dist/getdns-1.1.0.tar.gz.asc sha256: aa47bca275b97f623dc6799cee97d3465fa46521d94bd9892e08e8d5d88f09c3 ChangeLog ========= * 2017-04-13: Version 1.1.0 * bugfix: Check size of tls_auth_name. * Improvements that came from Visual Studio static analysis * Fix to compile with libressl. Thanks phicoh. * Spelling fixes. Thanks Andreas Schulze. * bugfix: Reschedule request timeout when getting the DNSSEC chain. * getdns_context_unset_edns_maximum_udp_payload_size() to reset to default IPv4/IPv6 dependent edns max udp payload size. * Implement sensible default edns0 padding policy. Thanks DKG. * Keep connections open with sync requests too. * Fix of event loops so they do not give up with naked timers with windows. Thanks Christian Huitema. * Include peer certificate with DNS-over-TLS in combination with the return_call_reporting extension. * More fine grained control over TLS upstream retry and back off behaviour with getdns_context_set_tls_backoff_time() and getdns_context_set_tls_connection_retries(). * New round robin over the available upstreams feaure. Enable with getdns_context_set_round_robin_upstreams() * Bugfix: Queue requests when no sockets available for outgoing queries. * Obey the outstanding query limit with STUB resolution mode too. * Updated stubby config file * Draft MDNS client implementation by Christian Huitema. Enable with --enable-draft-mdns-support to configure * bugfix: Let synchronous queries use fds > MAX_FDSETSIZE; By moving default eventloop from select to poll Thanks Neil Cook * bugfix: authentication failure for self signed cert + only pinset * bugfix: issue with session re-use making authentication appear to fail * 2016-10-19: Version 1.1.0-a2 * Improved TLS connection management * OpenSSL 1.1 support * Stubby, Server version of getdns_query that by default listens on 127.0.0.1 and ::1 and reads config from /etc/stubby.conf and $HOME/.stubby.conf * 2016-07-14: Version 1.1.0a1 * Conversion functions from text strings to getdns native types: getdns_str2dict(), getdns_str2list(), getdns_str2bindata() and getdns_str2int() * A getdns_context_config() function that configures a context with settings given in a getdns_dict * A a getdns_context_set_listen_addresses() function and companion getdns_reply() function to construct simple name servers. * Relocate getdns_query to src/tools and build by default * Enhancements to the logic used to select connection based upstream transports (TCP, TLS) to improve robustness and re-use of connections/upstreams. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 829 bytes Desc: OpenPGP digital signature URL: From xmgao at biigroup.cn Wed Apr 19 06:54:41 2017 From: xmgao at biigroup.cn (xmgao at biigroup.cn) Date: Wed, 19 Apr 2017 14:54:41 +0800 Subject: [getdns-users] A question on stubby Message-ID: <2017041914544074037618@biigroup.cn> Hello everyone, I?m Xiaomin, a young engineer in this field. I?m trying to setup a DNS-over-TLS demo using Stubby recently. Now it works in opportunistic mode, but failed in strict mode with 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field. AFAIK, the server are using Let's encrypt cert, What should I do on client side(stubby) to verify the cert? Do I need make extra configuration on Stubby or openssl? Thanks in advance. Best reguards, Xiaomin xmgao at biigroup.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From sca at andreasschulze.de Wed Apr 19 08:25:23 2017 From: sca at andreasschulze.de (A. Schulze) Date: Wed, 19 Apr 2017 10:25:23 +0200 Subject: [getdns-users] A question on stubby In-Reply-To: <2017041914544074037618@biigroup.cn> Message-ID: <20170419102523.Horde.IJBXCnv_fIoIvj4ZpTN4vDo@andreasschulze.de> xmgao: > Hello everyone, > I?m Xiaomin, a young engineer in this field. I?m trying to setup a > DNS-over-TLS demo using Stubby recently. Now it works in > opportunistic mode, but failed in strict mode with > 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field. AFAIK, > the server are using Let's encrypt cert, What should I do on client > side(stubby) to verify the cert? Do I need make extra configuration > on Stubby or openssl? Hello, I use this configuration: $ cat /etc/resolv.conf nameserver ::1 $ cat /etc/stubby.conf { resolution_type: GETDNS_RESOLUTION_STUB , dns_transport_list: [ GETDNS_TRANSPORT_TLS ] , upstream_recursive_servers: [ { address_data: 2a00:e50:f15c:1000::2:53 , tls_auth_name: "yeti-rr.datev.net" , tls_pubkey_pinset: [ { digest: "sha256" , value: QFWn+jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg= } ] } ] , idle_timeout: 10000 } $ stubby -C /etc/stubby.conf $ dig hostname.bind. txt chaos +short "see https://yeti-rr.datev.net" This forward all requests to the Yeti-DNS Resolver. The Resolver use the same LE certificate on https/443 and domain-s/853. The Resolver is IPv6 only but capable to reach name servers via IPv4 So it /should/ reach the whole internet... BTW. stubby.conf was created (guessing) using information on https://getdnsapi.net/blog/dns-privacy-daemon-stubby/ The example file (src/tools/stubby.conf) mentioned there don't exist in the current release. Any formal documentation on stubby.conf is really required! Andreas From sara at sinodun.com Wed Apr 19 08:34:42 2017 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 19 Apr 2017 09:34:42 +0100 Subject: [getdns-users] A question on stubby In-Reply-To: <2017041914544074037618@biigroup.cn> References: <2017041914544074037618@biigroup.cn> Message-ID: > On 19 Apr 2017, at 07:54, xmgao at biigroup.cn wrote: > > Hello everyone, > I?m Xiaomin, a young engineer in this field. I?m trying to setup a DNS-over-TLS demo using Stubby recently. Now it works in opportunistic mode, but failed in strict mode with 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field. AFAIK, the server are using Let's encrypt cert, What should I do on client side(stubby) to verify the cert? Do I need make extra configuration on Stubby or openssl? Hi Xiaomin, Thanks for your question. Can you let me know which version of Stubby you are using? I would recommend using the recent 1.1.0 release. To validate a nameserver Stubby needs one of - an authentication domain name or - a SPKI pin The easiest way to set up strict authentication is to use the default configuration file that is in the getdns source code in src/tools/stubby.conf which has this information in for several servers. Then tell Stubby where to find this file by using the ?-C? flag on the command line. I?ve attached the stubby.conf file here for reference. This configuration will run in Strict mode, using all the servers listed. If you want a simple demo then I suggest just using a single server that has a Let?s Encrypt certificate. I?ve created a file for that too using the getdns nameserver and attached it (stubby_one_server.conf). Hope this helps Regards Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stubby.conf Type: application/octet-stream Size: 2149 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stubby_one_server.conf Type: application/octet-stream Size: 535 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmgao at biigroup.cn Wed Apr 19 09:36:26 2017 From: xmgao at biigroup.cn (xmgao at biigroup.cn) Date: Wed, 19 Apr 2017 17:36:26 +0800 Subject: [getdns-users] A question on stubby References: <2017041914544074037618@biigroup.cn>, Message-ID: <2017041917362502762424@biigroup.cn> Hi Sara, Thanks for your advice. I followed your instructions : update stubby to 1.1.0 version and rebuild it. I use the stubby_one_server.conf as you suggested. But I still encounter the same problem. I print the error msg as follows: [09:29:08.290308] => ENTRY: _getdns_submit_stub_request : MSG: 0x9122658 TYPE: 1 [09:29:08.290426] --- SETUP: upstream_select_stateful : Testing upstreams 0 0 [09:29:08.290436] --- SETUP: upstream_select_stateful : Testing upstreams 1 0 [09:29:08.290443] --- SETUP: upstream_connect : Getting upstream connection: 0x9121fec [09:29:08.290448] --- SETUP: tcp_connect : Creating TCP connection: 0x9121fec [09:29:08.290776] --- SETUP(TLS): tls_create_object : Hostname verification requested for: getdnsapi.net [09:29:08.290790] --- SETUP(TLS): tls_create_object : ERROR: TLS Authentication functionality not available [09:29:08.290802] --- CLEANUP: upstream_failed : FD: 5 Failure during connection setup = 1 [09:29:08.290822] --- SETUP: upstream_select_stateful : Testing upstreams 0 0 [09:29:08.290827] --- SETUP: upstream_select_stateful : Testing upstreams 1 3 [09:29:08.290832] ----- SCHEDULE: upstream_find_for_netreq : MSG: 0x9122658 No valid upstream! [09:29:08.290840] GETDNS_DAEMON: *FAILURE* no valid transports or upstreams available! Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports Regards, Xiaomin xmgao at biigroup.cn From: Sara Dickinson Date: 2017-04-19 16:34 To: libgetdns users list Subject: Re: [getdns-users] A question on stubby On 19 Apr 2017, at 07:54, xmgao at biigroup.cn wrote: Hello everyone, I?m Xiaomin, a young engineer in this field. I?m trying to setup a DNS-over-TLS demo using Stubby recently. Now it works in opportunistic mode, but failed in strict mode with 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field. AFAIK, the server are using Let's encrypt cert, What should I do on client side(stubby) to verify the cert? Do I need make extra configuration on Stubby or openssl? Hi Xiaomin, Thanks for your question. Can you let me know which version of Stubby you are using? I would recommend using the recent 1.1.0 release. To validate a nameserver Stubby needs one of - an authentication domain name or - a SPKI pin The easiest way to set up strict authentication is to use the default configuration file that is in the getdns source code in src/tools/stubby.conf which has this information in for several servers. Then tell Stubby where to find this file by using the ?-C? flag on the command line. I?ve attached the stubby.conf file here for reference. This configuration will run in Strict mode, using all the servers listed. If you want a simple demo then I suggest just using a single server that has a Let?s Encrypt certificate. I?ve created a file for that too using the getdns nameserver and attached it (stubby_one_server.conf). Hope this helps Regards Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmgao at biigroup.cn Wed Apr 19 09:39:03 2017 From: xmgao at biigroup.cn (xmgao at biigroup.cn) Date: Wed, 19 Apr 2017 17:39:03 +0800 Subject: [getdns-users] A question on stubby References: <20170419102523.Horde.IJBXCnv_fIoIvj4ZpTN4vDo@andreasschulze.de> Message-ID: <2017041917385920719027@biigroup.cn> Thanks. But you do not include the 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field in the stubby.conf file. -Xiaomin xmgao at biigroup.cn From: A. Schulze Date: 2017-04-19 16:25 To: libgetdns users list Subject: Re: [getdns-users] A question on stubby xmgao: > Hello everyone, > I?m Xiaomin, a young engineer in this field. I?m trying to setup a > DNS-over-TLS demo using Stubby recently. Now it works in > opportunistic mode, but failed in strict mode with > 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field. AFAIK, > the server are using Let's encrypt cert, What should I do on client > side(stubby) to verify the cert? Do I need make extra configuration > on Stubby or openssl? Hello, I use this configuration: $ cat /etc/resolv.conf nameserver ::1 $ cat /etc/stubby.conf { resolution_type: GETDNS_RESOLUTION_STUB , dns_transport_list: [ GETDNS_TRANSPORT_TLS ] , upstream_recursive_servers: [ { address_data: 2a00:e50:f15c:1000::2:53 , tls_auth_name: "yeti-rr.datev.net" , tls_pubkey_pinset: [ { digest: "sha256" , value: QFWn+jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg= } ] } ] , idle_timeout: 10000 } $ stubby -C /etc/stubby.conf $ dig hostname.bind. txt chaos +short "see https://yeti-rr.datev.net" This forward all requests to the Yeti-DNS Resolver. The Resolver use the same LE certificate on https/443 and domain-s/853. The Resolver is IPv6 only but capable to reach name servers via IPv4 So it /should/ reach the whole internet... BTW. stubby.conf was created (guessing) using information on https://getdnsapi.net/blog/dns-privacy-daemon-stubby/ The example file (src/tools/stubby.conf) mentioned there don't exist in the current release. Any formal documentation on stubby.conf is really required! Andreas _______________________________________________ Users mailing list Users at getdnsapi.net https://getdnsapi.net/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara at sinodun.com Wed Apr 19 09:50:34 2017 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 19 Apr 2017 10:50:34 +0100 Subject: [getdns-users] A question on stubby In-Reply-To: <2017041917362502762424@biigroup.cn> References: <2017041914544074037618@biigroup.cn> <2017041917362502762424@biigroup.cn> Message-ID: <94084081-07DD-4CB2-A502-954258533A66@sinodun.com> Hi Xiaomin, Thanks for the reply and the log output. I suspect that the version of OpenSSL you are using is quite old? You need version 1.0.1 or later for TLS support and version 1.0.2 or later is required for TLS hostname authentication. This message is output if the version is less than 1.0.2. Regards Sara. > On 19 Apr 2017, at 10:36, xmgao at biigroup.cn wrote: > > Hi Sara, > > Thanks for your advice. I followed your instructions : update stubby to 1.1.0 version and rebuild it. I use the stubby_one_server.conf as you suggested. But I still encounter the same problem. I print the error msg as follows: > > [09:29:08.290308] => ENTRY: _getdns_submit_stub_request : MSG: 0x9122658 TYPE: 1 > [09:29:08.290426] --- SETUP: upstream_select_stateful : Testing upstreams 0 0 > [09:29:08.290436] --- SETUP: upstream_select_stateful : Testing upstreams 1 0 > [09:29:08.290443] --- SETUP: upstream_connect : Getting upstream connection: 0x9121fec > [09:29:08.290448] --- SETUP: tcp_connect : Creating TCP connection: 0x9121fec > [09:29:08.290776] --- SETUP(TLS): tls_create_object : Hostname verification requested for: getdnsapi.net > [09:29:08.290790] --- SETUP(TLS): tls_create_object : ERROR: TLS Authentication functionality not available > [09:29:08.290802] --- CLEANUP: upstream_failed : FD: 5 Failure during connection setup = 1 > [09:29:08.290822] --- SETUP: upstream_select_stateful : Testing upstreams 0 0 > [09:29:08.290827] --- SETUP: upstream_select_stateful : Testing upstreams 1 3 > [09:29:08.290832] ----- SCHEDULE: upstream_find_for_netreq : MSG: 0x9122658 No valid upstream! > [09:29:08.290840] GETDNS_DAEMON: *FAILURE* no valid transports or upstreams available! > Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports > > Regards, > Xiaomin > > > xmgao at biigroup.cn > > From: Sara Dickinson > Date: 2017-04-19 16:34 > To: libgetdns users list > Subject: Re: [getdns-users] A question on stubby > >> On 19 Apr 2017, at 07:54, xmgao at biigroup.cn wrote: >> >> Hello everyone, >> I?m Xiaomin, a young engineer in this field. I?m trying to setup a DNS-over-TLS demo using Stubby recently. Now it works in opportunistic mode, but failed in strict mode with 'tls_authentication: GETDNS_AUTHENTICATION_REQUIRED' field. AFAIK, the server are using Let's encrypt cert, What should I do on client side(stubby) to verify the cert? Do I need make extra configuration on Stubby or openssl? > > Hi Xiaomin, > > Thanks for your question. Can you let me know which version of Stubby you are using? I would recommend using the recent 1.1.0 release. > > To validate a nameserver Stubby needs one of > - an authentication domain name or > - a SPKI pin > > The easiest way to set up strict authentication is to use the default configuration file that is in the getdns source code in src/tools/stubby.conf which has this information in for several servers. Then tell Stubby where to find this file by using the ?-C? flag on the command line. I?ve attached the stubby.conf file here for reference. This configuration will run in Strict mode, using all the servers listed. > > If you want a simple demo then I suggest just using a single server that has a Let?s Encrypt certificate. I?ve created a file for that too using the getdns nameserver and attached it (stubby_one_server.conf). > > Hope this helps > > Regards > > Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sca at andreasschulze.de Wed Apr 19 12:37:12 2017 From: sca at andreasschulze.de (A. Schulze) Date: Wed, 19 Apr 2017 14:37:12 +0200 Subject: [getdns-users] A question on stubby In-Reply-To: <2017041917385920719027@biigroup.cn> References: <20170419102523.Horde.IJBXCnv_fIoIvj4ZpTN4vDo@andreasschulze.de> <2017041917385920719027@biigroup.cn> Message-ID: <20170419143712.Horde.aT6Jy3deEbz3tSdmGspmc50@andreasschulze.de> xmgao: > Thanks. But you do not include the 'tls_authentication: > GETDNS_AUTHENTICATION_REQUIRED' field in the stubby.conf file. you're right! without "tls_authentication: GETDNS_AUTHENTICATION_REQUIRED" I may provide wrong tls_auth_name or tls_pubkey_pinset/value and stubby still will answer my queries! unfortunately stubby do not complain about authentication failures. for the archive: the better stubby.conf: { resolution_type: GETDNS_RESOLUTION_STUB , dns_transport_list: [ GETDNS_TRANSPORT_TLS ] , tls_authentication: GETDNS_AUTHENTICATION_REQUIRED , upstream_recursive_servers: [ { address_data: 2a00:e50:f15c:1000::2:53 , tls_auth_name: "yeti-rr.datev.net" , tls_pubkey_pinset: [ { digest: "sha256" , value: QFWn+jgr2FfkRjCw8J77QJbChem3FUGwi9Ntp67SnVg= } ] } ] , idle_timeout: 10000 } $ man stubby.conf No manual entry for stubby.conf without documentation such errors may happen ... Andreas From sara at sinodun.com Wed Apr 26 16:01:25 2017 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 26 Apr 2017 17:01:25 +0100 Subject: [getdns-users] A question on stubby In-Reply-To: <20170419143712.Horde.aT6Jy3deEbz3tSdmGspmc50@andreasschulze.de> References: <20170419102523.Horde.IJBXCnv_fIoIvj4ZpTN4vDo@andreasschulze.de> <2017041917385920719027@biigroup.cn> <20170419143712.Horde.aT6Jy3deEbz3tSdmGspmc50@andreasschulze.de> Message-ID: > On 19 Apr 2017, at 13:37, A. Schulze wrote: > > without documentation such errors may happen ? Hi All, Following up on this I?ve tried to improve the documentation on Stubby by adding more information to the ?Configure Stubby? section of the webpage: https://getdnsapi.net/blog/dns-privacy-daemon-stubby/ This is still a work in progress and additional documentation should be in the next release. Regards Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Apr 27 19:17:50 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Apr 2017 12:17:50 -0700 Subject: [getdns-users] a .service file stubby on systemd systems Message-ID: <8737ct7j8h.fsf@fifthhorseman.net> Hi all-- I've just written a simple systemd unit file for stubby which runs the resolver as a non-privileged user. I propose to ship it in the getdns upstream sources so that downstream distributors can have a canonical reference: https://github.com/getdnsapi/getdns/pull/299 It keeps one elevated privilege so that it's possible to bind to port 53, but otherwise is a non-privileged process, which is probably preferable to running as root. we could reduce the privileges even further by allowing stubby to inherit its listening socket from the system manager (e.g., sd_listen_fds(3)), but that requires more coding work, so i'm starting with this simpler first step. happy to hear feedback about this suggestion! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Apr 28 15:18:43 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Apr 2017 08:18:43 -0700 Subject: [getdns-users] [getdns-api] getdns-1.1.0 released In-Reply-To: References: <99303075-6178-6301-7223-8e94d59f3445@nlnetlabs.nl> Message-ID: <87bmrg5zn0.fsf@fifthhorseman.net> Hi Willem-- On Thu 2017-04-13 21:19:03 +0200, Willem Toorop wrote: > We are pleased to announce release 1.1.0 of our library implementation > of the getdns API. Thanks for this! I note that the library's SONAME has been bumped so it's moved from libgetdns1.so to libgetdns6.so. This implies a backward-incompatible API/ABI change. Most of the changes you mention here are API additions or bugfixes, and as such aren't backward-incompatible. So i think most software that depends on libgetdns can just do a recompile against the new version and it should be fine. But if there are more subtle API inconsistencies that clients need to be aware of but that compilers won't catch automatically (this seems likely, since getdns's API has lots of enums and flexible dict-style configuration), then it's nice to provide some sort of porting guide for clients of the library, so that they don't get burned by doing a "recompile and pray" upgrade operation. Does such a doc exist? as an example from another library, take a look at https://github.com/jstedfast/gmime/blob/master/PORTING. What should users (and package maintainers) of be aware of given this particular backward-incompatible change? Thanks for all the work on getdns! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From willem at nlnetlabs.nl Thu Apr 6 21:39:34 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 6 Apr 2017 23:39:34 +0200 Subject: [getdns-api] Second release candidate for getdns-1.1.0 Message-ID: <2bf5aa6e-e55c-069d-820e-946cfedc91ec@nlnetlabs.nl> Dear all, We have a second release candidate for the new feature release version 1.1.0 of getdns. The first release has been extensively tested and used in the IETF98 Hackathon, which has let to some great hacks!, and also revealed some improvement potentials and even some bugs. This second release candidate addresses those things: * The return_call_reporting extension now also returns the remote end's certificate if the interaction was over TLS. * Stateful connections with and idle_timeout > 0 will not be closed after doing a synchronous request any more. This also involved a bugfix for naked timeout events with Windows. * Stability of the DNSSEC extensions in combination with stateful transports have been improved (and a bugfix in which this combination hang). * A default edns0 padding policy contributed by DKG. * A new function getdns_context_unset_edns_maximum_udp_payload_size() to reset to the default behaviour to have a maximum UDP payload size dependent on the address family; 1432 for IPv4 and 1232 for IPv6 to maximize receptivity. Please review this release candidate carefully, if all is well, the actual release will follow Thursday the 13th of April. link : https://getdnsapi.net/dist/getdns-1.1.0-rc2.tar.gz pgp : https://getdnsapi.net/dist/getdns-1.1.0-rc2.tar.gz sha256: d91ec104b33880ac901f36b8cc01b22f9086fcf7d4ab94c0cbc56336d1f6bec0 ChangeLog ========= * 2017-04-??: Version 1.1.0 * bugfix: Reschedule request timeout when getting the DNSSEC chain. * getdns_context_unset_edns_maximum_udp_payload_size() to reset to default IPv4/IPv6 dependent edns max udp payload size. * Implement sensible default edns0 padding policy. Thanks DKG. * Keep connections open with sync requests too. * Fix of event loops so they do not give up with naked timers with windows. Thanks Christian Huitema. * Include peer certificate with DNS-over-TLS in combination with the return_call_reporting extension. * 2017-03-23: Version 1.1.0-rc1 * More fine grained control over TLS upstream retry and back off behaviour with getdns_context_set_tls_backoff_time() and getdns_context_set_tls_connection_retries(). * New round robin over the available upstreams feaure. Enable with getdns_context_set_round_robin_upstreams() * Bugfix: Queue requests when no sockets available for outgoing queries. * Obey the outstanding query limit with STUB resolution mode too. * Updated stubby config file * Draft MDNS client implementation by Christian Huitema. Enable with --enable-draft-mdns-support to configure * bugfix: Let synchronous queries use fds > MAX_FDSETSIZE; By moving default eventloop from select to poll Thanks Neil Cook * bugfix: authentication failure for self signed cert + only pinset * bugfix: issue with session re-use making authentication appear to fail * 2016-10-19: Version 1.1.0-a2 * Improved TLS connection management * OpenSSL 1.1 support * Stubby, Server version of getdns_query that by default listens on 127.0.0.1 and ::1 and reads config from /etc/stubby.conf and $HOME/.stubby.conf * 2016-07-14: Version 1.1.0a1 * Conversion functions from text strings to getdns native types: getdns_str2dict(), getdns_str2list(), getdns_str2bindata() and getdns_str2int() * A getdns_context_config() function that configures a context with settings given in a getdns_dict * A a getdns_context_set_listen_addresses() function and companion getdns_reply() function to construct simple name servers. * Relocate getdns_query to src/tools and build by default * Enhancements to the logic used to select connection based upstream transports (TCP, TLS) to improve robustness and re-use of connections/upstreams. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 829 bytes Desc: OpenPGP digital signature URL: From willem at nlnetlabs.nl Thu Apr 13 19:19:03 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 13 Apr 2017 21:19:03 +0200 Subject: [getdns-api] getdns-1.1.0 released Message-ID: <99303075-6178-6301-7223-8e94d59f3445@nlnetlabs.nl> Dear all, We are pleased to announce release 1.1.0 of our library implementation of the getdns API. This version comes with the DNS Privacy stub resolver Stubby. Stubby encrypts DNS queries sent from a client machine (desktop or laptop) to a DNS Privacy resolver increasing end user privacy. Stubby is in the early stages of development but is suitable for technical/advanced users. A more generally user-friendly version is on the way! More information about Stubby is here: https://getdnsapi.net/blog/dns-privacy-daemon-stubby/ Stubby will be build by default and will be installed in the ${PREFIX}/bin directory. Also the getdns_query test tool will be build and installed by default now. If you want the library only, you can disable building and installation of those programs with the --without-stubby and --without-getdns_query options to configure. getdns_query (and Stubby) have had functionality added which was not part of the original API specification, but which we think is useful for other applications as well. This includes functions that have been added to deal with parsing and configuring getdns with a configuration file, and functions to serve DNS requests. To handle configuration files, functions were added to convert strings to getdns native types, getdns_str2dict(), getdns_str2list(), getdns_str2bindata() and getdns_str2int(); A getdns_context can then be configured with a resulting getdns_dict with the new getdns_context_config() function. This can reduce the amount of code needed to setup a context in a C program. It also provides default values for extensions and allows the trust anchor and root hints files to be directly specified. For example, the following piece of C code would configure the context to do DNSSEC roadblock avoidance (i.e. validate DNSSEC as stub, fallback to full recursive with hampering middleboxes), with alternative trust-anchor and root-hints. if (GETDNS_RETURN_GOOD == getdns_str2dict( "{ dnssec_roadblock_avoidance: GETDNS_EXTENSION_TRUE" ", dns_root_servers: \"/etc/yeti/named.cache\"" ", dnssec_trust_anchors: \"/etc/yeti/KSK.pub\"" "}", &config_dict)) getdns_context_config(context, config_dict); More detailed (doxygen) documentation about the string to getdns data structure functions, and about configuring getdns_contexts with getdns_dicts is here: https://getdnsapi.net/doxygen/group__Ustring2getdns__data.html https://getdnsapi.net/functions/getdns_context_config.html The getdns_context_set_listen_addresses() function, allows the user to register a request handler function and list of addresses that will be listened on when the eventloop is run. The request handler function will be called when a DNS requests arrives, with the request in getdns reply dict format. The request handler may construct a response to the request and eventually has to call getdns_reply() with that response to answer the request (or NULL to cancel). I will try to provide and example blog post on the website for this functionality shortly. For now, we have the doxygen documentation and the IETF97 hackathon project delaydns which was using this functionality: https://getdnsapi.net/doxygen/group__UServerFunctions.html https://github.com/IETF-Hackathon/delaydns Besides these new functions, we have much improved and more stable and robust scheduling of requests: * The default event loop, which is also used for synchronous requests, is now based on poll() instead of select() and does not inherit select()'s limits any more. * The limit on number of outstanding queries, set with the getdns_context_limit_outstanding_queries() function, will now also be obeyed in stub mode. This was an ommision from the 1.0.0 release. * getdns will now queue up requests that could not be scheduled because of resource limitations, to be rescheduled when resources become available again. We now also have: * a new modus for stub resolving in which queries are scheduled round robin over the upstreams. This can be enabled with the getdns_context_set_round_robin_upstreams() function. * more fine grained control over how TLS upstreams are retried with the getdns_context_set_tls_backoff_time() and the getdns_context_set_tls_connection_retries() function. and * Much improved doxygen documentation. Have a look here: https://getdnsapi.net/doxygen/ Finally, we have a new draft MDNS-client implementation by Christian Huitema. To enable it, use the --enable-draft-mdns-client option to configure. Happy Easter! link : https://getdnsapi.net/dist/getdns-1.1.0.tar.gz pgp : https://getdnsapi.net/dist/getdns-1.1.0.tar.gz.asc sha256: aa47bca275b97f623dc6799cee97d3465fa46521d94bd9892e08e8d5d88f09c3 ChangeLog ========= * 2017-04-13: Version 1.1.0 * bugfix: Check size of tls_auth_name. * Improvements that came from Visual Studio static analysis * Fix to compile with libressl. Thanks phicoh. * Spelling fixes. Thanks Andreas Schulze. * bugfix: Reschedule request timeout when getting the DNSSEC chain. * getdns_context_unset_edns_maximum_udp_payload_size() to reset to default IPv4/IPv6 dependent edns max udp payload size. * Implement sensible default edns0 padding policy. Thanks DKG. * Keep connections open with sync requests too. * Fix of event loops so they do not give up with naked timers with windows. Thanks Christian Huitema. * Include peer certificate with DNS-over-TLS in combination with the return_call_reporting extension. * More fine grained control over TLS upstream retry and back off behaviour with getdns_context_set_tls_backoff_time() and getdns_context_set_tls_connection_retries(). * New round robin over the available upstreams feaure. Enable with getdns_context_set_round_robin_upstreams() * Bugfix: Queue requests when no sockets available for outgoing queries. * Obey the outstanding query limit with STUB resolution mode too. * Updated stubby config file * Draft MDNS client implementation by Christian Huitema. Enable with --enable-draft-mdns-support to configure * bugfix: Let synchronous queries use fds > MAX_FDSETSIZE; By moving default eventloop from select to poll Thanks Neil Cook * bugfix: authentication failure for self signed cert + only pinset * bugfix: issue with session re-use making authentication appear to fail * 2016-10-19: Version 1.1.0-a2 * Improved TLS connection management * OpenSSL 1.1 support * Stubby, Server version of getdns_query that by default listens on 127.0.0.1 and ::1 and reads config from /etc/stubby.conf and $HOME/.stubby.conf * 2016-07-14: Version 1.1.0a1 * Conversion functions from text strings to getdns native types: getdns_str2dict(), getdns_str2list(), getdns_str2bindata() and getdns_str2int() * A getdns_context_config() function that configures a context with settings given in a getdns_dict * A a getdns_context_set_listen_addresses() function and companion getdns_reply() function to construct simple name servers. * Relocate getdns_query to src/tools and build by default * Enhancements to the logic used to select connection based upstream transports (TCP, TLS) to improve robustness and re-use of connections/upstreams. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 829 bytes Desc: OpenPGP digital signature URL: