From paul at xelerance.com Fri Sep 2 22:28:50 2011 From: paul at xelerance.com (Paul Wouters) Date: Fri, 2 Sep 2011 18:28:50 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems Message-ID: Christopher Olah wrote: > (1) ldns_resolver stops responding > > Creating reproducible errors here is tricky, because things are so > dependent on the state of things outside my control. However, the > following code has been demonstrating it quite reliability on centos6 > with pyLDNS 1.3.40 He meant ldns-1.6.10 > import ldns > > ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf") > #Drop nameservers > while self._ldns_resolver.pop_nameserver(): > ? ?pass > #Set nameserver to xelerance's to aid repropducability > address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65") > ldns_resolver.push_nameserver(address) > #Make queries. The first will work OK, but the next two will break. > print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, > ldns.LDNS_RR_CLASS_IN ) > print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY, > ldns.LDNS_RR_CLASS_IN ) > print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, > ldns.LDNS_RR_CLASS_IN ) I can confirm this problem on centos6. I did not see it on another machine running centos5, though both machines show a VERY long query time for "xelerance.com" against 76.10.157.65, prob due to that machine being an embedded dnsmasq like forwarding proxy (stock openwrt setup) Running tcpdump, I see: 17:58:17.573349 IP 193.110.157.68.49261 > 76.10.157.65.domain: 39418+ ANY? google.com. (28) 17:58:17.701311 IP 76.10.157.65.domain > 193.110.157.68.49261: 39418 15/4/4 MX aspmx.l.google.com. 10, MX alt1.aspmx.l.google.com. 20, MX alt2.aspmx.l.google.com. 30, MX alt3.aspmx.l.google.com. 40, MX alt4.aspmx.l.google.com. 50, TXT "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all", A 74.125.226.82, A 74.125.226.83, A 74.125.226.84, A 74.125.226.80, A 74.125.226.81, NS ns3.google.com., NS ns4.google.com., NS ns2.google.com., NS ns1.google.com. (502) 17:58:17.702464 IP 193.110.157.68.57555 > 76.10.157.65.domain: 9877+ ANY? xelerance.com. (31) 17:58:22.708357 IP 193.110.157.68.41786 > 76.10.157.65.domain: 9877+ ANY? xelerance.com. (31) 17:58:27.713547 IP 193.110.157.68.46401 > 76.10.157.65.domain: 9877+ ANY? xelerance.com. (31) 17:58:27.900993 IP 76.10.157.65.domain > 193.110.157.68.46401: 9877| 2/0/0 RRSIG, RRSIG (377) 17:58:27.901165 IP 193.110.157.68.34584 > 76.10.157.65.domain: 9877+ [1au] ANY? xelerance.com. (42) 17:58:27.906896 IP 76.10.157.65.domain > 193.110.157.68.57555: 9877| 2/0/0 RRSIG, RRSIG (377) 17:58:27.912989 IP 76.10.157.65.domain > 193.110.157.68.41786: 9877| 2/0/0 RRSIG, RRSIG (377) 17:58:32.906321 IP 193.110.157.68.44629 > 76.10.157.65.domain: 9877+ [1au] ANY? xelerance.com. (42) 17:58:37.911606 IP 193.110.157.68.60266 > 76.10.157.65.domain: 9877+ [1au] ANY? xelerance.com. (42) Note that the last call to ldns_resolver.query() using "google.com" does NOT generate a DNS packet at all. It seems the resolver object is left in some broken state due to the previous TC packet. > It just returns Nones. Contrast this with dig ANY xelerance.com @76.10.157.65 > > Some observations: This bug seems to be associated with truncated packets. Using I've attached the test program, Paul -------------- next part -------------- #!/usr/bin/python import ldns ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf") while ldns_resolver.pop_nameserver(): pass address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65") ldns_resolver.push_nameserver(address) print "doing google" print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) print "doing xelerance" print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) print "doing google" print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) print "doing google again" print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) From amelton at gmail.com Thu Sep 8 16:38:46 2011 From: amelton at gmail.com (Andrew Melton) Date: Thu, 8 Sep 2011 09:38:46 -0700 Subject: [ldns-users] Example Program Message-ID: I am trying to do some testing of TTL values related to RFC 2181 section 5.2. Specifically, returning two separate RR with different TTLs. Is there an example of ldns which constructs multiple RRs in an RRset for a query from a hash entry? It doesn't really matter what the request is, I just want to return two records with differing TTLs to test conformance of an application. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at NLnetLabs.nl Mon Sep 12 20:46:31 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 12 Sep 2011 22:46:31 +0200 Subject: [ldns-users] pyLDNS Problems In-Reply-To: References: Message-ID: <4E6E6FA7.30709@nlnetlabs.nl> Op 03-09-11 00:28, Paul Wouters schreef: > I can confirm this problem on centos6. I did not see it on another > machine running > centos5, though both machines show a VERY long query time for > "xelerance.com" > against 76.10.157.65, prob due to that machine being an embedded > dnsmasq like > forwarding proxy (stock openwrt setup) HI Paul and Chris, I have setup pyldns 1.6.10 on a virtualbox with CentOS 6.0 and unfortunately cannot reproduce the error. With me the program answers within 3 to 8 seconds. I'm not really sure how to tackle the issue. Maybe with a ``ltrace -r python test-ldns.py''? Or running it in gdb? From paul at xelerance.com Sun Sep 18 19:13:56 2011 From: paul at xelerance.com (Paul Wouters) Date: Sun, 18 Sep 2011 15:13:56 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems Message-ID: > Op 03-09-11 00:28, Paul Wouters schreef: > > I can confirm this problem on centos6. I did not see it on another > > machine running > > centos5, though both machines show a VERY long query time for > > "xelerance.com" > > against 76.10.157.65, prob due to that machine being an embedded > > dnsmasq like > > forwarding proxy (stock openwrt setup) > HI Paul and Chris, I have setup pyldns 1.6.10 on a virtualbox with > CentOS 6.0 and unfortunately cannot reproduce the error. > With me the program answers within 3 to 8 seconds. Does it work 3 times? The test first checks google.com, then xelerance.com, then google.com again. The last two fail. This might be related to EDNS and/or UDP fragments gone missing. > I'm not really sure how to tackle the issue. Maybe with a ``ltrace -r > python test-ldns.py''? Or running it in gdb? Running it with ltrace only gave the following output (apart from the print output): 0.000000 __libc_start_main(0x400710, 2, 0x7fff4d48a908, 0x400730, 0x400720 0.000170 Py_Main(2, 0x7fff4d48a908, 0x7fff4d48a920, 0, 0x7f6cd7384300) = 0 16.525978 +++ exited (status 0) +++ I could probably clone a VM in that network and give you access to it? Paul From willem at NLnetLabs.nl Mon Sep 19 10:31:30 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 19 Sep 2011 12:31:30 +0200 Subject: [ldns-users] pyLDNS Problems In-Reply-To: References: Message-ID: <4E771A02.2020206@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18-09-11 21:13, Paul Wouters wrote: > Does it work 3 times? The test first checks google.com, then xelerance.com, > then google.com again. The last two fail. This might be related to EDNS > and/or > UDP fragments gone missing. Paul, Chris, I can finally reproduce the error. Even on my own Ubuntu box when I drop fragments from the PREROUTING table with: iptables -t mangle -A PREROUTING -f -j DROP Hopefully I can follow up with a fix now soon. Regards, Willem -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOdxoCAAoJEOX4+CEvd6SYAw4P/2c2+Rgp1tOtaV9l/Ya7I2Ni JsDeRFAviYxsIhmUMRg932M0p3B5ucwGmjQ4WIeNmNVZ8icJD/ytPAOG8qoFCjCa aJcLTIOMosM40bVQmhyJtGqFVovFDXFOmLuyYqOllIs1nGtA7jVxFajprsySW1J7 xIIE3RuZVl9gLKwYKOmlrcWNRF98KoSJDcZdGtO7y7bQ83HmnjER0pH8HRq2htN4 VQyONecd6YyS3vpjMccU9PF73ersbOe2a2g1Jdqa66BTolB3HZuZ30q8bOufh5k/ /aL3QkYUjvzOpbNf9fD0JeH4fcmMEYwNw3pJ2euQLNCcBqNgTCPpvEEAZuu9RVlD D3sCXcGpq7rqmif1xqGRbLb9av4SlE6RzcWfN/XjQ3+Ek4xDxAVEMgbPF28IzmyX O6NuclkqC8A43WkSCLa5quHWLVKANbySDXM/ANFHeAmK+ic195UqY+wBx6P/0JpS 1QHG75vHq5gnIhVhZm25uoYrWNhWYAvQjuCu2yXFC9M6074eneCihcyIKh8VVVhB HSoK60OMRdEt3QQdjnoY1d1mRjjToo84mf9Ug2OXSc4OE1GyjN2Q2svvWDjSfKXO DckFlRGmKclVQmch1iCz7Y941ZCrvBvuhzTHE1HFu8UJbQHvzmZnDNt5lY0AyBrL OWW43KJeiiaeKnwhL+cA =qnOC -----END PGP SIGNATURE----- From willem at NLnetLabs.nl Mon Sep 19 13:22:04 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 19 Sep 2011 15:22:04 +0200 Subject: [ldns-users] pyLDNS Problems In-Reply-To: <4E771A02.2020206@nlnetlabs.nl> References: <4E771A02.2020206@nlnetlabs.nl> Message-ID: <4E7741FC.5020304@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul and Chris, I found the culprit! ldns_resolver_send_pkt in resolver.c first tries normal UDP transmission. Then it tries UDP transmission with edns0 size 4096. When fragments are dropped (which was the case with you) a network error is returned and ldns_resolver_send_pkt then continues trying TCP. However, because of the network error, the non responsive nameservers in the resolver (in your case 76.10.157.65) is marked unreachable by ldns_send. As a result the ldns_resolver has no reachable nameservers any more and doesn't even try to send a query out. The reachability of nameservers is in the round trip time information (_rtt field) of an ldns_resolver struct. A round trip time of LDNS_RESOLV_RTT_INF means unreachable. I have fixed the issue by preserving the round trip time information when edns0 with size 4096 is tried. The fix is in revision r3551 and will be in the 1.6.11 release. Thanks for you bug report! Willem On 19-09-11 12:31, Willem Toorop wrote: > On 18-09-11 21:13, Paul Wouters wrote: >> Does it work 3 times? The test first checks google.com, then xelerance.com, >> then google.com again. The last two fail. This might be related to EDNS >> and/or >> UDP fragments gone missing. > > Paul, Chris, I can finally reproduce the error. Even on my own Ubuntu > box when I drop fragments from the PREROUTING table with: > > iptables -t mangle -A PREROUTING -f -j DROP > > Hopefully I can follow up with a fix now soon. > > Regards, Willem _______________________________________________ ldns-users mailing list ldns-users at open.nlnetlabs.nl http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOd0H8AAoJEOX4+CEvd6SYyh0P/jbfrxZ2rwcZamefCSH5+co3 K1E5PBro7PvQqb48JPUvoDb/Ezfq6/K4dJQGp8C8E8GdJqnx2l7oTsY/ymt44vLB 0hRij7XLKb/O6IsWMN2XX/T5hJC7mTexfCKONkR4IaFrV259YkWCMiZROgZqV6I/ LbNQ/LQYL8J9kCzj49y3F0tcZ8Hd5dYhdsDQ2vIN6MJij/piudRdpop4DpEsd43t FSzRV5CHft2XfHdpQQVjf3ji1CrNrB9Gm7NFcfOxQu5AryA9xymk63fsQ8n+LOE1 IfK2XXUloyQU6E6S6muBB88rTQpuRCawXXDMQKrNST/UA6L62fJb6Yq5BnNA0nXQ +MBQCSiL3WO8D7fOID+CvW10BHLqikteVxEMNpVTgyezUBn2JvsOXu9h11lfbPgC Xfhh2diQtTkJ3IT08WVYcB6iL4BaFwopwITj1VH1GIhi86H9gvU8k34fzn6KvGTj e8ACGv1MCyTyPjiCyU0gxe1y08ZTpd2FIcRTVhQH1ggJabGryEAEBvRUIMSC8AUk 8+scvAy89N7trisvT16vR+b7oxE8uGd738IQY+mqMHBon5peyt0XutElsZ6g4ETC /QPchtykUfxOV2VBolIP60kYPNGSgT2AQvIRbHwTpebDmOrGlwzuyqfShBzTFQBo TwY1ozS9yqZsH9byIZ1F =zk3d -----END PGP SIGNATURE----- From paul at xelerance.com Mon Sep 19 16:10:18 2011 From: paul at xelerance.com (Paul Wouters) Date: Mon, 19 Sep 2011 12:10:18 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems In-Reply-To: <4E7741FC.5020304@nlnetlabs.nl> References: <4E771A02.2020206@nlnetlabs.nl> <4E7741FC.5020304@nlnetlabs.nl> Message-ID: On Mon, 19 Sep 2011, Willem Toorop wrote: > I found the culprit! Excellent. > I have fixed the issue by preserving the round trip time information > when edns0 with size 4096 is tried. The fix is in revision r3551 and > will be in the 1.6.11 release. I've built it and confirm it is now fixed! Though perhaps some EDNS backoff attempt would be good too? :) Note, I still see these in 1.6.10, not sure if you addressed them: contrib/python/ldns_wrapper.c: In function 'SWIG_PyInstanceMethod_New': contrib/python/ldns_wrapper.c:1049:59: warning: unused parameter 'self' contrib/python/ldns_wrapper.c:1049:75: warning: unused parameter 'func' contrib/python/ldns_wrapper.c: In function '_PySwigObject_type': contrib/python/ldns_wrapper.c:1829:7: warning: missing initializer contrib/python/ldns_wrapper.c:1829:7: warning: (near initialization for 'tmp.tp_version_tag') contrib/python/ldns_wrapper.c: In function '_PySwigPacked_type': contrib/python/ldns_wrapper.c:2004:7: warning: missing initializer contrib/python/ldns_wrapper.c:2004:7: warning: (near initialization for 'tmp.tp_version_tag') contrib/python/ldns_wrapper.c: In function 'SWIG_Python_MustGetPtr': contrib/python/ldns_wrapper.c:2666:63: warning: unused parameter 'argnum' contrib/python/ldns_wrapper.c: In function 'ldns_wire2pkt_': contrib/python/ldns_wrapper.c:3930:13: warning: unused variable 'resultobj' contrib/python/ldns_wrapper.c: In function '_wrap_ldns_print_rr_rdf__varargs__': contrib/python/ldns_wrapper.c:13081:115: warning: unused parameter 'varargs' contrib/python/ldns_wrapper.c: In function 'swig_varlink_type': contrib/python/ldns_wrapper.c:38843:7: warning: missing initializer contrib/python/ldns_wrapper.c:38843:7: warning: (near initialization for 'tmp.tp_version_tag') And some minor man page issues: ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_new.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_derive_trust_tree_dnskey_rrset.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_contains_keys.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_print.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_derive_trust_tree_no_sig.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_derive_trust_tree_normal_rrset.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_print_sm.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_derive_trust_tree.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_free.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_buffer_export.3.gz 60: warning: macro `\\0'.' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_buffer_clear.3.gz 60: warning: macro `\\0'.' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_buffer_free.3.gz 60: warning: macro `\\0'.' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_buffer_printf.3.gz 60: warning: macro `\\0'.' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_buffer_new.3.gz 60: warning: macro `\\0'.' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_buffer_new_frm_data.3.gz 60: warning: macro `\\0'.' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_depth.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_derive_trust_tree_ds_rrset.3.gz 131: warning: macro `normal'' not defined ldns.x86_64: W: manual-page-warning /usr/share/man/man3/ldns_dnssec_trust_tree_add_parent.3.gz 131: warning: macro `normal'' not defined ldns-devel.x86_64: W: no-manual-page-for-binary ldns-config This one I'm unsure about. Is this needed and/or different from the system .so ? ldns-python.x86_64: W: private-shared-object-provides /usr/lib/python2.7/site-packages/_ldns.so.1.6.10 _ldns.so.1()(64bit) I still have sitelib vs sitearch issues on 1.6.10, but I assume that will be resolved in 1.6.11? This might need more then just the: sed -i "s/0,0/1,0/" acx_python.m4 Perhaps it needs a similar fix as was done recently for unbound-python? I pushed 1.6.10-2, that includes this fix plus the ldnsx.py module into rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=3360890 Paul From willem at NLnetLabs.nl Mon Sep 19 21:46:13 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 19 Sep 2011 23:46:13 +0200 Subject: [ldns-users] pyLDNS Problems In-Reply-To: References: <4E771A02.2020206@nlnetlabs.nl> <4E7741FC.5020304@nlnetlabs.nl> Message-ID: <4E77B825.1050104@nlnetlabs.nl> Hi Paul, The warnings compiling pyldns are about code automatically generated by swig. I have tweaked configure.ac a bit to suppress those warnings. I also reformatted some of the comment texts to get rid of the "macro not defined" warnings in the manpages. I guess I have to write a man page for ldns-config to make *all* your warnings go away :/ > This one I'm unsure about. Is this needed and/or different from the > system .so ? > > ldns-python.x86_64: W: private-shared-object-provides > /usr/lib/python2.7/site-packages/_ldns.so.1.6.10 _ldns.so.1()(64bit) It contains al the code Python needs to use the system .so (on which it is dependent too) > I still have sitelib vs sitearch issues on 1.6.10, but I assume that > will be resolved in 1.6.11? > This might need more then just the: sed -i "s/0,0/1,0/" acx_python.m4 > Perhaps it needs a similar fix as was done recently for unbound-python? I am not sure what you mean. I have replaced acx_python.m4 with the more recent ax_python_devel.m4 from the Autoconf Archive. Maybe that already solves the issue. > I pushed 1.6.10-2, that includes this fix plus the ldnsx.py module > into rawhide: Shall I include ldnsx.py in the next ldns release? Chris? -- Willem From paul at xelerance.com Mon Sep 19 22:03:42 2011 From: paul at xelerance.com (Paul Wouters) Date: Mon, 19 Sep 2011 18:03:42 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems In-Reply-To: <4E77B825.1050104@nlnetlabs.nl> References: <4E771A02.2020206@nlnetlabs.nl> <4E7741FC.5020304@nlnetlabs.nl> <4E77B825.1050104@nlnetlabs.nl> Message-ID: On Mon, 19 Sep 2011, Willem Toorop wrote: > The warnings compiling pyldns are about code automatically generated by > swig. I have tweaked configure.ac a bit to suppress those warnings. I > also reformatted some of the comment texts to get rid of the "macro not > defined" warnings in the manpages. Okay. > I guess I have to write a man page for ldns-config to make *all* your > warnings go away :/ That's the spirit! >> This one I'm unsure about. Is this needed and/or different from the >> system .so ? >> >> ldns-python.x86_64: W: private-shared-object-provides >> /usr/lib/python2.7/site-packages/_ldns.so.1.6.10 _ldns.so.1()(64bit) > It contains al the code Python needs to use the system .so (on which it > is dependent too) Oki >> I still have sitelib vs sitearch issues on 1.6.10, but I assume that >> will be resolved in 1.6.11? >> This might need more then just the: sed -i "s/0,0/1,0/" acx_python.m4 >> Perhaps it needs a similar fix as was done recently for unbound-python? > I am not sure what you mean. I have replaced acx_python.m4 with the more > recent ax_python_devel.m4 from the Autoconf Archive. Maybe that already > solves the issue. I'll find out when you do an ldns-1.6.11rc release? >> I pushed 1.6.10-2, that includes this fix plus the ldnsx.py module >> into rawhide: > Shall I include ldnsx.py in the next ldns release? Chris? I'd say yes. Perhaps Chris wants to remove some workaround code for the latest EDNS fix from ldnsx.py though. Chris? Paul From paul at xelerance.com Tue Sep 20 17:04:58 2011 From: paul at xelerance.com (Paul Wouters) Date: Tue, 20 Sep 2011 13:04:58 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems In-Reply-To: References: <4E771A02.2020206@nlnetlabs.nl> <4E7741FC.5020304@nlnetlabs.nl> <4E77B825.1050104@nlnetlabs.nl> Message-ID: On Tue, 20 Sep 2011, Christopher Olah wrote: > Subject: Re: [ldns-users] pyLDNS Problems > > Done. So willem, you can grab: http://git.xelerance.com/cgi-bin/gitweb.cgi?p=ldnsx.git;a=blob_plain;f=ldnsx.py;h=9b59c4b26009f66b034b132f5ce3a7cf99ebd912;hb=HEAD Though you should probably also integtrate the source/ build/ and examples/ directories. Paul From willem at NLnetLabs.nl Tue Sep 20 22:51:55 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 21 Sep 2011 00:51:55 +0200 Subject: [ldns-users] pyLDNS Problems In-Reply-To: References: <4E771A02.2020206@nlnetlabs.nl> <4E7741FC.5020304@nlnetlabs.nl> <4E77B825.1050104@nlnetlabs.nl> Message-ID: <4E79190B.8090008@nlnetlabs.nl> Op 20-09-11 19:04, Paul Wouters schreef: > Though you should probably also integtrate the source/ build/ and > examples/ > directories. Have done so now in svn. I also put a --with-pyldnsx in configure which defaults to installing the ldnsx module when --with-pyldns is given. -- Willem From paul at xelerance.com Tue Sep 20 23:53:04 2011 From: paul at xelerance.com (Paul Wouters) Date: Tue, 20 Sep 2011 19:53:04 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems In-Reply-To: <4E79190B.8090008@nlnetlabs.nl> References: <4E771A02.2020206@nlnetlabs.nl> <4E7741FC.5020304@nlnetlabs.nl> <4E77B825.1050104@nlnetlabs.nl> <4E79190B.8090008@nlnetlabs.nl> Message-ID: On Wed, 21 Sep 2011, Willem Toorop wrote: > Op 20-09-11 19:04, Paul Wouters schreef: >> Though you should probably also integtrate the source/ build/ and >> examples/ >> directories. > Have done so now in svn. > I also put a --with-pyldnsx in configure which defaults to installing > the ldnsx module when --with-pyldns is given. Awesome! Is there an 1.6.11 planned? Paul From willem at NLnetLabs.nl Thu Sep 29 14:54:11 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Thu, 29 Sep 2011 16:54:11 +0200 Subject: [ldns-users] ldns 1.6.11 released Message-ID: <4E848693.3020200@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Version 1.6.11 of ldns is now available. Best regards, Willem Toorop link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.11.tar.gz sha1: 2c4537eee39a1af63e8dde4f35498ce78c968c1f 1.6.112011-09-29 * bugfix #394: Fix socket leak on errors * bugfix #392: Apex only and percentage checks for ldns-verify-zone (thanks Miek Gieben) * bugfix #398: Allow NSEC RRSIGs before the NSEC3 in ldns-verify-zone * Fix python site package path from sitelib to sitearch for pyldns. * Fix python api to support python2 and python3 (thanks Karel Slany). * bugfix #401: Correction of date/time functions algorithm and prevention of an infinite loop therein * bugfix #402: Correct the minimum and maximum number of rdata fields in TSIG. (thanks David Keeler) * bugfix #403: Fix heap overflow (thanks David Keeler) * bugfix #404: Make parsing APL strings more robust (thanks David Keeler) * bugfix #391: Complete library assessment to prevent assertion errors through ldns_rdf_size usage. * Slightly more specific error messaging on wrong number of rdata fields with the LDNS_STATUS_MISSING_RDATA_FIELDS_RRSIG and LDNS_STATUS_MISSING_RDATA_FIELDS_KEY result codes. * bugfix #406: More rigorous openssl result code handling to prevent future crashes within openssl. * Fix ldns_fetch_valid_domain_keys to search deeper than just one level for a DNSKEY that signed a DS RR. (this function was used in the check_dnssec_trace nagios module) * bugfix #407: Canonicalize TSIG dnames and algorithm fields * A new output specifier to accommodate configuration of what to show in comment texts when converting host and/or wire-format data to string. All conversion to string and printing functions have a new version that have such a format specifier as an extra argument. The default is changed so that only DNSKEY RR's are annotated with an comment show the Key Tag of the DNSKEY. * Fixed the ldns resolver to not mark a nameserver unreachable when edns0 is tried unsuccessfully with size 4096 (no return packet came), but to still try TCP. A big UDP packet might have been corrupted by fragments dropping firewalls. * Update of libdns.vim (thanks Miek Gieben) * Added the ldnsx Python module to our contrib section, which adds even more pythonisticism to the usage of ldns with Python. (Many thanks to Christpher Olah and Paul Wouters) The ldnsx module is automatically installed when --with-pyldns is used with configuring, but may explicitly be excluded with the --without-pyldnsx option to configure. * bugfix #410: Fix clearing out temporary data on stack in sha2.c * bugfix #411: Don't let empty non-terminal NSEC3s cause assertion failure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOhIaTAAoJEOX4+CEvd6SYXjcQAJMuBZCmNxco30NXh2sS6f3L F6s45imE6X8va5PXIIkQoTJjErhx9POMWPCuKJe+aBDrcZ0m3/Bveyo43zCeLEKE YKWZaTmb2cL14uAzr1KAMDtNiL6lHmzryTEErBtxb9uY6Vfcv17nBFBQLp62zIZ/ wOzTFjYUTUHZA7Ub/dUApRR1WHHbZeIVP9zRN7cnnTsgjwm80NMs5dGoZTpTeGLb DjZae3/+UMyuwCeFUR9qdqoLBNS7SuRZ2M1U7NAB6dsyly21MS/P+uWF1wgWcvhX uVWgb9x8O1gjEeT2kMpsIozW05aNnEDrdLxgExFaoWTOLqGfXFq1+5uEsOgVXBxY tbjV6f104E5SJ1aRSenxcc2vEq4QnYKJYjZLCO3dzw6YYZL4fx9vlhf8YBvRzyuc gdBWNLvQWbfxWZrIvd5ZEkA5ubdBcorecFBuOQrbiDxvbf+2JFR7XY67D1p2N2Vg eNxKPz5TN8aqnNgLc+MTsbajnLk3tSnf5kASzvbuHiFpDP0HsHenIKB6FuyCdmKP 0T1HCZi70RbdhBgGu83M1HJRmfTkReS1jX2poRv065gzaBXPrK1wNQ+HM6iPHN9f yvI5DOX5bTQCp5YnZJAiERhDm3kMzM9+5AwXiVi8eQ7XyNvPr/EATL+Fjfv4tbt2 rS2UVVmJkl0PZ2YDuTaH =L2NH -----END PGP SIGNATURE-----