[Stub-resolver] Fwd: [getdns-api] getdns 0.1.5 released

[Willem Toorop]

Thanks!  It did not go completely without a hitch.  Libuv changed a
prototype for which I had to write a configure test;  There were some
symbol conflicts with libunbound on FreeBSD; and I am always struggling
with the administrative overhead of nodejs, but alas;  It is released
and it is a good release!  I am happy with it.

Good work all!

Op 31-10-14 om 17:54 schreef Mankin, Allison:
> Also, beautiful work!!
> 
> On Oct 31, 2014, at 9:44, "Mankin, Allison" <amankin at verisign.com
> <mailto:amankin at verisign.com>> wrote:
> 
>> Hi Angelique, 
>>
>> Please tweet this for us from getdnsapi 
>>
>> Please indicate it is a "features release as well as making some bug
>> fixes" and point to getdnsapi.net <http://getdnsapi.net>
>>
>> Begin forwarded message:
>>
>>> *From:* Willem Toorop <willem at nlnetlabs.nl <mailto:willem at nlnetlabs.nl>>
>>> *Date:* October 31, 2014 at 9:06:13 PDT
>>> *To:* "getdns-api at vpnc.org <mailto:getdns-api at vpnc.org>"
>>> <getdns-api at vpnc.org <mailto:getdns-api at vpnc.org>>
>>> *Subject:* *[getdns-api] getdns 0.1.5 released*
>>>
> Dear all,
> 
> We have a new release, version 0.1.5 of our getdns API implementation.
> 
> This release includes the features from the API that affect hop-by-hop
> communication and apply to stub resolution mode.  The
> "add_opt_parameters" extension from section 3.3 of the spec and all
> getdns_context_set_edns_* functions from Section 8.8 have are now
> implemented.  The GETDNS_TRANSPORT_TCP_ONLY_KEEP_CONNECTIONS_OPEN
> transport mode is also implemented with this release.  IPv6 link-local
> with scope_id upstreams are now supported, both in /etc/resolv.conf as
> via getdns_context_set_upstream_recursive_servers().
> 
> In addition, TCP Fast open is available as an optional feature (linux
> only).  This mechanism enables data exchange during TCP’s initial
> handshake and in doing so it decreases application network latency by
> one full round-trip time.
> 
> To enable these features we have done a major internal rework.  Before,
> we used libunbound for both stub and recursive mode, but to get the
> amount of control needed for the hop-by-hop communication features we
> had to implement stub resolution independently.  For this task we also
> needed to review and refine our extensible event loop mechanism so it is
> able to handle events for multiple simultaneous connections.  (This was
> handled internally by libunbound before)
> 
> As a consequence, this release is binary incompatible with respect to
> the extensible event loop mechanism.  The getdns_context_fd() function
> that facilitated asynchronous processing based on select is no longer
> available.  Instead, getdns_context_run() should be used to perform
> blocking asynchronous processing.  The getdns_context_process_async()
> and getdns_context_get_num_pending_requests() functions remain for
> asynchronous processing in non-blocking fashion.
> 
> Besides our own three event loop extensions shipped alongside the
> library (for libevent, libev and libuv) we are aware of only one
> software package affected by this: the nodejs bindings.  A new release
> of the nodejs bindings fitting this release will follow shortly.
> 
> The internal rework has many improvements as a consequence.  Many
> implementation details that previously had specific code paths for the
> different modus operandi (i.e. sync/recursive, sync/stub,
> async/recursive and async stub) could be merged, resulting in a more
> consistent and easier to maintain code base.  Consequences can already
> be seen in the simultaneous querying for IPv4 and IPv6 addresses and the
> more consistent handling of name spaces, plus the possibility to alter
> name space evaluation order even after a context has been used to sent
> out a query.
> 
> Note that stub resolution will still use libunbound if any of the DNSSEC
> extensions are into play.  Performing stub validation independently from
> libunbound is on the road map for the next release.
> 
> Besides these features, many bugs have been fixed with this release.
> For a complete overview see the ChangeLog section below.
> 
> link   : https://getdnsapi.net/dist/getdns-0.1.5.tar.gz
> md5    : a963594fca8ef2849244aa7290abe7f8
> sha1   : 5da3f54d0929d967039e5d0d54e7125dd13acf38
> pgp sig: https://getdnsapi.net/dist/getdns-0.1.5.tar.gz.asc
> 
> 
> ChangeLog
> =========
> * 2014-10-31: Version 0.1.5
>  * Unit tests for transport settings
>  * Fix: adhere to set maximum UDP payload size
>  * API change: when no maximum UDP payload size is set, outgoing
>    values will adhere to the suggestions in RFC 6891 and may follow
>    a scheme that uses multiple values to maximize receptivity.
>  * Stub mode use 1232 maximum UDP payload size when connecting to an
>    IPv6 upstreams and 1432 with an IPv4 upstream.
>  * Evaluate namespaces (or not) on a per query basis
>  * GETDNS_NAMESPACE_LOCALNAMES namespace now gives just_address_answers
>    only and does not mimic a DNS packet answer anymore
>  * The add_opt_parameters extension
>  * IPv6 scope_id support with link-local addresses.  Both with parsing
>    /etc/resolv.conf and by providing them explicitly via
>    getdns_context_set_upstream_recursive_servers
>  * Query for A and AAAA simultaneously with return_both_v4_and_v6
>  * GETDNS_TRANSPORT_TCP_ONLY_KEEP_CONNECTIONS_OPEN DNS transport
>  * Fix: Answers without RRs in query secion (i.e. REFUSED)
>  * Fix: Return empty response dict on timeout in async mode too
>  * Move spec examples to spec subdirectory
>  * Fix issue#76: Setting UDP Payload size below 512 should not error
>  * Fix: Include OPT RR in response dict always (even without options)
>  * TCP Fast open support (linux only).
>    Enable with the --enable-tcp-fastopen configure option
>  * Bump library version because of binary API change
> 
>>> _______________________________________________
>>> getdns-api mailing list
>>> getdns-api at vpnc.org <mailto:getdns-api at vpnc.org>
>> _______________________________________________
>> stub-resolver mailing list
>> stub-resolver at lists.verisignlabs.com
>> <mailto:stub-resolver at lists.verisignlabs.com>
>> https://lists.verisignlabs.com/mailman/listinfo/stub-resolver
> 
> 
> _______________________________________________
> stub-resolver mailing list
> stub-resolver at lists.verisignlabs.com
> https://lists.verisignlabs.com/mailman/listinfo/stub-resolver
> 

_______________________________________________
stub-resolver mailing list
stub-resolver at lists.verisignlabs.com
https://lists.verisignlabs.com/mailman/listinfo/stub-resolver