From shollenbeck at verisign.com Sun Nov 1 02:42:15 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Sun, 1 Nov 2015 02:42:15 +0000 Subject: [getdns-users] getdns 0.5.0 release In-Reply-To: <56327392.6060502@nlnetlabs.nl> References: <56327392.6060502@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A0D3165@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Thursday, October 29, 2015 3:29 PM > To: libgetdns users list > Subject: [getdns-users] getdns 0.5.0 release > > Dear All, > > We have a new release version 0.5.0 of getdns. I just pushed an update to the PHP language bindings. I'm pretty sure I captured and implemented all off the needed changes. Scott From dkg at fifthhorseman.net Sun Nov 1 07:26:55 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 01 Nov 2015 16:26:55 +0900 Subject: [getdns-users] privacy work on getdns at the IETF 94 Hackathon Message-ID: <87a8qyrxhc.fsf@alice.fifthhorseman.net> Hi GetDNS folks-- several of us did work on GetDNS at the IETF 94 hackathon. I focused on DNS privacy. I've pushed a patch queue here: https://github.com/getdnsapi/getdns/pull/118 This implements two new policies that can be set on the getdns_context object: client_subnet_private: Background: https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-04 defines a way for recursive resolvers to report their client's IP addresses to the authoritative server. This is a privacy concern, because clients might not want their IP addresses to be revealed to the authoritative resolver. If client_subnet_private is turned on while a getdns_context is in stub mode, it will, ask its upstream resolver to not reveal anything about the stub's IP address to the authoritative. tls_query_padding_blocksize: Background: https://tools.ietf.org/html/draft-mayrhofer-edns0-padding-01 Doing DNS queries over TLS still leaks the size of the query itself. This means, for example, that if i query for cats.example, it will be 3 octets shorter than a query for kittens.example. This leaks information that can be combined with other information to reveal the actual queries sent. I implemented a simple policy to have getdns pad all queries to a multiple of a desired size (the TLS and TCP and IP and L1 overhead is not included in this measurement). As a demonstration, i used this to query 185.49.141.38 for both "example.com" and "www.example.com". The ethernet frame size for each query based on different transports is shown in the table below: Transport | example.com | www.example.com --------------------------+--------------+------------------- cleartext UDP | 82 octets | 86 octets cleartext TCP | 108 octets | 112 octets TLS over TCP | 137 octets | 141 octets padded(512) TLS over TCP | 609 octets | 609 octets This doesn't solve all the leakage, of course (e.g. the responses aren't being padded). And it's not clear that this policy (pad to a multiple of K octets ignoring TLS and TCP and IP and L1 overhead) is the best padding policy. I welcome suggestions for better padding policies. Note: i randomly chose an arbitrary value for the option here out of the Local and Experimental space. It'd be great if we could get a normal option value assigned. I'd be happy to hear any feedback about these changes. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Nov 1 15:41:41 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 02 Nov 2015 00:41:41 +0900 Subject: [getdns-users] privacy work on getdns at the IETF 94 Hackathon In-Reply-To: <22069.50199.500847.533436@tale.kendall.corp.akamai.com> References: <87a8qyrxhc.fsf@alice.fifthhorseman.net> <22069.50199.500847.533436@tale.kendall.corp.akamai.com> Message-ID: <8737wpsp56.fsf@alice.fifthhorseman.net> On Sun 2015-11-01 16:49:43 +0900, David C Lawrence wrote: > Daniel Kahn Gillmor writes: >> client_subnet_private: >> >> https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-04 > > Thanks for doing this! I'm very happy to see library support for this > added. My only question would be whether you could make it so people > could specify exactly how much they're willing to reveal, rather than > complete anonymity. Thanks for the prompt review, David! I was concerned about producing an API that would be more complicated than developers would know how to use reliably -- let alone exposing this choice to regular users directly. It seems to me that we don't have a lot of data about what the risks are for revealing only a portion of your IP address to a server. I suspect it depends on the distribution of e-mail addresses querying some particular name, since that would affect how large the anonymity set is. If we wanted an even more complete API, we could also allow users to make a claim about what IP address to put in the ADDRESS field of the RDATA. (and if we don't let the user set that, then the library itself has to fill in the ADDRESS field with something -- where should it get that information from? If the getdns client is behind a NAT, should it publish its own internal address? So i opted for the simple and more-clearly understood privacy approach (ask DNS recursors to behave like blinded resolvers), rather than these more nuanced parameters. If you want to make an argument about what kind of configuration choices should be made for a more nuanced API, i'm happy to hear it, but please keep in mind that simpler is better in general! all the best, --dkg From dkg at fifthhorseman.net Wed Nov 4 22:23:30 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 05 Nov 2015 07:23:30 +0900 Subject: [getdns-users] why do we link libgetdns.so to dlopen? Message-ID: <87lhado13x.fsf@alice.fifthhorseman.net> i noticed that libgetdns.so is being linked against libdl, but i don't think we're using dlopen or any of the other functions exported from ldl. fwict, ./configure is adding -ldl because of m4/acx_openssl.m4, which claims: # openssl engine functionality needs dlopen(). BAKLIBS="$LIBS" AC_SEARCH_LIBS([dlopen], [dl]) if test "$LIBS" != "$BAKLIBS"; then LIBSSL_LIBS="$LIBSSL_LIBS -ldl" fi However, we're not using OpenSSL Engine support directly. If some library user wants to initialize openssl's engine support, they should be able to do that with OpenSSL itself, and then they should be able to get libcrypto and/or libssl to use libdl directly. On some minimal systems, libcrypto and libssl might be built without engine support at all; in that case, libgetdns is adding a superfluous dependency to the linker. I don't know the what the getdns policy is about tweaking the files in m4/, but maybe the following patch can be safely applied? diff --git a/m4/acx_openssl.m4 b/m4/acx_openssl.m4 index 87507dc..059a670 100644 --- a/m4/acx_openssl.m4 +++ b/m4/acx_openssl.m4 @@ -95,12 +95,6 @@ AC_DEFUN([ACX_SSL_CHECKS], [ fi AC_SUBST(HAVE_SSL) AC_SUBST(RUNTIME_PATH) - # openssl engine functionality needs dlopen(). - BAKLIBS="$LIBS" - AC_SEARCH_LIBS([dlopen], [dl]) - if test "$LIBS" != "$BAKLIBS"; then - LIBSSL_LIBS="$LIBSSL_LIBS -ldl" - fi fi AC_CHECK_HEADERS([openssl/ssl.h],,, [AC_INCLUDES_DEFAULT]) AC_CHECK_HEADERS([openssl/err.h],,, [AC_INCLUDES_DEFAULT]) wdyt? --dkg From wouter at nlnetlabs.nl Wed Nov 4 22:53:41 2015 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed, 04 Nov 2015 23:53:41 +0100 Subject: [getdns-users] why do we link libgetdns.so to dlopen? In-Reply-To: <87lhado13x.fsf@alice.fifthhorseman.net> References: <87lhado13x.fsf@alice.fifthhorseman.net> Message-ID: <563A8C75.6090504@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Daniel, On 11/04/2015 11:23 PM, Daniel Kahn Gillmor wrote: > i noticed that libgetdns.so is being linked against libdl, but i > don't think we're using dlopen or any of the other functions > exported from ldl. > > fwict, ./configure is adding -ldl because of m4/acx_openssl.m4, > which claims: > > # openssl engine functionality needs dlopen(). BAKLIBS="$LIBS" > AC_SEARCH_LIBS([dlopen], [dl]) if test "$LIBS" != "$BAKLIBS"; then > LIBSSL_LIBS="$LIBSSL_LIBS -ldl" fi > > However, we're not using OpenSSL Engine support directly. If some > library user wants to initialize openssl's engine support, they > should be able to do that with OpenSSL itself, and then they should > be able to get libcrypto and/or libssl to use libdl directly. But that is not how the linker works, I understand you would like it to. > > On some minimal systems, libcrypto and libssl might be built > without engine support at all; in that case, libgetdns is adding a > superfluous dependency to the linker. Regardless of what calls getdns uses, the dependency of openssl on libdl has to be satisfied for the linker to succeed. > > I don't know the what the getdns policy is about tweaking the files > in m4/, but maybe the following patch can be safely applied? No, you cannot safely apply that patch. The library will not link properly (at compile time or at run time, not sure) for some setups/platforms. Leaving out -ldl when possible would be a nice patch (that I would also like for unbound and NSD). Best regards, Wouter > > diff --git a/m4/acx_openssl.m4 b/m4/acx_openssl.m4 index > 87507dc..059a670 100644 --- a/m4/acx_openssl.m4 +++ > b/m4/acx_openssl.m4 @@ -95,12 +95,6 @@ AC_DEFUN([ACX_SSL_CHECKS], > [ fi AC_SUBST(HAVE_SSL) AC_SUBST(RUNTIME_PATH) - # openssl engine > functionality needs dlopen(). - BAKLIBS="$LIBS" - > AC_SEARCH_LIBS([dlopen], [dl]) - if test "$LIBS" != "$BAKLIBS"; > then - LIBSSL_LIBS="$LIBSSL_LIBS -ldl" - fi fi > AC_CHECK_HEADERS([openssl/ssl.h],,, [AC_INCLUDES_DEFAULT]) > AC_CHECK_HEADERS([openssl/err.h],,, [AC_INCLUDES_DEFAULT]) > > > wdyt? > > --dkg _______________________________________________ Users mailing > list Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWOox0AAoJEJ9vHC1+BF+NlkcP/ixzETnGIvxvaRQpZfqHdLux Q6QfR2zbq8qXjIpqmGjaK2VAuDTqpk5OSoPIVCNZON394OPEtjVbKhBkZFrcxkud evU/P2NxfYYQVN7QBg6L07NkmCzihbumWOkPvhB2ZmLhnV7sJBHcYnVGNsXbnqWa o6D3HFy3nuzVgq7YZVka5bs4aCfgHrE0KlsEELg2aoVn/AQ+zEyk+qcey6Q/CI9k 0iEZ+f3N1X5pcoSnuT4XTfx85WWmOrVYO8dUeM/0vlEsj4t2QQN1DozEPBg7WFPy 7TtdrGNIOnf1WWWAtoI+XdYF6jkWyav+E+i5y6rL94xolmRaOSTZNKKvd3Xr1zZi 3WrvfAnibwhRqJrq7/a2rlmfRwUyGZ3Mrvdk/E1qQOvetN2L/b6rPEn3zpSqXm47 IEyQUPyrgFBI4NYg5sSH+64yRJuT52SmXL1aN6Hazudp/HWUy8a9s4x0baJ6YBKm 2OE9ZkjRgCJbRu+vnD9F7zcC740CW9W1t0PzBqrNXcxPxMb0HLA4WqpQjUDCJ/Db PIVJ+wJ1Un6BysxVzL+m+SevwCQkA/F+qBBNX/iPKdu9EzYo51MBuTGpRXU6/oV1 vGi/PFkIwj23Z9FVBXGDlshbd85yqyawKSayyA30WnCuI5EXvCbWxjpcswVZ1VmK cNMy7isp5u7cJI1x21bC =ttFd -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Wed Nov 4 23:14:48 2015 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 05 Nov 2015 00:14:48 +0100 Subject: [getdns-users] why do we link libgetdns.so to dlopen? In-Reply-To: <563A8C75.6090504@nlnetlabs.nl> References: <87lhado13x.fsf@alice.fifthhorseman.net> <563A8C75.6090504@nlnetlabs.nl> Message-ID: <563A9168.2050407@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Daniel, On 11/04/2015 11:53 PM, W.C.A. Wijngaards wrote: > Hi Daniel, > > On 11/04/2015 11:23 PM, Daniel Kahn Gillmor wrote: >> i noticed that libgetdns.so is being linked against libdl, but i >> don't think we're using dlopen or any of the other functions >> exported from ldl. > >> fwict, ./configure is adding -ldl because of m4/acx_openssl.m4, >> which claims: > >> # openssl engine functionality needs dlopen(). BAKLIBS="$LIBS" >> AC_SEARCH_LIBS([dlopen], [dl]) if test "$LIBS" != "$BAKLIBS"; >> then LIBSSL_LIBS="$LIBSSL_LIBS -ldl" fi Testing that, I see that for getdns and Unbound the patch is safe, because it is tested (but more properly) in ACX_LIB_SSL. Best regards, Wouter > >> However, we're not using OpenSSL Engine support directly. If >> some library user wants to initialize openssl's engine support, >> they should be able to do that with OpenSSL itself, and then they >> should be able to get libcrypto and/or libssl to use libdl >> directly. > > But that is not how the linker works, I understand you would like > it to. > > >> On some minimal systems, libcrypto and libssl might be built >> without engine support at all; in that case, libgetdns is adding >> a superfluous dependency to the linker. > > Regardless of what calls getdns uses, the dependency of openssl on > libdl has to be satisfied for the linker to succeed. > > >> I don't know the what the getdns policy is about tweaking the >> files in m4/, but maybe the following patch can be safely >> applied? > > No, you cannot safely apply that patch. The library will not link > properly (at compile time or at run time, not sure) for some > setups/platforms. Leaving out -ldl when possible would be a nice > patch (that I would also like for unbound and NSD). > > Best regards, Wouter > > >> diff --git a/m4/acx_openssl.m4 b/m4/acx_openssl.m4 index >> 87507dc..059a670 100644 --- a/m4/acx_openssl.m4 +++ >> b/m4/acx_openssl.m4 @@ -95,12 +95,6 @@ >> AC_DEFUN([ACX_SSL_CHECKS], [ fi AC_SUBST(HAVE_SSL) >> AC_SUBST(RUNTIME_PATH) - # openssl engine functionality needs >> dlopen(). - BAKLIBS="$LIBS" - AC_SEARCH_LIBS([dlopen], [dl]) - if >> test "$LIBS" != "$BAKLIBS"; then - LIBSSL_LIBS="$LIBSSL_LIBS >> -ldl" - fi fi AC_CHECK_HEADERS([openssl/ssl.h],,, >> [AC_INCLUDES_DEFAULT]) AC_CHECK_HEADERS([openssl/err.h],,, >> [AC_INCLUDES_DEFAULT]) > > >> wdyt? > >> --dkg _______________________________________________ Users >> mailing list Users at getdnsapi.net >> http://getdnsapi.net/mailman/listinfo/users > > > _______________________________________________ Users mailing list > Users at getdnsapi.net http://getdnsapi.net/mailman/listinfo/users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWOpFoAAoJEJ9vHC1+BF+NWqUP/iC5IUhep9tE2fkSoJLP7lEL 4kd1g+TdDKsSmXZChyguFQf15tYL9PlEFUMUX9RVMqGD03g22pjPuYNtCXe3Rfgz s2G79xcw8zErlqq8mgUHzfZRBX3uGk7VyQSOqF+2sFIMlinoc61Bbrbpslxttejs 4+ZqrnKFZmhb/QYiPKdXfz7/z6Euw3NkAFm0bwOlnIW9WDVkKqVeAOvM85EiTTfx JOBqohteAlEU4guIuD+DLIGioAkqXewfRiObXnJ/xkF8lM2O2kiUrd0VXkMBrRI3 VVYCBF/n9+u7FZhpqukDNkGjwqJCD+k5YkQAISA1iWCT+Po//KFoV7qHtC2ZA7e6 bqg1dOwmCrAQNtyglw9vWa4FOoJwwYXwE+fl09ZMfwl5/anBmcRrTsRcK4h9wD2T d4jfWZv6V1z28zeLjQ7LhLJ0I6miT6KCsjyS+GUqThZxypqH+zMch6vUOa0moFKu 4MPJJSbrGeRE3vjofTnDrrCv75bbF2bFmTGpR1V6vfNqQWXks9yMYvC8rYpKK3GX 78g3Px3OcIgS2IB0+0g77GXW4Lq8qLBQtUZyFK8UjOhSVpOAZufERH8QPPHjNNav Zi4WW51vtPIimEBvuZlkqeFGs9RhXdkTraPovunoUHKnH2j9xvNq1gdXMUD1DOTQ UdYHVtMCvh2vXY7AdCwA =Uia9 -----END PGP SIGNATURE----- From edmonds at debian.org Wed Nov 4 23:35:22 2015 From: edmonds at debian.org (Robert Edmonds) Date: Wed, 4 Nov 2015 18:35:22 -0500 Subject: [getdns-users] why do we link libgetdns.so to dlopen? In-Reply-To: <563A8C75.6090504@nlnetlabs.nl> References: <87lhado13x.fsf@alice.fifthhorseman.net> <563A8C75.6090504@nlnetlabs.nl> Message-ID: <20151104233522.GA31753@mycre.ws> W.C.A. Wijngaards wrote: > Hi Daniel, > > On 11/04/2015 11:23 PM, Daniel Kahn Gillmor wrote: > > i noticed that libgetdns.so is being linked against libdl, but i > > don't think we're using dlopen or any of the other functions > > exported from ldl. > > > > fwict, ./configure is adding -ldl because of m4/acx_openssl.m4, > > which claims: > > > > # openssl engine functionality needs dlopen(). BAKLIBS="$LIBS" > > AC_SEARCH_LIBS([dlopen], [dl]) if test "$LIBS" != "$BAKLIBS"; then > > LIBSSL_LIBS="$LIBSSL_LIBS -ldl" fi > > > > However, we're not using OpenSSL Engine support directly. If some > > library user wants to initialize openssl's engine support, they > > should be able to do that with OpenSSL itself, and then they should > > be able to get libcrypto and/or libssl to use libdl directly. > > But that is not how the linker works, I understand you would like it to. On the systems that I'm familiar with (GNU/Linux, FreeBSD), that is how the runtime linker does work. Libraries needed indirectly are located recursively. In fact the GNU 'ldd' utility has an option ('-u') to print "unused direct dependencies". But I don't believe this kind of behavior is regulated by the relevant standards (POSIX, C?). > > On some minimal systems, libcrypto and libssl might be built > > without engine support at all; in that case, libgetdns is adding a > > superfluous dependency to the linker. > > Regardless of what calls getdns uses, the dependency of openssl on > libdl has to be satisfied for the linker to succeed. For shared libraries, the linker reads the ELF sections of libssl.so and finds that it depends on libdl :-) Static libraries don't have a similar way to pass transitive dependencies, so they end up needing the dependencies spelled out explicitly when linking statically. If you use the pkg-config system (I don't believe getdns does, though), you can have pkg-config generate the minimal set of libraries needed dynamically when invoked with "pkg-config --libs", and the complete set of libraries needed statically when invoked with "pkg-config --libs --static". But not everyone uses pkg-config, of course. > No, you cannot safely apply that patch. The library will not link > properly (at compile time or at run time, not sure) for some > setups/platforms. Leaving out -ldl when possible would be a nice > patch (that I would also like for unbound and NSD). Do you know of any specific setups/platforms that would actually fail (when linking dynamically) if the full set of direct library dependencies + transitive library dependencies are not spelled out at compile/link time? Just curious. (Perhaps Windows? Does Windows even have dlopen?) -- Robert Edmonds edmonds at debian.org From willem at nlnetlabs.nl Wed Nov 11 13:55:43 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 11 Nov 2015 14:55:43 +0100 Subject: [getdns-users] Candidate for the IETF94 hackathon results release version 0.5.1 of getdns Message-ID: <564348DF.1070308@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have a candidate for the special IETF94 hackathon results release; version 0.5.1 of getdns. This release contains all contributions added during the hackathon helt at the IETF94 in Yokahama. The included contributions are: * EDNS(0) padding option With this option, the query size will be padded to be a multiple of a block size when queried over GETDNS_TRANSPORT_TLS transport, to eliminate guessing the query by analyzing query sizes. The block size can be set with getdns_context_set_tls_query_padding_blocksize() function. * An EDNS client subnet private option With this option EDNS client subnet aware upstreams are asked to not reveal the originating network of the query. * The return_call_debugging extensions This extension was already in the API, but had not been implemented yet. It returns "meta" information about a query in the response dict (under the name "call_debugging". On top of the returned information which was already described in the API spec, this version also returns information about the transport eventually used to perform the query, and (if applicable) whether authentication succeeded. * A dnssec_roadblock_avoidance extension When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry recursive resolution mode. This is the simplest form of passive roadblock detection and avoidance. For a very extensive overview of the types of roadblock, see: draft- ietf-dnsop-dnssec-roadblock-avoidance. Use the --enable-draft- dnssec-roadblock-avoidance option to configure to compile with this extension. Please review this candidate carefully. If no issues arrise the actual release will follow Wednesday the 18th of November 2015. link: https://getdnsapi.net/dist/getdns-0.5.1rc1.tar.gz md5 : cf4fa710cb733b90ae7d512dbb31c7d1 sha1: f3ca92884a9b0b5cd401b57ad9c5fa1c1646e9b6 pgp : https://getdnsapi.net/dist/getdns-0.5.1rc1.tar.gz.asc ChangeLog ========= * Bugfix: growing upstreams arrow. * Bugfix: Segfault on timeout in specific conditions * Bugfix: install getdns_extra.h from build location * Bugfix: Don't let cookies overwrite existing EDNS0 options * Don't link libdl * The EDNS(0) Padding Option (draft-mayrhofer-edns0-padding). When using DNS over TLS, query sizes will be padded to multiples of a block size given with: getdns_context_set_tls_query_padding_blocksize() * An EDNS client subnet private option, that will ask a EDNS client subnet aware resolver to not reveal any details about the originating network. See: draft-ietf-dnsop-edns-client-subnet Set with: getdns_context_set_edns_client_subnet_private() * The return_call_debugging extension. The extension will also return the transport used on top of the information about the request which is described in the API spec. * A dnssec_roadblock_avoidance extension. When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry rescursive resolution mode. This is the simplest form of passive roadblock detection and avoidance: draft-ietf-dnsop-dnssec-roadblock- avoidance. Use the --enable-draft-dnssec-roadblock-avoidance option to configure to compile with this extension. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWQ0jfAAoJEOX4+CEvd6SYUEwP/Ra+2Z8QIW6afCun3OFKgjZI uRD3DXJR3fZlU4SNk7o/B2f4ae6j1ZMniII4Hm7VlqR0vGowzjzPxge8P8k2tWt2 +sNkUBYtB9ggsqplJy/ucypIg00UKmaEcF6stzhZAzsj669f/mDBtFzAQbtcJfMi ZhMtyTarcr0jm6Wixq9KkxAW/4HE/+lgNLDPFvVXHHtE8AKD8sx61RSgobhM24rS X58mGrAUbNyJlX6vpldeCUSMUWWbgMnuKOB2IszXgfGlz9d40d52uyy8Jfzii5a6 ZQ7GzKxjkOd7TlLWZAJZqPeUcDFuX9F7Pw07MXBRBTgj7efcAdx+pw5tbq7g4J0B nTdlgnPPLLcztktfmFtYOgn/bRM/X43OFLTHH44f5A1747RMzoXS9+lsGBy0iI+b huV7KHq7miIndP9XrqLI22d6j37ROG4NPY33L1RUCfJeNYE3Dlc3ivrpwYP3aUwb HYY0KJK7AYKhXbbGAcB8jIXMXKA3TX7E146JvDFEbFYMMOXD0tYoFVGFHCJRf4Zh m4ygJurHGnndBPoEBpnC//c7dH9BcgVyaizK7c1OjoIDSv8/ja6MYFMbnCeVs5Ny r9pUnynnlCgyPJDBAyTRyGCkQLjAjcNG8LZcEVcLw7D+aMtLdrXtzoB+KzTSwqx1 g+U8/exFXaYT4NwwyzDW =mnL0 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Thu Nov 12 23:41:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Nov 2015 18:41:35 -0500 Subject: [getdns-users] Candidate for the IETF94 hackathon results release version 0.5.1 of getdns In-Reply-To: <564348DF.1070308@nlnetlabs.nl> References: <564348DF.1070308@nlnetlabs.nl> Message-ID: <87fv0an5u8.fsf@alice.fifthhorseman.net> On Wed 2015-11-11 08:55:43 -0500, Willem Toorop wrote: > We have a candidate for the special IETF94 hackathon results release; > version 0.5.1 of getdns. This release candidate is now available in the debian experimental apt repository: https://packages.qa.debian.org/g/getdns/news/20151112T221955Z.html https://buildd.debian.org/status/logs.php?arch=&pkg=getdns Regards, --dkg From willem at nlnetlabs.nl Wed Nov 18 23:41:05 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 19 Nov 2015 01:41:05 +0200 Subject: [getdns-users] getdns 0.5.1 released Message-ID: <564D0C91.8070901@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have special RIPE71 release, version 0.5.1 of getdns. This release contains all contributions added during the hackathon helt at the IETF94 in Yokahama; carefully reviewed and polished. The included contributions are: * EDNS(0) padding option With this option, the query size will be padded to be a multiple of a block size when queried over GETDNS_TRANSPORT_TLS transport, to eliminate guessing the query by analyzing query sizes. The block size can be set with getdns_context_set_tls_query_padding_blocksize() function. * An EDNS client subnet private option With this option EDNS client subnet aware upstreams are asked to not reveal the originating network of the query. * The return_call_debugging extensions This extension was already in the API, but had not been implemented yet. It returns "meta" information about a query in the response dict (under the name "call_debugging". On top of the returned information which was already described in the API spec, this version also returns information about the transport eventually used to perform the query, and (if applicable) whether authentication succeeded. * A dnssec_roadblock_avoidance extension When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry recursive resolution mode. This is the simplest form of passive roadblock detection and avoidance. For a very extensive overview of the types of roadblock, see: draft- ietf-dnsop-dnssec-roadblock-avoidance. Use the --enable-draft- dnssec-roadblock-avoidance option to configure to compile with this extension. Besides these additions contains a few bugfixes too. For an complete overview see the ChangeLog. link: https://getdnsapi.net/dist/getdns-0.5.1.tar.gz md5 : 1be0a47ff0877d4cef19161a8b9f8daa sha1: 9383e7f2f2cfbeaa60e46cd0d7b566b4e9b3db13 pgp : https://getdnsapi.net/dist/getdns-0.5.1.tar.gz.asc ChangeLog ========= * 2015-11-18: Version 0.5.1 * Bugfix: growing upstreams arrow. * Bugfix: Segfault on timeout in specific conditions * Bugfix: install getdns_extra.h from build location * Bugfix: Don't let cookies overwrite existing EDNS0 options * Don't link libdl * The EDNS(0) Padding Option (draft-mayrhofer-edns0-padding). When using DNS over TLS, query sizes will be padded to multiples of a block size given with: getdns_context_set_tls_query_padding_blocksize() * An EDNS client subnet private option, that will ask a EDNS client subnet aware resolver to not reveal any details about the originating network. See: draft-ietf-dnsop-edns-client-subnet Set with: getdns_context_set_edns_client_subnet_private() * The return_call_debugging extension. The extension will also return the transport used on top of the information about the request which is described in the API spec. * A dnssec_roadblock_avoidance extension. When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry rescursive resolution mode. This is the simplest form of passive roadblock detection and avoidance: draft-ietf-dnsop-dnssec-roadblock- avoidance. Use the --enable-draft-dnssec-roadblock-avoidance option to configure to compile with this extension. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWTQyRAAoJEOX4+CEvd6SY1fkQAJxqXx0r6WE/NZMiOhP1csb8 konaiR48RsAKa9BOe54DpynuP7ZSb0gz615+qvvjBORvp4N3n5ETXbhFkVwhh+5W AWAuTV4J3QIifek8KYk1y7ovtaIwVtPuxT+lTpszs1m5ZioaclcEXflXDiu94NRy cfPrJlejO2E5YFVLcYD0/7mowG3Qp5wnsy1DZgNuiYkhc78DLlSSmuzr17cyTIb2 1/F24HU5Etfs5HPHIslTJ5uX53WY7KnlP7cmTQAXb7Oi/yuqCaT72jWIUcUaOsxy 5UA9oD/dtv5Hib6Tw7Re/RKwEiTiNMq7hS54A/lll5FYbs9wEyAeqprtFYZyv4+B SRqVcs2bIhbZAnBfNeqI2wdJhjcbmu9d6Sdd8ElWXSGnQ7CqCu4yy9AUVzrm3zEl 55ygJXcvBTl2c31/6atFA8kV0/kqRCPgt9BaemKRVxbuuU+gI/Ucc7xZn6e6j+/y oYk/1rOdOtE9Y9uKR+kkbc0lmSETaUa5kct9gEXVmm518S1QRqtqRKmI2XTQKM0r Lf02vvOepEIxSEXTrBtUn0TVAyWFfZN5pebF8RJa9GqwdyOFRqMrTcfp/8Qa3lGv xgkhunkyU8XlQPyTlMszVGtE8Aho3tW2/Do5bVNDEyIiUP7Ikot4DLG3ng+I9tA1 S8HOp2YIvWOmKBV3jJKY =ldCg -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Thu Nov 19 16:14:52 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Nov 2015 11:14:52 -0500 Subject: [getdns-users] getdns 0.5.1 released In-Reply-To: <564D0C91.8070901@nlnetlabs.nl> References: <564D0C91.8070901@nlnetlabs.nl> Message-ID: <87fv02arur.fsf@alice.fifthhorseman.net> On Wed 2015-11-18 18:41:05 -0500, Willem Toorop wrote: > We have special RIPE71 release, version 0.5.1 of getdns. This release is already packaged and available for debian unstable. enjoy! --dkg From shollenbeck at verisign.com Fri Nov 20 14:33:31 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Fri, 20 Nov 2015 14:33:31 +0000 Subject: [getdns-users] getdns 0.5.1 released Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A0F3772@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Wednesday, November 18, 2015 6:41 PM > To: libgetdns users list > Subject: [getdns-users] getdns 0.5.1 released > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear All, > > We have special RIPE71 release, version 0.5.1 of getdns. > > This release contains all contributions added during the hackathon helt > at the IETF94 in Yokahama; carefully reviewed and polished. [snip] I've updated and committed the PHP language bindings for compatibility with this release. One thought, though: if the release includes, new, backward compatible features shouldn't the version number be 0.6.0 instead of 0.5.1? As noted on http://semver.org/, one should increment the "MINOR version when you add functionality in a backwards-compatible manner". This release increments the patch version. Scott From edmonds at debian.org Sun Nov 22 23:16:23 2015 From: edmonds at debian.org (Robert Edmonds) Date: Sun, 22 Nov 2015 18:16:23 -0500 Subject: [getdns-users] getdns 0.5.1 released In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A0F3772@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A0F3772@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <20151122231623.GA2821@mycre.ws> Hollenbeck, Scott wrote: > One thought, though: if the release includes, new, backward compatible features shouldn't the version number be 0.6.0 instead of 0.5.1? As noted on http://semver.org/, one should increment the "MINOR version when you add functionality in a backwards-compatible manner". This release increments the patch version. Strictly speaking, the full Semantic Versioning rules don't kick in until 1.0.0, though. 4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. 5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes. -- Robert Edmonds edmonds at debian.org From willem at nlnetlabs.nl Mon Nov 23 09:50:44 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 23 Nov 2015 10:50:44 +0100 Subject: [getdns-users] getdns 0.5.1 released In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A0F3772@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A0F3772@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <5652E174.8080207@nlnetlabs.nl> Op 20-11-15 om 15:33 schreef Hollenbeck, Scott: >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem >> Toorop >> Sent: Wednesday, November 18, 2015 6:41 PM >> To: libgetdns users list >> Subject: [getdns-users] getdns 0.5.1 released >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Dear All, >> >> We have special RIPE71 release, version 0.5.1 of getdns. >> >> This release contains all contributions added during the hackathon helt >> at the IETF94 in Yokahama; carefully reviewed and polished. > > [snip] > > I've updated and committed the PHP language bindings for compatibility with this release. > > One thought, though: if the release includes, new, backward compatible features shouldn't the version number be 0.6.0 instead of 0.5.1? As noted on http://semver.org/, one should increment the "MINOR version when you add functionality in a backwards-compatible manner". This release increments the patch version. Scott, You're right. I'll consider version 0.5.1 to be actually 0.6.0 and will release the upcoming version as 0.6.1 if we have only bugfixes or 0.7.0 if we have added functionality. Thanks for notifying!, -- Willem > > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From jad at sinodun.com Sun Nov 1 04:18:37 2015 From: jad at sinodun.com (John Dickinson) Date: Sun, 01 Nov 2015 13:18:37 +0900 Subject: [getdns-api] call_debugging extension Message-ID: <1C678789-D9D0-4947-BB4A-1E7EBFFDC80B@sinodun.com> I have implemented the call_debugging extension. It raised a couple of issues with the API: 1. Added a tls_auth_status field to tell you if the server was authenticated 2. Added a transport field to tell you what transport was actually used 3. removed start_time and end_time as these are defined as uint64_t?s but the dict can only handle 32 bit ints. 4. Added run_time field to contain end_time - start_time as a uint32_t entire_reply and dnssec_result have not yet been implemented. regards John From jad at sinodun.com Sun Nov 1 04:22:38 2015 From: jad at sinodun.com (John Dickinson) Date: Sun, 01 Nov 2015 13:22:38 +0900 Subject: [getdns-api] call_debugging extension In-Reply-To: <1C678789-D9D0-4947-BB4A-1E7EBFFDC80B@sinodun.com> References: <1C678789-D9D0-4947-BB4A-1E7EBFFDC80B@sinodun.com> Message-ID: <9F1E533F-CA9A-4909-9585-33C038A49A01@sinodun.com> Forgot to say that the code is currently in my fork at https://github.com/johndickinson/getdns/tree/feature/call_debug On 1 Nov 2015, at 13:18, John Dickinson wrote: > I have implemented the call_debugging extension. It raised a couple of > issues with the API: > > 1. Added a tls_auth_status field to tell you if the server was > authenticated > 2. Added a transport field to tell you what transport was actually > used > 3. removed start_time and end_time as these are defined as > uint64_t?s but the dict can only handle 32 bit ints. > 4. Added run_time field to contain end_time - start_time as a > uint32_t > > entire_reply and dnssec_result have not yet been implemented. > > regards > John > _______________________________________________ > spec mailing list > spec at getdnsapi.net From willem at nlnetlabs.nl Wed Nov 11 13:55:46 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 11 Nov 2015 14:55:46 +0100 Subject: [getdns-api] Candidate for the IETF94 hackathon results release version 0.5.1 of getdns Message-ID: <564348E2.2090809@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have a candidate for the special IETF94 hackathon results release; version 0.5.1 of getdns. This release contains all contributions added during the hackathon helt at the IETF94 in Yokahama. The included contributions are: * EDNS(0) padding option With this option, the query size will be padded to be a multiple of a block size when queried over GETDNS_TRANSPORT_TLS transport, to eliminate guessing the query by analyzing query sizes. The block size can be set with getdns_context_set_tls_query_padding_blocksize() function. * An EDNS client subnet private option With this option EDNS client subnet aware upstreams are asked to not reveal the originating network of the query. * The return_call_debugging extensions This extension was already in the API, but had not been implemented yet. It returns "meta" information about a query in the response dict (under the name "call_debugging". On top of the returned information which was already described in the API spec, this version also returns information about the transport eventually used to perform the query, and (if applicable) whether authentication succeeded. * A dnssec_roadblock_avoidance extension When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry recursive resolution mode. This is the simplest form of passive roadblock detection and avoidance. For a very extensive overview of the types of roadblock, see: draft- ietf-dnsop-dnssec-roadblock-avoidance. Use the --enable-draft- dnssec-roadblock-avoidance option to configure to compile with this extension. Please review this candidate carefully. If no issues arrise the actual release will follow Wednesday the 18th of November 2015. link: https://getdnsapi.net/dist/getdns-0.5.1rc1.tar.gz md5 : cf4fa710cb733b90ae7d512dbb31c7d1 sha1: f3ca92884a9b0b5cd401b57ad9c5fa1c1646e9b6 pgp : https://getdnsapi.net/dist/getdns-0.5.1rc1.tar.gz.asc ChangeLog ========= * Bugfix: growing upstreams arrow. * Bugfix: Segfault on timeout in specific conditions * Bugfix: install getdns_extra.h from build location * Bugfix: Don't let cookies overwrite existing EDNS0 options * Don't link libdl * The EDNS(0) Padding Option (draft-mayrhofer-edns0-padding). When using DNS over TLS, query sizes will be padded to multiples of a block size given with: getdns_context_set_tls_query_padding_blocksize() * An EDNS client subnet private option, that will ask a EDNS client subnet aware resolver to not reveal any details about the originating network. See: draft-ietf-dnsop-edns-client-subnet Set with: getdns_context_set_edns_client_subnet_private() * The return_call_debugging extension. The extension will also return the transport used on top of the information about the request which is described in the API spec. * A dnssec_roadblock_avoidance extension. When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry rescursive resolution mode. This is the simplest form of passive roadblock detection and avoidance: draft-ietf-dnsop-dnssec-roadblock- avoidance. Use the --enable-draft-dnssec-roadblock-avoidance option to configure to compile with this extension. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWQ0jiAAoJEOX4+CEvd6SYCEwQAJzG1DSn4KO/BLfAqTDsVisQ a3UDjHZ8doVMUQo8KW5MVgdYgPCSqFxWcb1UUGOf+tAXOeUV8ZTzumNZObLvXuNq ywvH9Vrb74l2jRGuBI4p1suO3BVOby2Go8mKpfEJqJv/yZACZtnDRD+6nHxNhnHj mXqRP7IdkTg8aKe6ogVWmchoQZvjdEUBU+e7F1P/dk7p5S0r7y4purcMyLo/VeVV ifMODjZ2xTZvksUzAYrUSl339kg1/NcJO+s8rH8YCBkgPyZWApvTLGM2DVYk/d8F 1calTcthxOpCNxjLmP0nCPLGvdtnwHrnaKpM0G2u2XY6Qs6EX4KH1OJan381NWDt 80DdBZNyDXRs4JJbo1gKnBZx5MCmwIck/QBr0DAhzWIbHpLHSL7hNaK+DogTl+4M GgdCT3RAXKN9Xm5vSiz+ihNHi4hqGwomVVMn19zLU02J6imBI9xKGDLgbEsxnIOK 5EIb26kR2YxjkD3Jtk21Vl1zNP/33INOAAodH3ylC8LOB183jVy81d3bKkJTUx6q gXscoRwmN+mWtQs4SmliynmgZwzvhKK9A9iERpIsJzbgGMYWAlzsuZClQ0UjQXXw o+RP5iMuqTbkN7WPyZiE8QhtIWh7/uLvyIeiKyWlQV1hs3uwNtRd8IquUGxNRfaU TdtTkLppCS6UyRnjKY0B =wqAU -----END PGP SIGNATURE----- From sara at sinodun.com Fri Nov 13 15:52:24 2015 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 13 Nov 2015 15:52:24 +0000 Subject: [getdns-api] call_debugging extension Message-ID: <5DF25849-1BE4-49F4-B6DC-B0F757247187@sinodun.com> > On 1 Nov 2015, at 04:18, John Dickinson > wrote: > > I have implemented the call_debugging extension. It raised a couple of issues with the API: > > 1. Added a tls_auth_status field to tell you if the server was authenticated > 2. Added a transport field to tell you what transport was actually used > 3. removed start_time and end_time as these are defined as uint64_t?s but the dict can only handle 32 bit ints. > 4. Added run_time field to contain end_time - start_time as a uint32_t Hi All, As a follow up to this I wanted to clarify what changes are being proposed to the official API at this time: 1) Following the implementation in the hackathon there was consensus among the developers that this is very useful general information (not only for debugging purposes) and that a different name e.g. ?return_call_reporting? would be more appropriate. 2) The getdns dict cannot represent uint64_t values and therefore the start_time and end_time will be replaced by a single field called ?run_time? which will be the 'end_time - start_time as a uint32_t? Suggested new text including these changes is below. We would like to agree these changes for the next release, so please voice any objections asap. The ?transport? and ?tis_auth_status? fields mentioned above have been added to the getdns implementation as experimental fields at this point in time, but it would be useful to hear if there is support for adding them to the official API. Regards Sara. 3.6 Extensions Relating to the API An application might want to see additional information for queries such as the length of time it takes for each query to return to the API. Use the return_call_reporting extension. The extension's value (an int) is set toGETDNS_EXTENSION_TRUE to add the name call_reporting (a list) to the top level of the response object. Each member of the list is a dict that represents one call made for the call to the API. Each member has the following names: query_name (a bindata) is the name that was sent query_type (an int) is the type that was queried for query_to (a bindata) is the address to which the query was sent run_time (a bindata) is the difference between the time the successful query started and ended in milliseconds since the epoch, represented as a uint32_t (this does not include time taken for connection set up or transport fallback) entire_reply (a bindata) is the entire response received dnssec_result (an int) is the DNSSEC status, or GETDNS_DNSSEC_NOT_PERFORMED if DNSSEC validation was not performed -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Nov 13 16:12:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Nov 2015 11:12:28 -0500 Subject: [getdns-api] call_debugging extension In-Reply-To: <5DF25849-1BE4-49F4-B6DC-B0F757247187@sinodun.com> References: <5DF25849-1BE4-49F4-B6DC-B0F757247187@sinodun.com> Message-ID: <87mvuhlvyr.fsf@alice.fifthhorseman.net> Hi Sara-- this all sounds reasonable to me, except: On Fri 2015-11-13 10:52:24 -0500, Sara Dickinson wrote: > run_time (a bindata) is the difference between the time the successful > query started and ended in milliseconds since the epoch, represented > as a uint32_t (this does not include time taken for connection set up > or transport fallback) I think you can remove "since the epoch" here. It seems possible that users might want to also measure transport fallback or connection setup, but we should be able to add that information to the dict in future revisions if we get requests for it. --dkg From sara at sinodun.com Fri Nov 13 16:14:45 2015 From: sara at sinodun.com (Sara Dickinson) Date: Fri, 13 Nov 2015 16:14:45 +0000 Subject: [getdns-api] call_debugging extension In-Reply-To: <87mvuhlvyr.fsf@alice.fifthhorseman.net> References: <5DF25849-1BE4-49F4-B6DC-B0F757247187@sinodun.com> <87mvuhlvyr.fsf@alice.fifthhorseman.net> Message-ID: <4EE05237-6235-4887-9FD2-B242699233BE@sinodun.com> > On 13 Nov 2015, at 16:12, Daniel Kahn Gillmor wrote: > > Hi Sara-- > > this all sounds reasonable to me, except: > > On Fri 2015-11-13 10:52:24 -0500, Sara Dickinson wrote: >> run_time (a bindata) is the difference between the time the successful >> query started and ended in milliseconds since the epoch, represented >> as a uint32_t (this does not include time taken for connection set up >> or transport fallback) > > I think you can remove "since the epoch" here. Quite right, a hangover from the previous text?. will remove. Sara. From willem at nlnetlabs.nl Wed Nov 18 23:41:00 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 19 Nov 2015 01:41:00 +0200 Subject: [getdns-api] getdns 0.5.1 released Message-ID: <564D0C8C.9050406@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have special RIPE71 release, version 0.5.1 of getdns. This release contains all contributions added during the hackathon helt at the IETF94 in Yokahama; carefully reviewed and polished. The included contributions are: * EDNS(0) padding option With this option, the query size will be padded to be a multiple of a block size when queried over GETDNS_TRANSPORT_TLS transport, to eliminate guessing the query by analyzing query sizes. The block size can be set with getdns_context_set_tls_query_padding_blocksize() function. * An EDNS client subnet private option With this option EDNS client subnet aware upstreams are asked to not reveal the originating network of the query. * The return_call_debugging extensions This extension was already in the API, but had not been implemented yet. It returns "meta" information about a query in the response dict (under the name "call_debugging". On top of the returned information which was already described in the API spec, this version also returns information about the transport eventually used to perform the query, and (if applicable) whether authentication succeeded. * A dnssec_roadblock_avoidance extension When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry recursive resolution mode. This is the simplest form of passive roadblock detection and avoidance. For a very extensive overview of the types of roadblock, see: draft- ietf-dnsop-dnssec-roadblock-avoidance. Use the --enable-draft- dnssec-roadblock-avoidance option to configure to compile with this extension. Besides these additions contains a few bugfixes too. For an complete overview see the ChangeLog. link: https://getdnsapi.net/dist/getdns-0.5.1.tar.gz md5 : 1be0a47ff0877d4cef19161a8b9f8daa sha1: 9383e7f2f2cfbeaa60e46cd0d7b566b4e9b3db13 pgp : https://getdnsapi.net/dist/getdns-0.5.1.tar.gz.asc ChangeLog ========= * 2015-11-18: Version 0.5.1 * Bugfix: growing upstreams arrow. * Bugfix: Segfault on timeout in specific conditions * Bugfix: install getdns_extra.h from build location * Bugfix: Don't let cookies overwrite existing EDNS0 options * Don't link libdl * The EDNS(0) Padding Option (draft-mayrhofer-edns0-padding). When using DNS over TLS, query sizes will be padded to multiples of a block size given with: getdns_context_set_tls_query_padding_blocksize() * An EDNS client subnet private option, that will ask a EDNS client subnet aware resolver to not reveal any details about the originating network. See: draft-ietf-dnsop-edns-client-subnet Set with: getdns_context_set_edns_client_subnet_private() * The return_call_debugging extension. The extension will also return the transport used on top of the information about the request which is described in the API spec. * A dnssec_roadblock_avoidance extension. When set, the library will work in stub resolution mode and try to get a by DNSSEC validation assessed answer. On BOGUS answers the library will retry rescursive resolution mode. This is the simplest form of passive roadblock detection and avoidance: draft-ietf-dnsop-dnssec-roadblock- avoidance. Use the --enable-draft-dnssec-roadblock-avoidance option to configure to compile with this extension. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWTQyLAAoJEOX4+CEvd6SY61QQAICyt8vp4VQD8SK5Q1iAYd8M eOUevS3ZXcwy0rocOnY6m9mznefxKJ1Mi975cpz7txn2sV9Shtv9fTzzLeZEkHqc 6/kp58S4vQUO7380BcS7+i/YLrw1cqQ90XdWzyYkyQOCEXWMgoj+NISzh/XdR2jJ tAKH8+fcIf9to58hguKLn890XyO7Q4lDGLC8WpipweELVdcEa+sxlU2gbicQRPSA L2LsHkwziYh0u85ErGcyhSgWdH0ebpclzNPQtB0icU7prkiJItU1IKInFCWd6op+ gUcxLGV0sVkRS5oNkBtwAMGiLIOkSiaO336C37w/0khI0yX2NnHaEyzuBXyzCU2V 1G0KtsbO4PykrGMZo89WUYkUP8zpretpt/amGGx/dZTToI+6NDsf2V8tSUstzeAa jxvTPSORWQjXSH/97eyExHGObVHmwCkRw/lBjpk1wJLasw6oAIg55s9zF/MNCw0c E4M1ydAMwZHE/TVPP4amVDRiCd45+GMK0DaLTtC5Ozq/MBCKMAJpES+pBCHan59/ bxOFuhY+YOnlbyoMt/aOhXLV0PHDe+K8SzKHbAg6EIuVRxnR9cOuqVO/HI+9+wcx ShRUXGY++dzwwROeeHNLYHHWNCzuyGVyHWvOs5aQjCHrRb1rI61Yf2P4M+lqVsSY EZlQHlMIqu/esmOFiQ/1 =ad5H -----END PGP SIGNATURE-----