From shollenbeck at verisign.com Fri May 1 00:29:08 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Fri, 1 May 2015 00:29:08 +0000 Subject: [getdns-users] getdns_context_run() vs. getdns_context_process_async() In-Reply-To: <55429AD3.2070004@nlnetlabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55422094.4040005@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F49FC0C33@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55429AD3.2070004@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC0F73@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Thursday, April 30, 2015 5:13 PM > To: users at getdnsapi.net > Subject: Re: [getdns-users] getdns_context_run() vs. > getdns_context_process_async() > > Hi Scott, > > I don't know for sure without seeing the code, but might it be that you > destroy the context right after the call to > getdns_context_process_async() ? Yes, exactly. My code for this test case calls getdns_address(),getdns_context_process_async(), and then it destroys the context. > getdns_context_process_async() just has a quick look if it can do some > callbacks immediately. If it cannot, it will not block and exit > immediately. When there are requests still in flight they will be > cancelled on a subsequent call to getdns_context_destroy(). > > If you want to process all outstanding queries, you should use > getdns_context_run(). > > Also getdns_context_process_async() does not work with stub requests > with libevent. The function is a leftover from earlier asynchronous > mechanics and I would actually rather get rid of it. Use > getdns_context_run() instead. OK, I'll update my documentation appropriately - thanks! Scott From shollenbeck at verisign.com Fri May 1 22:33:40 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Fri, 1 May 2015 22:33:40 +0000 Subject: [getdns-users] getdns_validate_dnssec() Example? Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Does anyone have some sample code that includes queries needed to create the lists that can be used to test the getdns_validate_dnssec() function? Scott From shollenbeck at verisign.com Mon May 4 15:51:53 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Mon, 4 May 2015 15:51:53 +0000 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of > Hollenbeck, Scott > Sent: Friday, May 01, 2015 6:34 PM > To: users at getdnsapi.net > Subject: [getdns-users] getdns_validate_dnssec() Example? > > Does anyone have some sample code that includes queries needed to > create the lists that can be used to test the getdns_validate_dnssec() > function? Let me try this a different way. I've written some PHP code that runs, but my call to getdns_validate_dnssec() is returning either GETDNS_RETURN_NO_SUCH_DICT_NAME (305) or GETDNS_RETURN_WRONG_TYPE_REQUESTED (306) depending on the list I pull from the response dictionary in my callback function. Here's my code - can anyone tell me what I need to do to get the lists for the record(s) to be validated and the support records if I'm not accessing them correctly? Scott ---------- From amankin at verisign.com Mon May 4 16:08:39 2015 From: amankin at verisign.com (Mankin, Allison) Date: Mon, 4 May 2015 16:08:39 +0000 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> Scott, I think this extension may not be complete in the C library. It is a more recent arrival to the API. It's been on my TODO list to check details on this. Allison On May 4, 2015, at 11:52, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of >> Hollenbeck, Scott >> Sent: Friday, May 01, 2015 6:34 PM >> To: users at getdnsapi.net >> Subject: [getdns-users] getdns_validate_dnssec() Example? >> >> Does anyone have some sample code that includes queries needed to >> create the lists that can be used to test the getdns_validate_dnssec() >> function? > > Let me try this a different way. I've written some PHP code that runs, but my call to getdns_validate_dnssec() is returning either GETDNS_RETURN_NO_SUCH_DICT_NAME (305) or GETDNS_RETURN_WRONG_TYPE_REQUESTED (306) depending on the list I pull from the response dictionary in my callback function. Here's my code - can anyone tell me what I need to do to get the lists for the record(s) to be validated and the support records if I'm not accessing them correctly? > > Scott > ---------- > > function php_callback($dict, $callbackType, $userArg, $transID) > { > $status = 0; > $result = php_getdns_dict_get_int($dict, "status", $status); > var_dump($status); > if ($status != GETDNS_RESPSTATUS_GOOD) { > return; > } > > // Parse the response to get the records to be validated. > // "replies_tree" produces a 305 when I call php_getdns_validate_dnssec() below. > // "replies_full" produces a 306. > // I *think* I need to get deeper into the list, but what exactly do I need > // to retrieve? > $toVal = 0; > $result = php_getdns_dict_get_list($dict, "replies_tree", $toVal); > var_dump($result); > > // Get the support records. > $supRecs = 0; > $result = php_getdns_dict_get_list($dict, "validation_chain", $supRecs); > var_dump($result); > > // Get the trust anchor. > $anchorDate = 0; > $trustAnchor = php_getdns_root_trust_anchor($anchorDate); > var_dump($trustAnchor); > > // Validate! > $result = php_getdns_validate_dnssec($toVal, $supRecs, $trustAnchor);> var_dump($result); > > php_getdns_dict_destroy($dict); > } > > $context = 0; > $setFromOS = 1; > $result = php_getdns_context_create($context, $setFromOS); > var_dump($result); > > $name = "http://www.getdnsapi.net"; > $reqType = GETDNS_RRTYPE_NS; > > // Set extensions to return DNSSEC validation information. > $extensions = php_getdns_dict_create(); > $result = php_getdns_dict_set_int($extensions, "dnssec_return_validation_chain", GETDNS_EXTENSION_TRUE); > > $transID = ""; > $userArgs[0] = "php_callback"; > $userArgs[1] = "User args test 1"; > $result = php_getdns_general($context, $name, $reqType, $extensions, $userArgs, $transID); > php_getdns_dict_destroy($extensions); > var_dump($result, $transID); > if ($result == GETDNS_RETURN_GOOD) { > php_getdns_context_run($context); > } > > php_getdns_context_destroy($context); > > ?> > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From shollenbeck at verisign.com Tue May 5 12:35:00 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Tue, 5 May 2015 12:35:00 +0000 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC3D0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Mankin, > Allison > Sent: Monday, May 04, 2015 12:09 PM > To: libgetdns users list > Subject: Re: [getdns-users] getdns_validate_dnssec() Example? > > Scott, > > I think this extension may not be complete in the C library. It is a > more recent arrival to the API. > > It's been on my TODO list to check details on this. Thanks, Allison. I've made progress to the point where my call to getdns_validate_dnssec() is returning a 403 (I expect a 400), so I'm passing it the right types of data structures. Now I'm not sure if I'm passing it the right information to perform the validation. Scott From willem at nlnetlabs.nl Wed May 6 10:41:58 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 06 May 2015 12:41:58 +0200 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FC3D0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49FC3D0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <5549EFF6.20305@nlnetlabs.nl> Hi Scott, I suppose the API could be a bit more clear on the input of this function yes. getdns_return_t getdns_validate_dnssec( getdns_list *record_to_validate, getdns_list *bundle_of_support_records, getdns_list *trust_anchor_records ); - record_to_validate is a list of RR-dicts with companion RRSIG-RR-dicts which will be validated. - trust_anchor_records is the list of trusted DNSKEYs or DS'es RR-dicts. They do *not* need companion RRSIG-RR-dicts, as they are already trusted. You can get the system default trusted keys with the getdns_root_trust_anchor() function. - bundle_of_support_records must be a list of DS's RR-dicts and DNSKEY RR-dicts with companion RRSIG-RR-dicts that lead up from one of the trust_anchors to the RR-dicts to validate. If you would do a query with the "dnssec_return_validation_chain" extension, you can use the "validation_chain" key in the response dict as the bundle_of_support_records parameter ro getdns_validate_dnssec. You can use a "answer" section of a reply as the record_to_validate parameter; Or the "authority" section in case of NXDOMAIN. Note however, that the record_to_validate list MUST have companion RRSIG-RR-dicts for all its RR-dicts. getdns_validate_dnssec does not know the zone-cuts and thus cannot handle insecure delegations! It cannot determine if missing RRSIGs are sound (by way of insecure delegation: GETDNS_DNSSEC_INSECURE) or not (GETDNS_DNSSEC_BOGUS)! Also, building the wireformat data from RR-dicts doesn't work all that well currently. getdns_validate_dnssec can now validate only RR-dicts, that came from the wire and have a sound "rdata_raw" attribute. But, if the name contains compressed names (like with NS, MX and CNAME records) then the "rdata_raw" is not usable either, and getdns_validate_dnssec simply does not work! This is a bug and is top on my to do list to fix, as native stub dnssec validation depends on it's correct working. Hope this helps a bit. There used to be an test program for getdns_validate_dnssec: https://github.com/getdnsapi/getdns/blob/v0.1.4/src/test/tests_dnssec.c But I removed all the tests_*.c programs I contributed myself in favor of getdns_query... (which in turn never got the getdns_validate_dnssec test function, but alas). -- Willem Op 05-05-15 om 14:35 schreef Hollenbeck, Scott: >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Mankin, >> Allison >> Sent: Monday, May 04, 2015 12:09 PM >> To: libgetdns users list >> Subject: Re: [getdns-users] getdns_validate_dnssec() Example? >> >> Scott, >> >> I think this extension may not be complete in the C library. It is a >> more recent arrival to the API. >> >> It's been on my TODO list to check details on this. > > Thanks, Allison. I've made progress to the point where my call to getdns_validate_dnssec() is returning a 403 (I expect a 400), so I'm passing it the right types of data structures. Now I'm not sure if I'm passing it the right information to perform the validation. > > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From shollenbeck at verisign.com Wed May 6 11:02:44 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Wed, 6 May 2015 11:02:44 +0000 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <5549EFF6.20305@nlnetlabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49FC3D0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5549EFF6.20305@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC4B9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Thanks, Willem. This all sounds like where I am right now. One more question below. Scott > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Wednesday, May 06, 2015 6:42 AM > To: users at getdnsapi.net > Subject: Re: [getdns-users] getdns_validate_dnssec() Example? > > Hi Scott, > > I suppose the API could be a bit more clear on the input of this > function yes. > > getdns_return_t getdns_validate_dnssec( > getdns_list *record_to_validate, > getdns_list *bundle_of_support_records, > getdns_list *trust_anchor_records > ); > > - record_to_validate is a list of RR-dicts with companion RRSIG-RR- > dicts > which will be validated. > > - trust_anchor_records is the list of trusted DNSKEYs or DS'es RR- > dicts. > They do *not* need companion RRSIG-RR-dicts, as they are already > trusted. You can get the system default trusted keys with the > getdns_root_trust_anchor() function. > > - bundle_of_support_records must be a list of DS's RR-dicts and DNSKEY > RR-dicts with companion RRSIG-RR-dicts that lead up from one of the > trust_anchors to the RR-dicts to validate. > > If you would do a query with the "dnssec_return_validation_chain" > extension, you can use the "validation_chain" key in the response dict > as the bundle_of_support_records parameter ro getdns_validate_dnssec. > You can use a "answer" section of a reply as the record_to_validate > parameter; Or the "authority" section in case of NXDOMAIN. > > Note however, that the record_to_validate list MUST have companion > RRSIG-RR-dicts for all its RR-dicts. getdns_validate_dnssec does not > know the zone-cuts and thus cannot handle insecure delegations! It > cannot determine if missing RRSIGs are sound (by way of insecure > delegation: GETDNS_DNSSEC_INSECURE) or not (GETDNS_DNSSEC_BOGUS)! > > Also, building the wireformat data from RR-dicts doesn't work all that > well currently. getdns_validate_dnssec can now validate only RR-dicts, > that came from the wire and have a sound "rdata_raw" attribute. But, > if > the name contains compressed names (like with NS, MX and CNAME records) > then the "rdata_raw" is not usable either, and getdns_validate_dnssec > simply does not work! I've been able to get a positive result by doing an address query for www.getdnsapi.net. The test case that failed is doing an NS query for getdnsapi.net with this data: The answer to be validated: string(1342) "[ { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "nsdname": , "rdata_raw": }, "ttl": 450, "type": GETDNS_RRTYPE_NS }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "nsdname": , "rdata_raw": }, "ttl": 450, "type": GETDNS_RRTYPE_NS }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "nsdname": , "rdata_raw": }, "ttl": 450, "type": GETDNS_RRTYPE_NS }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "key_tag": 6273, "labels": 2, "original_ttl": 450, "rdata_raw": , "signature": , "signature_expiration": 1431913568, "signature_inception": 1430100475, "signers_name": , "type_covered": GETDNS_RRTYPE_NS }, "ttl": 450, "type": GETDNS_RRTYPE_RRSIG } ]" The support records: string(6593) "[ { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "flags": 256, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 172800, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "flags": 257, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 172800, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "key_tag": 19036, "labels": 0, "original_ttl": 172800, "rdata_raw": , "signature": , "signature_expiration": 1431734399, "signature_inception": 1430438400, "signers_name": , "type_covered": GETDNS_RRTYPE_DNSKEY }, "ttl": 172800, "type": GETDNS_RRTYPE_RRSIG }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "flags": 257, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 3600, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "flags": 257, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 3600, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "flags": 256, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 3600, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "key_tag": 26203, "labels": 2, "original_ttl": 3600, "rdata_raw": , "signature": , "signature_expiration": 1432283562, "signature_inception": 1430431675, "signers_name": , "type_covered": GETDNS_RRTYPE_DNSKEY }, "ttl": 3600, "type": GETDNS_RRTYPE_RRSIG }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "key_tag": 64869, "labels": 2, "original_ttl": 3600, "rdata_raw": , "signature": , "signature_expiration": 1432283562, "signature_inception": 1430431675, "signers_name": , "type_covered": GETDNS_RRTYPE_DNSKEY }, "ttl": 3600, "type": GETDNS_RRTYPE_RRSIG }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 7, "digest": , "digest_type": 1, "key_tag": 26203, "rdata_raw": }, "ttl": 86400, "type": GETDNS_RRTYPE_DS }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "key_tag": 48497, "labels": 2, "original_ttl": 86400, "rdata_raw": , "signature": , "signature_expiration": 1431235640, "signature_inception": 1430626640, "signers_name": , "type_covered": GETDNS_RRTYPE_DS }, "ttl": 86400, "type": GETDNS_RRTYPE_RRSIG }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "flags": 257, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 86400, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "flags": 256, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 86400, "type": GETDNS_RRTYPE_DNSKEY }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "key_tag": 35886, "labels": 1, "original_ttl": 86400, "rdata_raw": , "signature": , "signature_expiration": 1431362337, "signature_inception": 1430757237, "signers_name": , "type_covered": GETDNS_RRTYPE_DNSKEY }, "ttl": 86400, "type": GETDNS_RRTYPE_RRSIG }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "digest": , "digest_type": 2, "key_tag": 35886, "rdata_raw": }, "ttl": 86399, "type": GETDNS_RRTYPE_DS }, { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "key_tag": 48613, "labels": 1, "original_ttl": 86400, "rdata_raw": , "signature": , "signature_expiration": 1431709200, "signature_inception": 1430841600, "signers_name": , "type_covered": GETDNS_RRTYPE_DS }, "ttl": 86399, "type": GETDNS_RRTYPE_RRSIG } ]" The trust anchor: string(355) "[ { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "algorithm": 8, "flags": 257, "protocol": 3, "public_key": , "rdata_raw": }, "ttl": 172800, "type": GETDNS_RRTYPE_DNSKEY } ]" Based on everything you wrote above, does this look correct? Scott From willem at nlnetlabs.nl Wed May 6 12:14:31 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 06 May 2015 14:14:31 +0200 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49FC4B9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49FC3D0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5549EFF6.20305@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F49FC4B9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <554A05A7.4090208@nlnetlabs.nl> Scott, why is this data of type string? Shouldn't those be array's in php? But the actual content of those strings are indeed the lists (array's) that should be used as parameters with getdns_validate_dnssec yes. The bug is in getdns_validate_dnssec itself. Currently it cannot handle compressed dname's. NS records do have compressed dname's and the records you try to validate in this case actually do contain compressed dname's too. Look for example to the rdata_raw in the first RR-dict in the answer: { "class": GETDNS_RRCLASS_IN, "name": , "rdata": { "nsdname": , "rdata_raw": }, "ttl": 450, "type": GETDNS_RRTYPE_NS }, It has the compression pointer bits set (first byte, 0xC0 has bits 8 and 7 set) and points to 0x000C, so position 12 which is directly after the 12 bytes DNS header, so it points to the query name. The presence of this RR-dict alone is enough trigger the getdns_validate_dnssec bug. Although not displayed, the third RR-dict in the answer must have a compression pointer too for ".nl", because the rdata_raw attribute is not expanded to a dname rendering. As I said, fixing this bug is on top of my TODO list, because native stub DNSSEC validation (without relying on libunbound to perform the DNSSEC queries) is dependent on it. Besides this fixable bug, using getdns_validate_dnssec also has the shortcoming that it cannot recognize insecure delegations, so it should never be used blindly to determine the DNSSEC status of answers received with the dnssec_return_validation_chain extension. Actual real-life DNSSEC validation needs a more intelligent approach than getdns_validate_dnssec can offer with the current API's prototype. -- Willem Op 06-05-15 om 13:02 schreef Hollenbeck, Scott: > Thanks, Willem. This all sounds like where I am right now. One more question below. > > Scott > >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem >> Toorop >> Sent: Wednesday, May 06, 2015 6:42 AM >> To: users at getdnsapi.net >> Subject: Re: [getdns-users] getdns_validate_dnssec() Example? >> >> Hi Scott, >> >> I suppose the API could be a bit more clear on the input of this >> function yes. >> >> getdns_return_t getdns_validate_dnssec( >> getdns_list *record_to_validate, >> getdns_list *bundle_of_support_records, >> getdns_list *trust_anchor_records >> ); >> >> - record_to_validate is a list of RR-dicts with companion RRSIG-RR- >> dicts >> which will be validated. >> >> - trust_anchor_records is the list of trusted DNSKEYs or DS'es RR- >> dicts. >> They do *not* need companion RRSIG-RR-dicts, as they are already >> trusted. You can get the system default trusted keys with the >> getdns_root_trust_anchor() function. >> >> - bundle_of_support_records must be a list of DS's RR-dicts and DNSKEY >> RR-dicts with companion RRSIG-RR-dicts that lead up from one of the >> trust_anchors to the RR-dicts to validate. >> >> If you would do a query with the "dnssec_return_validation_chain" >> extension, you can use the "validation_chain" key in the response dict >> as the bundle_of_support_records parameter ro getdns_validate_dnssec. >> You can use a "answer" section of a reply as the record_to_validate >> parameter; Or the "authority" section in case of NXDOMAIN. >> >> Note however, that the record_to_validate list MUST have companion >> RRSIG-RR-dicts for all its RR-dicts. getdns_validate_dnssec does not >> know the zone-cuts and thus cannot handle insecure delegations! It >> cannot determine if missing RRSIGs are sound (by way of insecure >> delegation: GETDNS_DNSSEC_INSECURE) or not (GETDNS_DNSSEC_BOGUS)! >> >> Also, building the wireformat data from RR-dicts doesn't work all that >> well currently. getdns_validate_dnssec can now validate only RR-dicts, >> that came from the wire and have a sound "rdata_raw" attribute. But, >> if >> the name contains compressed names (like with NS, MX and CNAME records) >> then the "rdata_raw" is not usable either, and getdns_validate_dnssec >> simply does not work! > > I've been able to get a positive result by doing an address query for www.getdnsapi.net. The test case that failed is doing an NS query for getdnsapi.net with this data: > > The answer to be validated: > > string(1342) "[ > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "nsdname": , > "rdata_raw": > }, > "ttl": 450, > "type": GETDNS_RRTYPE_NS > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "nsdname": , > "rdata_raw": > }, > "ttl": 450, > "type": GETDNS_RRTYPE_NS > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "nsdname": , > "rdata_raw": > }, > "ttl": 450, > "type": GETDNS_RRTYPE_NS > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "key_tag": 6273, > "labels": 2, > "original_ttl": 450, > "rdata_raw": , > "signature": , > "signature_expiration": 1431913568, > "signature_inception": 1430100475, > "signers_name": , > "type_covered": GETDNS_RRTYPE_NS > }, > "ttl": 450, > "type": GETDNS_RRTYPE_RRSIG > } > ]" > > The support records: > > string(6593) "[ > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "flags": 256, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 172800, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "flags": 257, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 172800, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "key_tag": 19036, > "labels": 0, > "original_ttl": 172800, > "rdata_raw": , > "signature": , > "signature_expiration": 1431734399, > "signature_inception": 1430438400, > "signers_name": , > "type_covered": GETDNS_RRTYPE_DNSKEY > }, > "ttl": 172800, > "type": GETDNS_RRTYPE_RRSIG > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "flags": 257, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 3600, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "flags": 257, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 3600, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "flags": 256, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 3600, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "key_tag": 26203, > "labels": 2, > "original_ttl": 3600, > "rdata_raw": , > "signature": , > "signature_expiration": 1432283562, > "signature_inception": 1430431675, > "signers_name": , > "type_covered": GETDNS_RRTYPE_DNSKEY > }, > "ttl": 3600, > "type": GETDNS_RRTYPE_RRSIG > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "key_tag": 64869, > "labels": 2, > "original_ttl": 3600, > "rdata_raw": , > "signature": , > "signature_expiration": 1432283562, > "signature_inception": 1430431675, > "signers_name": , > "type_covered": GETDNS_RRTYPE_DNSKEY > }, > "ttl": 3600, > "type": GETDNS_RRTYPE_RRSIG > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 7, > "digest": , > "digest_type": 1, > "key_tag": 26203, > "rdata_raw": > }, > "ttl": 86400, > "type": GETDNS_RRTYPE_DS > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "key_tag": 48497, > "labels": 2, > "original_ttl": 86400, > "rdata_raw": , > "signature": , > "signature_expiration": 1431235640, > "signature_inception": 1430626640, > "signers_name": , > "type_covered": GETDNS_RRTYPE_DS > }, > "ttl": 86400, > "type": GETDNS_RRTYPE_RRSIG > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "flags": 257, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 86400, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "flags": 256, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 86400, > "type": GETDNS_RRTYPE_DNSKEY > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "key_tag": 35886, > "labels": 1, > "original_ttl": 86400, > "rdata_raw": , > "signature": , > "signature_expiration": 1431362337, > "signature_inception": 1430757237, > "signers_name": , > "type_covered": GETDNS_RRTYPE_DNSKEY > }, > "ttl": 86400, > "type": GETDNS_RRTYPE_RRSIG > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "digest": , > "digest_type": 2, > "key_tag": 35886, > "rdata_raw": > }, > "ttl": 86399, > "type": GETDNS_RRTYPE_DS > }, > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "key_tag": 48613, > "labels": 1, > "original_ttl": 86400, > "rdata_raw": , > "signature": , > "signature_expiration": 1431709200, > "signature_inception": 1430841600, > "signers_name": , > "type_covered": GETDNS_RRTYPE_DS > }, > "ttl": 86399, > "type": GETDNS_RRTYPE_RRSIG > } > ]" > > The trust anchor: > > string(355) "[ > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "algorithm": 8, > "flags": 257, > "protocol": 3, > "public_key": , > "rdata_raw": > }, > "ttl": 172800, > "type": GETDNS_RRTYPE_DNSKEY > } > ]" > > Based on everything you wrote above, does this look correct? > > Scott > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From shollenbeck at verisign.com Wed May 6 12:21:37 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Wed, 6 May 2015 12:21:37 +0000 Subject: [getdns-users] getdns_validate_dnssec() Example? In-Reply-To: <554A05A7.4090208@nlnetlabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F49FC1B0F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <831693C2CDA2E849A7D7A712B24E257F49FC2EB2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2372B955-B896-4752-BBC6-E0A8FA149E5C@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49FC3D0A@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5549EFF6.20305@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F49FC4B9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <554A05A7.4090208@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FC4C23@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Wednesday, May 06, 2015 8:15 AM > To: users at getdnsapi.net > Subject: Re: [getdns-users] getdns_validate_dnssec() Example? > > Scott, > > why is this data of type string? Shouldn't those be array's in php? > But the actual content of those strings are indeed the lists (array's) > that should be used as parameters with getdns_validate_dnssec yes. They're strings because they are the output of the "pretty print" functions. > The bug is in getdns_validate_dnssec itself. Currently it cannot > handle > compressed dname's. NS records do have compressed dname's and the > records you try to validate in this case actually do contain compressed > dname's too. > > Look for example to the rdata_raw in the first RR-dict in the answer: > > { > "class": GETDNS_RRCLASS_IN, > "name": , > "rdata": > { > "nsdname": , > "rdata_raw": > }, > "ttl": 450, > "type": GETDNS_RRTYPE_NS > }, > > It has the compression pointer bits set (first byte, 0xC0 has bits 8 > and > 7 set) and points to 0x000C, so position 12 which is directly after the > 12 bytes DNS header, so it points to the query name. > > The presence of this RR-dict alone is enough trigger the > getdns_validate_dnssec bug. > > Although not displayed, the third RR-dict in the answer must have a > compression pointer too for ".nl", because the rdata_raw attribute is > not expanded to a dname rendering. > > As I said, fixing this bug is on top of my TODO list, because native > stub DNSSEC validation (without relying on libunbound to perform the > DNSSEC queries) is dependent on it. > > Besides this fixable bug, using getdns_validate_dnssec also has the > shortcoming that it cannot recognize insecure delegations, so it should > never be used blindly to determine the DNSSEC status of answers > received > with the dnssec_return_validation_chain extension. > Actual real-life DNSSEC validation needs a more intelligent approach > than getdns_validate_dnssec can offer with the current API's prototype. Understood, and thanks for confirming. I'm updating my documentation to note this current limitation in the library. Scott From willem at nlnetlabs.nl Tue May 12 14:13:06 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 12 May 2015 16:13:06 +0200 Subject: [getdns-users] getdns_context_run() vs. getdns_context_process_async() In-Reply-To: <55429AD3.2070004@nlnetlabs.nl> References: <831693C2CDA2E849A7D7A712B24E257F49FC02D6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55422094.4040005@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F49FC0C33@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <55429AD3.2070004@nlnetlabs.nl> Message-ID: <55520A72.2090303@nlnetlabs.nl> Op 30-04-15 om 23:12 schreef Willem Toorop: > Also getdns_context_process_async() does not work with stub requests > with libevent. FYI: This has been fixed with commit 01d42753 . -- Willem From willem at nlnetlabs.nl Tue May 12 14:54:15 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 12 May 2015 16:54:15 +0200 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <5541FD41.8010702@nlnetlabs.nl> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> Message-ID: <55521417.5090306@nlnetlabs.nl> Hi Daniel and others interested in .so versioning. I have to admit that my initial willingness to blindly agree has been tempered somewhat when I was notified of the fact that the .so version actually does increment on FreeBSD. Op 30-04-15 om 12:00 schreef Willem Toorop: >> This is worked around in 0.1.8 by another change to GETDNS_LIBVERSION, >> but the change isn't correct either, since interfaces have been added >> again (in partcular, the GETDNS_TRANSPORT_TLS_* constants have been >> added, which affects the API at least, for tools trying to compile >> against the newer version). It affects the API, but not the ABI. Since .so versions are really about the ABI, I am now fairly reluctant to increase current when only constants are added. I believe the addition of a constant is considered a source code change in the context of libtool and only the revision needs to be updated. So based on the exposed symbols in the .so, I've done the following adaptation to configure.ac. diff --git a/configure.ac b/configure.ac index 6e321ee..b1efccd 100755 --- a/configure.ac +++ b/configure.ac @@ -56,10 +56,11 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for th # getdns-0.1.4 had libversion 0:0:0 # getdns-0.1.5 had libversion 1:0:0 # getdns-0.1.6 had libversion 1:1:0 -# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:2:1) -# getdns-0.1.8 had libversion 1:3:0 (but should have had 3:3:2) +# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:0:1) +# getdns-0.1.8 had libversion 1:3:0 (but should have had 2:1:1) +# getdns-0.1.9 will have libversion 2:2:1 # -GETDNS_LIBVERSION=3:3:2 +GETDNS_LIBVERSION=2:2:1 AC_SUBST(GETDNS_COMPILATION_COMMENT) AC_SUBST(GETDNS_LIBVERSION) -- Willem >> >> Note that the commentary in configure.ac about how to update >> libversion is correct up to a point, but then breaks things badly. >> This patch removes that as well. >> >> Here is the canonical reference for how to update libversion: >> >> https://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info >> --- >> configure.ac | 10 +++------- >> 1 file changed, 3 insertions(+), 7 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index 6e98e01..6e321ee 100755 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -52,18 +52,14 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING configured on $CURRENT_DATE for th >> # if any interfaces have been added since the last public release then increment age >> # if any interfaces have been removed or changed since the last public release then >> # set age to 0 >> -# if api unchanged: no changes >> -# if api broken: current++ ; revision = 0; age = 0 >> -# if programs compiled against existing library work and link with new >> -# version of library with new binary api: revision++; age++ >> # >> # getdns-0.1.4 had libversion 0:0:0 >> # getdns-0.1.5 had libversion 1:0:0 >> # getdns-0.1.6 had libversion 1:1:0 >> -# getdns-0.1.7 had libversion 1:2:1 >> -# getdns-0.1.8 will have libversion 1:3:0 >> +# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:2:1) >> +# getdns-0.1.8 had libversion 1:3:0 (but should have had 3:3:2) >> # >> -GETDNS_LIBVERSION=1:3:0 >> +GETDNS_LIBVERSION=3:3:2 >> >> AC_SUBST(GETDNS_COMPILATION_COMMENT) >> AC_SUBST(GETDNS_LIBVERSION) >> > > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From dkg at fifthhorseman.net Tue May 12 16:16:29 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 May 2015 12:16:29 -0400 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <55521417.5090306@nlnetlabs.nl> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> <55521417.5090306@nlnetlabs.nl> Message-ID: <87sib1db4y.fsf@alice.fifthhorseman.net> On Tue 2015-05-12 10:54:15 -0400, Willem Toorop wrote: > I have to admit that my initial willingness to blindly agree has been > tempered somewhat when I was notified of the fact that the .so version > actually does increment on FreeBSD. hm, i wasn't hoping for blind agreement anyway, so i'm glad you're thinking more about this :) I'm surprised that FreeBSD produces a different .so number, to be honest. do you mean it produces something new for libversion 3:3:2 or for the older settings? > Op 30-04-15 om 12:00 schreef Willem Toorop: >>> This is worked around in 0.1.8 by another change to GETDNS_LIBVERSION, >>> but the change isn't correct either, since interfaces have been added >>> again (in partcular, the GETDNS_TRANSPORT_TLS_* constants have been >>> added, which affects the API at least, for tools trying to compile >>> against the newer version). > > It affects the API, but not the ABI. Since .so versions are really > about the ABI, I am now fairly reluctant to increase current when only > constants are added. I believe the addition of a constant is considered > a source code change in the context of libtool and only the revision > needs to be updated. I think you may be right, but this is not the clearest distinction; in particular, i think that you could legitimately define an ABI differently and maybe come to a different conclusion. There are some constants that could be added in such a way that i think should increment the ABI. What happens if i pass the GETDNS_TRANSPORT_TLS_* constants to a version of libgetdns that doesn't know about them? If they were silently accepted (i don't think this is the case), then this is definitely an ABI change, because the intended semantics of the underlying library function have shifted. If they cause an error (which i think is what actually happens here, though i haven't tested) then you've got a stronger argument that the ABI is stable because the semantics are stable. > So based on the exposed symbols in the .so, I've done the following > adaptation to configure.ac. > > diff --git a/configure.ac b/configure.ac > index 6e321ee..b1efccd 100755 > --- a/configure.ac > +++ b/configure.ac > @@ -56,10 +56,11 @@ GETDNS_COMPILATION_COMMENT="AC_PACKAGE_STRING > configured on $CURRENT_DATE for th > # getdns-0.1.4 had libversion 0:0:0 > # getdns-0.1.5 had libversion 1:0:0 > # getdns-0.1.6 had libversion 1:1:0 > -# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:2:1) > -# getdns-0.1.8 had libversion 1:3:0 (but should have had 3:3:2) > +# getdns-0.1.7 had libversion 1:2:1 (but should have had 2:0:1) > +# getdns-0.1.8 had libversion 1:3:0 (but should have had 2:1:1) > +# getdns-0.1.9 will have libversion 2:2:1 > # > -GETDNS_LIBVERSION=3:3:2 > +GETDNS_LIBVERSION=2:2:1 > > AC_SUBST(GETDNS_COMPILATION_COMMENT) > AC_SUBST(GETDNS_LIBVERSION) I think this is OK. Thanks for thinking it over! --dkg From edmonds at debian.org Tue May 12 16:39:22 2015 From: edmonds at debian.org (Robert Edmonds) Date: Tue, 12 May 2015 12:39:22 -0400 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <87sib1db4y.fsf@alice.fifthhorseman.net> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> <55521417.5090306@nlnetlabs.nl> <87sib1db4y.fsf@alice.fifthhorseman.net> Message-ID: <20150512163922.GA25138@mycre.ws> Daniel Kahn Gillmor wrote: > On Tue 2015-05-12 10:54:15 -0400, Willem Toorop wrote: > > > I have to admit that my initial willingness to blindly agree has been > > tempered somewhat when I was notified of the fact that the .so version > > actually does increment on FreeBSD. > > hm, i wasn't hoping for blind agreement anyway, so i'm glad you're > thinking more about this :) I'm surprised that FreeBSD produces a > different .so number, to be honest. do you mean it produces something > new for libversion 3:3:2 or for the older settings? Hi, Building getdns with GETDNS_LIBVERSION=3:3:2 (i.e., 393b847) on FreeBSD results in this: root at freebsd10:/usr/local/stow/getdns/lib # ls -l total 3364 -rw-r--r-- 1 root wheel 2354970 May 4 21:00 libgetdns.a -rw-r--r-- 1 root wheel 1017 May 4 21:00 libgetdns.la lrwxr-xr-x 1 root wheel 14 May 4 21:00 libgetdns.so -> libgetdns.so.3 -rwxr-xr-x 1 root wheel 984116 May 4 21:00 libgetdns.so.3 root at freebsd10:/usr/local/stow/getdns/lib # objdump -p libgetdns.so.3 | grep SONAME SONAME libgetdns.so.3 It looks like the FreeBSD developers consider this an upstream bug in libtool, and would really prefer if libtool would behave more like it does on Linux on their platform, see: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8765 http://lists.freebsd.org/pipermail/freebsd-ports/2014-May/092082.html The FreeBSD libtool appears to have been patched. When I run autoreconf + libtoolize on getdns 393b847 using the FreeBSD patched versions, I instead get this: root at freebsd10:/usr/local/stow/getdns-relibtoolized/lib # ls -l total 3364 -rw-r--r-- 1 root wheel 2355002 May 12 16:28 libgetdns.a -rw-r--r-- 1 root wheel 1011 May 12 16:28 libgetdns.la lrwxr-xr-x 1 root wheel 18 May 12 16:28 libgetdns.so -> libgetdns.so.1.2.3 lrwxr-xr-x 1 root wheel 18 May 12 16:28 libgetdns.so.1 -> libgetdns.so.1.2.3 -rwxr-xr-x 1 root wheel 984132 May 12 16:28 libgetdns.so.1.2.3 root at freebsd10:/usr/local/stow/getdns-relibtoolized/lib # objdump -p libgetdns.so.1.2.3 | grep SONAME SONAME libgetdns.so.1 Which is the same behavior you get on Linux. (Note also that there's a getdns port in the FreeBSD ports system, which does appear to use "USES=libtool" as described in the freebsd.org link above, so it presumably also gets the behavior performed by the patched FreeBSD version of libtool.) -- Robert Edmonds edmonds at debian.org From dkg at fifthhorseman.net Tue May 12 16:48:05 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 May 2015 12:48:05 -0400 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <20150512163922.GA25138@mycre.ws> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> <55521417.5090306@nlnetlabs.nl> <87sib1db4y.fsf@alice.fifthhorseman.net> <20150512163922.GA25138@mycre.ws> Message-ID: <87a8x9d9oa.fsf@alice.fifthhorseman.net> On Tue 2015-05-12 12:39:22 -0400, Robert Edmonds wrote: > Which is the same behavior you get on Linux. > > (Note also that there's a getdns port in the FreeBSD ports system, which > does appear to use "USES=libtool" as described in the freebsd.org link > above, so it presumably also gets the behavior performed by the patched > FreeBSD version of libtool.) Thanks for tracking that down and explaining it, Robert! --dkg From edmonds at debian.org Tue May 12 17:12:34 2015 From: edmonds at debian.org (Robert Edmonds) Date: Tue, 12 May 2015 13:12:34 -0400 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <87a8x9d9oa.fsf@alice.fifthhorseman.net> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> <55521417.5090306@nlnetlabs.nl> <87sib1db4y.fsf@alice.fifthhorseman.net> <20150512163922.GA25138@mycre.ws> <87a8x9d9oa.fsf@alice.fifthhorseman.net> Message-ID: <20150512171234.GA5141@mycre.ws> Daniel Kahn Gillmor wrote: > On Tue 2015-05-12 12:39:22 -0400, Robert Edmonds wrote: > > Which is the same behavior you get on Linux. > > > > (Note also that there's a getdns port in the FreeBSD ports system, which > > does appear to use "USES=libtool" as described in the freebsd.org link > > above, so it presumably also gets the behavior performed by the patched > > FreeBSD version of libtool.) > > Thanks for tracking that down and explaining it, Robert! I did some more digging. It looks like libtool upstream merged the changes requested from the FreeBSD project: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0995849d00a6f6f52a2b940c0e19b1f4a0891e50 (libtool: split sco version into its own type.) http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=bb7cef9d97d6fdb2d8ee5350a82fb39b0ff8513d (libtool: use a modern library version scheme for freebsd-elf.) http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=cbeefbc8f0ac527f7c7f14cbc8b3fc9de0ff2b77 (libtoolize: no need for umask 0 now that copying does not use tar.) http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=218bf6f4c2ed02ee13293b2100238008ef225405 (libtool: commit forgotten soname_spec for freebsd-elf in bb7cef9.) So, it looks like: - If you use libtool 2.4.5, 2.4.6, or newer, you should get the right behavior on FreeBSD. - Do not use libtool 2.4.4, it does not work properly on FreeBSD. - If you use libtool 2.4.3 or older, you get the old, undesired behavior on FreeBSD, where the SONAME just uses current. Unfortunately, Debian/Ubuntu have libtool 2.4.2, which means releases built on those platforms will have the old behavior on FreeBSD. -- Robert Edmonds edmonds at debian.org From willem at nlnetlabs.nl Tue May 12 19:16:15 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 12 May 2015 21:16:15 +0200 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <20150512171234.GA5141@mycre.ws> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> <55521417.5090306@nlnetlabs.nl> <87sib1db4y.fsf@alice.fifthhorseman.net> <20150512163922.GA25138@mycre.ws> <87a8x9d9oa.fsf@alice.fifthhorseman.net> <20150512171234.GA5141@mycre.ws> Message-ID: <5552517F.6030209@nlnetlabs.nl> Hey Robert! Thanks for looking into this! I will make sure to always do a autoreconf -fi on FreeBSD after altering configure.ac. That should take care of this. You've earned a thank you in the ChangeLog. Thanks again! -- Willem Op 12-05-15 om 19:12 schreef Robert Edmonds: > Daniel Kahn Gillmor wrote: >> On Tue 2015-05-12 12:39:22 -0400, Robert Edmonds wrote: >>> Which is the same behavior you get on Linux. >>> >>> (Note also that there's a getdns port in the FreeBSD ports system, which >>> does appear to use "USES=libtool" as described in the freebsd.org link >>> above, so it presumably also gets the behavior performed by the patched >>> FreeBSD version of libtool.) >> >> Thanks for tracking that down and explaining it, Robert! > > I did some more digging. It looks like libtool upstream merged the > changes requested from the FreeBSD project: > > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0995849d00a6f6f52a2b940c0e19b1f4a0891e50 > (libtool: split sco version into its own type.) > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=bb7cef9d97d6fdb2d8ee5350a82fb39b0ff8513d > (libtool: use a modern library version scheme for freebsd-elf.) > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=cbeefbc8f0ac527f7c7f14cbc8b3fc9de0ff2b77 > (libtoolize: no need for umask 0 now that copying does not use tar.) > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=218bf6f4c2ed02ee13293b2100238008ef225405 > (libtool: commit forgotten soname_spec for freebsd-elf in bb7cef9.) > > So, it looks like: > > - If you use libtool 2.4.5, 2.4.6, or newer, you should get the > right behavior on FreeBSD. > > - Do not use libtool 2.4.4, it does not work properly on FreeBSD. > > - If you use libtool 2.4.3 or older, you get the old, undesired > behavior on FreeBSD, where the SONAME just uses current. > > Unfortunately, Debian/Ubuntu have libtool 2.4.2, which means releases > built on those platforms will have the old behavior on FreeBSD. > From willem at nlnetlabs.nl Tue May 12 20:23:31 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 12 May 2015 22:23:31 +0200 Subject: [getdns-users] [PATCH] Fix libversion numbering In-Reply-To: <87sib1db4y.fsf@alice.fifthhorseman.net> References: <1430357875-1819-1-git-send-email-dkg@fifthhorseman.net> <5541FD41.8010702@nlnetlabs.nl> <55521417.5090306@nlnetlabs.nl> <87sib1db4y.fsf@alice.fifthhorseman.net> Message-ID: <55526143.7020300@nlnetlabs.nl> Op 12-05-15 om 18:16 schreef Daniel Kahn Gillmor: > What happens if i pass the GETDNS_TRANSPORT_TLS_* constants to a version > of libgetdns that doesn't know about them? If they were silently > accepted (i don't think this is the case), then this is definitely an > ABI change, because the intended semantics of the underlying library > function have shifted. If they cause an error (which i think is what > actually happens here, though i haven't tested) then you've got a > stronger argument that the ABI is stable because the semantics are > stable. Good :)! Because I can confirm that trying to set an undefined transport has always resulted in an GETDNS_RETURN_CONTEXT_UPDATE_FAIL return code and will still do this. Thanks for raising this issue which eventually resulted in a more consistently compiling library. -- Willem From willem at nlnetlabs.nl Wed May 13 22:31:33 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 14 May 2015 00:31:33 +0200 Subject: [getdns-users] getdns 0.2.0 release candidate Message-ID: <5553D0C5.80102@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, I am pleased to announce the special RIPE70 edition release candidate for version 0.2.0 of our getdns API implementation. This release candidate is for a release that has its intermediate version bumped to indicate that we consider the native stub operation, introduced in version 0.1.6, to be in a mature state. Besides bug fixes, the DNS over TLS transport option, introduced in the previous version, has been fully incorporated in the native stub module and is now truly asynchronous in all its phases; include the TCP and the TLS handshake. In addition a new transport option is introduced with this release: GETDNS_TRANSPORT_STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN A list of servers supporting TLS on port 1021 and STARTTLS on port 53 for testing purposes is available on the sinodun portal, here: https://portal.sinodun.com/wiki/display/TDNS/DNS-over-TLS+test+servers 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.2.0 release will follow over one week on the 21th of May 2015. link : https://getdnsapi.net/dist/getdns-0.2.0rc1.tar.gz md5 : 4abf8be703a5040354e66d720922904d sha1 : 7248654e57848c2b2a3d5c33ff86f2f7ca121ccf pgp sig: https://getdnsapi.net/dist/getdns-0.2.0rc1.tar.gz.asc ChangeLog ========= * 2015-05-??: Version 0.2.0 * Fix libversion numbering: Thanks Daniel Kahn Gillmor * run_once method for the libevent extension * autoreconf -fi on FreeBSD always, because of newer libtool version suitable for FreeBSD installs too. Thanks Robert Edmonds * True asynchronous processing of the new TLS transport options * STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN transport option. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVU9DFAAoJEOX4+CEvd6SYWIAP/1emRzm8CkRn7446kEf6otEy //5MV3+Oy7Txp2Y+OoNDcRSlvRchW0pm8rPdXa+7AalN6dlaoUZShnWSdjcYbPg1 9Jksgii/zCZybuZrgpkzZtGpFyidYCvGSqsF6fX7qKhZ9iZo4x0TvyUn6KPke1iO PL7soPpFWJHMCCskounHFanybWki+7JI1rFj4m3wVLxaAEOEg6XZ7A44oQTVI+E2 tFgRDj+21TUm6BOY/C5R5bzMaJi5V/6iViWRIGAM/h6F14+Gu9SyJ1nhQ5MSHFBH UIRk1DyQpFaHYK0sotEldDaNdSQQMaGt32BqeskVTZ2JNs/dMecfxq4H4Og7la7/ LWNRWwBR+Ac+yyjJGPndkQb6w8xumtf6w6ig2hnpQf3ppHorkl2w8LAYfqmREyhD UsqmRFElYiCJPWnVVMMjYp8BHe+KuGm2UjggL2SFJ96tnVjhCKfNKCKBS3mppTb2 ofDJx/RCIAwsgR84O7dwWYaUcaNr14ynwAX5ve/Fgrk8ihhaucT4Pw+kWckEoflM WK78jyo7U1Ki3wIYt9Qn9L6Z+/fdJg84DWa5NZZJcUzEIDurCSin4ho9G5PVpaRA fb9ieSCfiU9iHd5yI8bjg6Cap4MWR5CUsUk4I35b1NeoVy7XBwSqHXuu0InwZjvy vqlZT8g4GiXRw+aOAnS3 =yCwG -----END PGP SIGNATURE----- From shollenbeck at verisign.com Thu May 14 11:37:16 2015 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu, 14 May 2015 11:37:16 +0000 Subject: [getdns-users] getdns 0.2.0 release candidate In-Reply-To: <5553D0C5.80102@nlnetlabs.nl> References: <5553D0C5.80102@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F49FCD009@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Wednesday, May 13, 2015 6:32 PM > To: users at getdnsapi.net > Subject: [getdns-users] getdns 0.2.0 release candidate > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear All, > > I am pleased to announce the special RIPE70 edition release candidate > for version 0.2.0 of our getdns API implementation. I've updated the PHP language bindings for compatibility with this release. Version 0.6.2 can be found in the "develop" branch. Scott From dkg at fifthhorseman.net Thu May 14 13:28:15 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 14 May 2015 09:28:15 -0400 Subject: [getdns-users] getdns 0.2.0 release candidate In-Reply-To: <5553D0C5.80102@nlnetlabs.nl> References: <5553D0C5.80102@nlnetlabs.nl> Message-ID: <87iobv70gg.fsf@alice.fifthhorseman.net> On Wed 2015-05-13 18:31:33 -0400, Willem Toorop wrote: > I am pleased to announce the special RIPE70 edition release candidate > for version 0.2.0 of our getdns API implementation. [...] > 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.2.0 release will follow > over one week on the 21th of May 2015. Thanks for this! I've prepared debian packaging for it as part of the pkg-nlnetlabs team in debian[0], and uploaded the release candidate to debian's experimental repository. It should be available for download via apt within the next day (or maybe even a few hours, for architectures with speedy buildds). Hopefully this will allow wider exposure and testing of the RC before the 21st. Regards, --dkg [0] branches and tags for debian packaging of 0.2.0~rc1 are pushed to https://anonscm.debian.org/git/pkg-nlnetlabs/getdns for anyone interested (we do not intend or want the debian packaging to be merged by upstream). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From willem at nlnetlabs.nl Thu May 14 14:55:02 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 14 May 2015 16:55:02 +0200 Subject: [getdns-users] getdns 0.2.0 release candidate In-Reply-To: <87iobv70gg.fsf@alice.fifthhorseman.net> References: <5553D0C5.80102@nlnetlabs.nl> <87iobv70gg.fsf@alice.fifthhorseman.net> Message-ID: <5554B746.9090808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you Daniel that is wonderful. Much appreciated. - -- Willem Op 14-05-15 om 15:28 schreef Daniel Kahn Gillmor: > On Wed 2015-05-13 18:31:33 -0400, Willem Toorop wrote: >> I am pleased to announce the special RIPE70 edition release >> candidate for version 0.2.0 of our getdns API implementation. > [...] >> 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.2.0 release >> will follow over one week on the 21th of May 2015. > > Thanks for this! I've prepared debian packaging for it as part of > the pkg-nlnetlabs team in debian[0], and uploaded the release > candidate to debian's experimental repository. > > It should be available for download via apt within the next day > (or maybe even a few hours, for architectures with speedy > buildds). Hopefully this will allow wider exposure and testing of > the RC before the 21st. > > Regards, > > --dkg > > [0] branches and tags for debian packaging of 0.2.0~rc1 are pushed > to https://anonscm.debian.org/git/pkg-nlnetlabs/getdns for anyone > interested (we do not intend or want the debian packaging to be > merged by upstream). > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVVLc9AAoJEOX4+CEvd6SYjJwP+gKW4OiCu5rgvDiVFyYsWYM6 yYDkuiOMItYle65wzh2KeIuzC1BMOztAMvH7JPLJtCTmTgx4p8fieiYLUglDjV4V FjNtHeAAbnH7sH3Uezmsfz6HwxXTN+UDVSH/XpEYNq4E102XFOD7aUT7OlGCoiUc 6QQmByIfMc5iavVH/DbDKbYF0EGR5KRJWJJ0kMKzNmSZLQ6dRMmge30XipsZuJHK XGU5OXLusC+g/UDPE4oNzRdQEI7cq5gW+zba4fEJEm7KRETk6Fs0TVVs8dLx/pgz u9c62+VwDkP5JnYykc3rxaVRRlAEUbQQTgjPuSyLEjXVaauZ0MuuV4OESazmFIQg m/k+8viZXHIdlxwtu5tDpf1QKHUDmOK2NTfMGTcJIMZADRWQuiUTiV1hGd7QF4yp p8WWxF/J8DY7kFv9nEZmOZndoF+yoKpptasSazBjfFaZEYQXOowmEOd3QlaRsyju B+UNKfH0OPe1p3luM87DFFz/7aZsVV2sMGx+Mh1cGYv/LpPmnOMNwPtjYJFcemfI eqlstAYCajQSCvVgCZbNSND7RTKfgTce1jVZniNnPQR/tt669LcXwd/FXtIcHhzF RnxTp+O7c3HRRDb206jwQ241Al8IE5rKsMaXuf2YxRPP7/XUgpn/M06Gu2ktrQmn sjr5TB/1dlhxPEqdVCcp =kmP7 -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu May 21 12:33:46 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 21 May 2015 14:33:46 +0200 Subject: [getdns-users] getdns 0.2.0 released Message-ID: <555DD0AA.6030107@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I am pleased to announce version 0.2.0 of our getdns API implementation. This release has its intermediate version bumped to indicate that we consider the native stub operation, introduced in version 0.1.6, to be in a mature state. Besides bug fixes, the DNS over TLS transport option, introduced in the previous version, has been fully incorporated in the native stub module and is now truly asynchronous in all its phases; including the TCP and the TLS handshake. In addition, a new transport option is introduced with this release: GETDNS_TRANSPORT_STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN A list of servers supporting TLS on port 1021 and STARTTLS on port 53 for testing purposes is available on the sinodun portal, here: https://portal.sinodun.com/wiki/display/TDNS/DNS-over-TLS+test+servers link: https://getdnsapi.net/dist/getdns-0.2.0.tar.gz md5 : 4abf8be703a5040354e66d720922904d sha1: 7248654e57848c2b2a3d5c33ff86f2f7ca121ccf pgp : https://getdnsapi.net/dist/getdns-0.2.0.tar.gz.asc ChangeLog ========= * 2015-05-21: Version 0.2.0 * Fix libversion numbering: Thanks Daniel Kahn Gillmor * run_once method for the libevent extension * autoreconf -fi on FreeBSD always, because of newer libtool version suitable for FreeBSD installs too. Thanks Robert Edmonds * True asynchronous processing of the new TLS transport options * STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN transport option. * Manpage fixes: Thanks Anthony Kirby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVXdCqAAoJEOX4+CEvd6SY3hIP/0ZcoNFPzEgctEGnzuSe2rzP kVFwH/l4AZSz0tccQDXyD+JvQ7FQhqR5iXYDO9LIHfqNfNVjLw4Ty5wOoWykMsUh KSUtt4hz7ab+xfEVKWNtaZvup0C3+5DABU6jf9mG5mLhD4oTHBUCWDu+b6HLvZWL MyoIS6gHYi2oRXtliRIj6ENUH4McOuZMRLLw//trBffHJoa9sZiehSaf3xk3NTYD 7jNmW11QSiJKLxcSaQpGxw/8QaXwnvttaZDM8eIN5F8o27m4FKISYcZDyJSm8SxW d+9Uy1ZSw+PjhBu93LNYhWBAlc69zusRuzsGqjIJSS0c+RtNDPaPrPF4u4FShewG FD5ZqfjVCn6OsDJlxlO7n1wYsSnNxbPdKoZjGyfPSqd4VYL6+QPTlb6P5FaRUAJm oHEgCH7i8g5kkrScBfKvzE78lPlyj+EDw2WFj8oiYEl8hxpcTu8XquVvA8HcHDdI PTWPRIhKNpECsoaFdEj2bJKQDTg6HWVf8YhjwcUv97Fids5ZD+M0rYNhiB9SlGXs h/j3etK4owMVBWzsG7XGa+PfE/JNMjJ6b71oQ1zHfKH3KTMQ/rpUOcBoEKXSjqbh n87SfVNZBTFuJPnTScUmZZawqh7gE0JEo6hkuPMIB/rfQoZU+Bo7jLp4c0UrLGzK LJ29f9ghQnOiD0hsAfwH =SzYz -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu May 21 12:41:12 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 21 May 2015 14:41:12 +0200 Subject: [getdns-users] getdns 0.2.0 released In-Reply-To: <555DD0AA.6030107@nlnetlabs.nl> References: <555DD0AA.6030107@nlnetlabs.nl> Message-ID: <555DD268.7000909@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am terribly sorry, but I had the md5 and sha1 values wrong. They should have been: md5 : 268ebec9058f29ef7e203fbb3b5f5c0f sha1: 6843984f7ed8109302bda3b37f5247fd49827f90 Op 21-05-15 om 14:33 schreef Willem Toorop: > Dear all, > > I am pleased to announce version 0.2.0 of our getdns API > implementation. > > This release has its intermediate version bumped to indicate that > we consider the native stub operation, introduced in version 0.1.6, > to be in a mature state. > > Besides bug fixes, the DNS over TLS transport option, introduced > in the previous version, has been fully incorporated in the native > stub module and is now truly asynchronous in all its phases; > including the TCP and the TLS handshake. > > In addition, a new transport option is introduced with this > release: > GETDNS_TRANSPORT_STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN > > A list of servers supporting TLS on port 1021 and STARTTLS on port > 53 for testing purposes is available on the sinodun portal, here: > https://portal.sinodun.com/wiki/display/TDNS/DNS-over-TLS+test+servers > > > > link: https://getdnsapi.net/dist/getdns-0.2.0.tar.gz md5 : > 4abf8be703a5040354e66d720922904d sha1: > 7248654e57848c2b2a3d5c33ff86f2f7ca121ccf pgp : > https://getdnsapi.net/dist/getdns-0.2.0.tar.gz.asc > > > ChangeLog ========= * 2015-05-21: Version 0.2.0 * Fix libversion > numbering: Thanks Daniel Kahn Gillmor * run_once method for the > libevent extension * autoreconf -fi on FreeBSD always, because of > newer libtool version suitable for FreeBSD installs too. Thanks > Robert Edmonds * True asynchronous processing of the new TLS > transport options * > STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN transport > option. * Manpage fixes: Thanks Anthony Kirby > _______________________________________________ Users mailing list > Users at getdnsapi.net http://getdnsapi.net/mailman/listinfo/users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVXdJoAAoJEOX4+CEvd6SYYxMP/imPIiHyZZKGq77BKkZfInd8 bgawqSbGp5lhzSpgokzWFjMbEaKzYLbwdH6I6RAwQu+YYOWq+CZcmRfWeX3JRiyU le7HRxj68x4adYLjJNtWcct90wDXhXMIOEIdw5a7E5OEy83PMyIrGK3vgtwMmiT0 uirhIKhYJl1TfW++nhQUzZAf+SAKZW6ofZYDOBEp82urVgeVg4SaVxqEDOzoEKnN ZId+pLV8bzZf6h8sIdzotiJCozOkuawYjYT3nXJnSP8YhPfn07DVKdRAl+OYrbfA 1nnaL8Ropu5YPJZl+zf7dq9g69zmg8tyzs+8wF0mH/f6Xafa6Rvbaqx4xjtl9C1w xQ/nby1a8GXNb90aMWrHFgHskyxnqd/tEa6BytbePlC0EN4x1rBkBjXb74ArvxrU nNimvZy+Y6kXeibnZTcV0pLJ1yLbedhi2dYaqmq7yk8Ehny6LIEAB37YMJ2c112E 3dxdgrluLFq3mGSh2A6sACmOxDKAXlKXKQ5ZMCaDmCNlnSWQIhwXBaBLXcthMD8V PVox2hToz/y6crVnaiqMtF1a6MZf2iV1Kqo8hTrmFU7FGSeDieBTrBQ/8hxV6gWY vTsSuBKO5vN1FakvfXWpi/txvepK74NdGrYg2AZuz3SY7j7PzDvkrYpXOB2Y3yFq x9n/XMI9NEHJI7lY/xQc =BHZ+ -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Thu May 21 16:52:36 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 May 2015 12:52:36 -0400 Subject: [getdns-users] getdns 0.2.0 released In-Reply-To: <555DD268.7000909@nlnetlabs.nl> References: <555DD0AA.6030107@nlnetlabs.nl> <555DD268.7000909@nlnetlabs.nl> Message-ID: <87wq01swiz.fsf@alice.fifthhorseman.net> On Thu 2015-05-21 08:41:12 -0400, Willem Toorop wrote: > I am terribly sorry, but I had the md5 and sha1 values wrong. > They should have been: > > md5 : 268ebec9058f29ef7e203fbb3b5f5c0f > sha1: 6843984f7ed8109302bda3b37f5247fd49827f90 verified, thanks :) 0.2.0 is now in debian unstable, and is making its way through the buildds: https://buildd.debian.org/status/logs.php?pkg=getdns&ver=0.2.0-1&suite=sid Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: