[getdns-api] getdns 0.3.0 release candidate

[Mankin, Allison]

Some of your typos are very likable, such as hob-by-hob :-)

Could you publish the new API spec on the website?  I think that is what we call “burying the lede” to have it not get announced to the getdnsapi list but only mentioned as part of the tarball.

Al

> On Jul 10, 2015, at 9:40 AM, Willem Toorop <willem at nlnetlabs.nl> wrote:
> 
> Thank you :)   Lots of typos in the release text though.  I'll fix that
> for the actual release..
> 
> Op 10-07-15 om 15:06 schreef Mankin, Allison:
>> Fantastic 
>> 
>> 
>> 
>>> On Jul 10, 2015, at 06:06, Willem Toorop <willem at nlnetlabs.nl> wrote:
>>> 
>> Dear All,
>> 
>> I am pleased to announce the special IETF93 edition release candidate
>> for version 0.3.0 of our getdns API implementation.
>> 
>> Besides bugfixes and DNS parameter updates, this release follows the
>> (yes to be published, but within the tarball) updated version of the
>> API, which has a new function to set a list of transports:
>> getdns_context_set_dns_transport_list().
>> 
>> If only one transport value is specified, it will be the only
>> transport used.  Should it not be available, basic resolution will
>> fail.  Fallback transport options are specified by including multiple
>> values in the list.  The values are GETDNS_TRANSPORT_UDP,
>> GETDNS_TRANSPORT_TCP, GETDNS_TRANSPORT_TLS, or
>> GETDNS_TRANSPORT_STARTTLS. The default is a list containing
>> GETDNS_TRANSPORT_UDP then GETDNS_TRANSPORT_TCP.
>> 
>> Also, for transport options TCP, TLS and STARTTLS, the connection will
>> now always be tried to be kept open and multiple queries will be
>> pipelined over it.  When there are no pending queries, the connection
>> is not closed for a period of time that can be specified with the new
>> API function: getdns_context_set_idle_timeout().
>> 
>> Besides these new transport options, the release has improved DNSSEC
>> support.  Before, when using stub resolution mode, libunbound was
>> still used (in forwarding mode) when one of the DNSSEC extensions was
>> set.  This release has native stub DNSSEC validation on board, so all
>> DNSSEC extensions can now be combined with all the other hob-by-hob
>> communication features available with stub resolution mode, such as
>> the new transport options, cookies and fine grained control over EDNS0
>> options.
>> 
>> To realise native stub validation, both the
>> dnssec_return_validation_chain extension and the
>> getdns_validate_dnssec() function have been thoroughly improved.
>> 
>> Before the dnssec_return_validation_chain extension only returned the
>> chain of DS/DNSKEY's starting at the signers name of the signatures in
>> the answer and authority section of the request.  Now, the extension
>> will also return the support records needed to asses the DNSSEC status
>> of replies without signatures, and even for replies without any RR's
>> at all.  Note that even an empty packet may be BOGUS or INSECURE
>> depending on the proof of non-existence of the DS of the zone for the
>> request of one of its parents.
>> 
>> Also, the dnssec_return_validation_chain extension will try to return
>> a single RRSIG RR per RRset.  The one that it has used itself to asses
>> the DNSSEC status of the RRset.  This to alleviate the eventual
>> validation effort that will be done with the chain.
>> 
>> Note that the improved behaviour can be viewed live on the "Do a
>> query" page of our website: https://getdnsapi.net/query.html
>> 
>> Complementary to this improvement, the getdns_validate_dnssec()
>> function can now also asses DNSSEC status for RRsets without
>> signatures and even empty replies when given such "validation_chain"
>> as the support_records.  As the record_to_validate parameter, complete
>> replies may now be given.  It will deal with everything needed to
>> correctly asses DNSSEC status for a reply, such as (but not limited
>> to) NSEC3 opt-out evaluation and handling of by DNAME synthesized CNAMEs.
>> 
>> Note that this is a release candidate.  It is distributed for you to
>> review before we do an actual release.  Please review this candidate
>> carefully.  If no issues arise the actual 0.3.0 release will follow
>> over one week on the seventeenth of July 2015.
>> 
>> 
>> link   : https://getdnsapi.net/dist/getdns-0.3.0rc1.tar.gz
>> md5    : 27a1100d5d5d70c087b79109d1109ef3
>> sha1   : d79db12590109c826f627417da1b480f67c3839c
>> pgp sig: https://getdnsapi.net/dist/getdns-0.3.0rc1.tar.gz.asc
>> 
>> 
>> ChangeLog
>> =========
>> * 2015-07-??: Version 0.3.0
>> * Unit test for spurious execute bits.  Thanks Paul Wouters.
>> * Added new transport list options in API. The option is now an
>>   ordered list of GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP,
>>   GETDNS_TRANSPORT_TLS, GETDNS_TRANSPORT_STARTTLS.
>> * Added new context setting for idle_timeout
>> * CSYNC RR type
>> * EDNS0 COOKIE option code set to 10
>> * dnssec_return_validation_chain for negative and insecure responses.
>> * dnssec_return_validation_chain return a single RRSIG on each RRSET
>>   (whenever possible)
>> * getdns_validate_dnssec() accept replies from the replies_tree
>> * getdns_validate_dnssec() asses negative and insecure responses.
>> * Native stub dnssec validation
>> * Implemented getdns_context_set_dnssec_trust_anchors()
>> * Switch freely between stub and recursive mode
>> * getdns_query -k shows default trust anchors
>> * functions and defines to get library and API versions in string and
>>   numeric values: getdns_get_version(), getdns_get_version_number(),
>>   getdns_get_api_version() and getdns_get_api_version_number()
>>> _______________________________________________
>>> getdns-api mailing list
>>> getdns-api at vpnc.org
>>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4718 bytes
Desc: not available
URL: <http://getdnsapi.net/pipermail/spec/attachments/20150710/6dd2d738/attachment.bin>