From willem at nlnetlabs.nl Tue Nov 13 11:17:19 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 13 Nov 2012 12:17:19 +0100 Subject: [ldns-users] ldns 1.6.16 released Message-ID: <50A22C3F.4050202@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers, ldns users and OpenDNSSEC users, We have found an issue in ldns releases 1.6.14 and 1.6.15. Both versions have a bug whereby during zone-parsing, the NSEC3 generation code fails to create an empty bitmap on empty non-terminals. The bug was discovered when the new ldns became a part of the OpenDNSSEC test environment; the pre-release ldns regression tests did not cover this specific case. Besides, ldns 1.6.14 and 1.6.15 do not build a working pyldns module (the python bindings to ldns). Does this affect you? - --------------------- This affects users that have empty non-terminals in their zones and sign their zones NSEC3-style. This does not affect users signing there zones NSEC-style, nor does this affect users that have no empty non-terminals in their zone, nor does this affect users who are running ldns 1.6.13 or lower. How to resolve? - --------------- If you are using ldns 1.6.14 or 1.6.15, please update your systems to use ldns version 1.6.16 or higher, available here: link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.16.tar.gz sha1: 5b4fc6c5c3078cd061905c47178478cb1015c62a How could this happen? - ---------------------- Thanks to the thorough code reviews, release 1.6.14 fixed a larger amount of bugs than before. Fixing bugs always has the risk of introducing new bugs or reintroducing old bugs. For long we perform the practice of "Continuous integration"; On each commit we automatically perform general unit tests and numerous tests that verify that earlier detected bugs have not accidentally re-emerged. Unfortunately we did not yet run the test suites of software using ldns as part of our "Continuous integration". We did thus not detect the influence those fixes had on the ldns using software. How are we going to prevent this in the future? - ----------------------------------------------- We have added regression tests to the ldns test package that run the test cases for Unbound and pyldns with the new version of ldns. This way, we can identify changes that introduce faults in software that depends on ldns in a early stage. The newly added regression tests now check for * loading of pyldns and pyldnsx * Whether the test suite of Unbound succeeds, - without building it against the new ldns version (so testing for backwards binary compatibility) - and with building it against the new ldns version. Regression testing for OpenDNSSEC has been performed manually with this release, but a similar setup as for Unbound will be deployed shortly. Please let us know if you wish to include regression tests for your software in the ldns test suite. Best regards, For NLnet Labs, Willem and Matthijs Changelog: ========== * Fix Makefile to build pyldns with BSD make * Fix typo in exporting b32_* symbols to make pyldns load again * Allow leaving the RR owner name empty in ldns-testns datafiles. * Fix fail to create NSEC3 bitmap for empty non-terminal (bug introduced in 1.6.14). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQoiw/AAoJEOX4+CEvd6SYQzUP/RUY85SevLCAV4zkL1W84N+V IyXWl/ZoitUh+C1XcLW4nCRRuwa1zPmYgpEubZxKHC9kBa3lfQl0n5VlPVohPJxl gLfG/0AhNUBigDhedJfo4rVIw2xqDso2M0ljI6fiY7J6DnfvbugPEgbjcnMcfU+e IxEHlFrloeT6Opv7Jz4nSlOpqVWx2LaFGR0wrDgEoI7N7wb/93xFEawyNvFIr4b6 KlzFF+Y6VqG0+DbzWap2+nHqhcKLvpzaYmQhyOtfyRtwabd4LpSAXROgv/LOi5bm 7/v45NwlwbCp/mdwVqJ4iwFG2dxrVTbPPHAd93Ko3InkrH+eZGgRQIr4NMI8pFNf t6uphJWIoe3zuFlt50WAnOsgzgqZLr8KVQVEsGoue5UANPYlQTg7ZVlOUHUeCgqj LIbu5aBDAnJjJk2IkM+sSupWGKgfVxRNtqqZFrsOY0VwI3ELcZEELnfBATunHDsY el6rai8XYupWt5VAGsQP8NF5AVqua5hoN0ILYqzBQ0VWWEdAQIGM+fRx9HX645IS JJszMlgogzx2lrcsPfnPjVSK5SJ/Y8iuYG+KptvX0R86Q0ZTfC4cBKnyPTOUGTbf 8JgbIvbP7cPmEWonfgEMvdStkVrq0HMbzDHtd4eYXM5Vltmlpco2/JNldKSdnKR6 HW7tS5qddF2wiaRt40Zh =4sEk -----END PGP SIGNATURE----- From peter.van.dijk at netherlabs.nl Wed Nov 21 15:57:09 2012 From: peter.van.dijk at netherlabs.nl (Peter van Dijk) Date: Wed, 21 Nov 2012 16:57:09 +0100 Subject: [ldns-users] ldns-verify-zone bug Message-ID: <936A9421-16FB-4568-95D5-353B1719B6BD@netherlabs.nl> Hello, given test.com as hosted at http://7bits.nl/tmp/unlisted/test.com.txt, I get: [vagrant at pdns ~/pdns/regression-tests/ldns-verify-zone]$ ldns-verify-zone test.com original of NSEC3 hashed name could not be found at 81 [vagrant at pdns ~/pdns/regression-tests/ldns-verify-zone]$ ldns-read-zone -z test.com > test.com.canon [vagrant at pdns ~/pdns/regression-tests/ldns-verify-zone]$ ldns-verify-zone test.com.canon Checking: test.com. ... Zone is verified and complete (Note that line 81 is the last line in the file.) A simple 'sort' also "fixes" the zone for ldns-verify-zone. Kind regards, -- Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From jpmens.dns at gmail.com Wed Nov 21 16:21:50 2012 From: jpmens.dns at gmail.com (Jan-Piet Mens) Date: Wed, 21 Nov 2012 17:21:50 +0100 Subject: [ldns-users] ldns-verify-zone bug In-Reply-To: <936A9421-16FB-4568-95D5-353B1719B6BD@netherlabs.nl> References: <936A9421-16FB-4568-95D5-353B1719B6BD@netherlabs.nl> Message-ID: <20121121162150.GA81727@jmbp.ww.mens.de> > [vagrant at pdns ~/pdns/regression-tests/ldns-verify-zone]$ ldns-verify-zone test.com > original of NSEC3 hashed name could not be found at 81 I get the same error with 1.6.16, but the zone verifies correctly with ldns 1.6.13: $ curl -o test.com http:// your url $ ldns-verify-zone test.com Checking: test.com. Checking: _underscore.test.com. Checking: c.test.com. Checking: b.c.test.com. Checking: a.b.c.test.com. Checking: *.a.b.c.test.com. Checking: counter.test.com. Checking: dc.test.com. Checking: _tcp.dc.test.com. Checking: _double._tcp.dc.test.com. Checking: _ldap._tcp.dc.test.com. Checking: enum.test.com. Checking: server1.test.com. Checking: test.test.com. Checking: *.test.test.com. Checking: www.test.test.com. Checking: very-long-txt.test.com. Checking: within-server.test.com. Checking: www.test.com. Zone is verified and complete Regards, -JP From Willem at NLnetLabs.nl Wed Nov 21 22:26:14 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 21 Nov 2012 23:26:14 +0100 Subject: [ldns-users] ldns-verify-zone bug In-Reply-To: <20121121162150.GA81727@jmbp.ww.mens.de> References: <936A9421-16FB-4568-95D5-353B1719B6BD@netherlabs.nl> <20121121162150.GA81727@jmbp.ww.mens.de> Message-ID: <50AD5506.1040401@NLnetLabs.nl> Thanks Peter! The issue is triggered when the last line of a parsed zone is a NSEC3 (or its RRSIG) covering an empty non-terminal. c.test.com in your case. When the last record would have been the qd81ag9inqts1ocs7api0pji94k27btr.test.com. NSEC3 or RRSIG record, the error would not have occurred! ldns-1.6.13 did not get in this condition, because it had a different bug that would allow for NSEC3s not covering anything within the zone. The fix for that bug unfortunately triggered this one. Thanks again for noticing and reporting! -- Willem Op 21-11-12 17:21, Jan-Piet Mens schreef: >> [vagrant at pdns ~/pdns/regression-tests/ldns-verify-zone]$ ldns-verify-zone test.com >> original of NSEC3 hashed name could not be found at 81 > > I get the same error with 1.6.16, but the zone verifies correctly with > ldns 1.6.13: > > $ curl -o test.com http:// your url > $ ldns-verify-zone test.com > Checking: test.com. > Checking: _underscore.test.com. > Checking: c.test.com. > Checking: b.c.test.com. > Checking: a.b.c.test.com. > Checking: *.a.b.c.test.com. > Checking: counter.test.com. > Checking: dc.test.com. > Checking: _tcp.dc.test.com. > Checking: _double._tcp.dc.test.com. > Checking: _ldap._tcp.dc.test.com. > Checking: enum.test.com. > Checking: server1.test.com. > Checking: test.test.com. > Checking: *.test.test.com. > Checking: www.test.test.com. > Checking: very-long-txt.test.com. > Checking: within-server.test.com. > Checking: www.test.com. > Zone is verified and complete > > Regards, > > -JP > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From mellery451 at gmail.com Thu Nov 29 21:41:33 2012 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 29 Nov 2012 13:41:33 -0800 Subject: [ldns-users] simple use case - change domain in query Message-ID: <6E021E7E-DFFF-4F8F-B397-3CB9AF4F69CA@gmail.com> Hello LDNS users, I'm trying to use LDNS to tweak an existing DNS request. In this case, I want to modify the domain in the query. Here is the code I've tried so far (minus error checking): /* dns_data, dns_data_len, and new_domain are inputs */ ldns_pkt *query = NULL; ldns_rr *question = NULL; ldns_rdf *new_name = NULL; uint8_t *new_dns_data = NULL size_t new_dns_data_len = 0U; ldns_wire2pkt(&query, dns_data, dns_data_len); ldns_str2rdf_str(&new_name, new_domain); question = ldns_rr_list_rr(ldns_pkt_question(query), 0U); ldns_rr_set_owner(question, new_name); ldns_pkt2wire(&new_dns_data, query, &new_dns_data_len); ldns_pkt_free(query); The code runs and doesn't produce any errors (I'm checking return codes), but the resulting buffer in new_dns_data subsequently fails in a call to ldns_wire2pkt, so I assume that means it's invalid or corrupt. Any thoughts about what I'm doing wrong or another way to accomplish what I'd like to do (change the FQDN in the query..). Thanks, Mike Ellery -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at nlnetlabs.nl Fri Nov 30 09:15:49 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Fri, 30 Nov 2012 10:15:49 +0100 Subject: [ldns-users] simple use case - change domain in query In-Reply-To: <6E021E7E-DFFF-4F8F-B397-3CB9AF4F69CA@gmail.com> References: <6E021E7E-DFFF-4F8F-B397-3CB9AF4F69CA@gmail.com> Message-ID: <50B87945.3020702@nlnetlabs.nl> Hi Mike, It is hard to tell, the code example is obviously not complete. What error is ldns_wire2pkt giving you? Perhaps you can use ldns_pkt_print() to see how the new packet looks like. Also, I guess you want to use ldns_str2rdf_dname() instead of ldns_str2rdf_str() . Best regards, Matthijs On 11/29/2012 10:41 PM, Michael Ellery wrote: > Hello LDNS users, > > I'm trying to use LDNS to tweak an existing DNS request. In this case, I > want to modify the domain in the query. Here is the code I've tried so > far (minus error checking): > > /* dns_data, dns_data_len, and new_domain are inputs */ > > ldns_pkt *query = NULL; > ldns_rr *question = NULL; > ldns_rdf *new_name = NULL; > uint8_t *new_dns_data = NULL > size_t new_dns_data_len = 0U; > > ldns_wire2pkt(&query, dns_data, dns_data_len); > ldns_str2rdf_str(&new_name, new_domain); > question = ldns_rr_list_rr(ldns_pkt_question(query), 0U); > ldns_rr_set_owner(question, new_name); > ldns_pkt2wire(&new_dns_data, query, &new_dns_data_len); > ldns_pkt_free(query); > > > The code runs and doesn't produce any errors (I'm checking return > codes), but the resulting buffer in new_dns_data subsequently fails in a > call to ldns_wire2pkt, so I assume that means it's invalid or corrupt. > > Any thoughts about what I'm doing wrong or another way to accomplish > what I'd like to do (change the FQDN in the query..). > > Thanks, > Mike Ellery > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From mellery451 at gmail.com Fri Nov 30 23:25:47 2012 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 30 Nov 2012 15:25:47 -0800 Subject: [ldns-users] simple use case - change domain in query In-Reply-To: <50B87945.3020702@nlnetlabs.nl> References: <6E021E7E-DFFF-4F8F-B397-3CB9AF4F69CA@gmail.com> <50B87945.3020702@nlnetlabs.nl> Message-ID: <3632A04A-7C81-4D00-A8C4-9E7BAD76B3CD@gmail.com> Matthijs, Thanks for your reply. It looks like switching to ldns_str2rdf_dname() has fixed my problem, at least in preliminary testing. Best, Mike On Nov 30, 2012, at 1:15 AM, Matthijs Mekking wrote: > Hi Mike, > > It is hard to tell, the code example is obviously not complete. What error is ldns_wire2pkt giving you? Perhaps you can use ldns_pkt_print() to see how the new packet looks like. > > Also, I guess you want to use ldns_str2rdf_dname() instead of ldns_str2rdf_str() . > > Best regards, > Matthijs > > > On 11/29/2012 10:41 PM, Michael Ellery wrote: >> Hello LDNS users, >> >> I'm trying to use LDNS to tweak an existing DNS request. In this case, I >> want to modify the domain in the query. Here is the code I've tried so >> far (minus error checking): >> >> /* dns_data, dns_data_len, and new_domain are inputs */ >> >> ldns_pkt *query = NULL; >> ldns_rr *question = NULL; >> ldns_rdf *new_name = NULL; >> uint8_t *new_dns_data = NULL >> size_t new_dns_data_len = 0U; >> >> ldns_wire2pkt(&query, dns_data, dns_data_len); >> ldns_str2rdf_str(&new_name, new_domain); >> question = ldns_rr_list_rr(ldns_pkt_question(query), 0U); >> ldns_rr_set_owner(question, new_name); >> ldns_pkt2wire(&new_dns_data, query, &new_dns_data_len); >> ldns_pkt_free(query); >> >> >> The code runs and doesn't produce any errors (I'm checking return >> codes), but the resulting buffer in new_dns_data subsequently fails in a >> call to ldns_wire2pkt, so I assume that means it's invalid or corrupt. >> >> Any thoughts about what I'm doing wrong or another way to accomplish >> what I'd like to do (change the FQDN in the query..). >> >> Thanks, >> Mike Ellery >> >> >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> >