From patrakov at gmail.com Fri Apr 2 09:01:53 2010 From: patrakov at gmail.com (Alexander E. Patrakov) Date: Fri, 02 Apr 2010 15:01:53 +0600 Subject: [ldns-users] Strange comment Message-ID: <1270198913.4191.34.camel@patrakov-desktop> Hello, I am trying to use ldns-1.6.4. However, I have a little problem with documentation. In ldns/rbtree.h line 46, just before the definition of ldns_rbnode_t, there is a comment: /** * This structure must be the first member of the data structure in * the rbtree. This allows easy casting between an rbnode_t and the * user data (poor man's inheritance). */ I.e. it seems to imply that one must put user data just after ldns_rbnode_t in memory, and nowhere else (in other words, pass a pointer to not_only_rbnode_t to ldns_rbtree_insert()). However, there is also a data pointer in ldns_rbnode_t, and if one follows the existing practice established in dnssec_zone.c, he puts the user data into the allocates memory there and inserts pointers to plain ldns_rbnode_t to the tree. Am I right that I am in fact free to choose any of the two above strategies for placing the user data, and that both are supported? Which one is preferred under which conditions? -- Alexander E. Patrakov From patrakov at gmail.com Mon Apr 5 11:03:58 2010 From: patrakov at gmail.com (Alexander E. Patrakov) Date: Mon, 05 Apr 2010 17:03:58 +0600 Subject: [ldns-users] malloc error handling Message-ID: <1270465438.1888.17.camel@patrakov-desktop> Hello. In general, ldns tries to check the return value of malloc. However, sometimes such checks are forgotten. E.g., in this piece of code, a failure of ldns_rdf_new() will lead to the leak of rdf_data: ldns_native2rdf_int32(ldns_rdf_type type, uint32_t value) { uint32_t *rdf_data = LDNS_XMALLOC(uint32_t, 1); if (!rdf_data) { return NULL; } ldns_write_uint32(rdf_data, value); return ldns_rdf_new(type, LDNS_RDF_SIZE_DOUBLEWORD, rdf_data); } Is this a bug? -- Alexander E. Patrakov From zbynek.michl at nic.cz Mon Apr 12 19:07:54 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 12 Apr 2010 21:07:54 +0200 Subject: [ldns-users] ldns_verify() sometimes returnes bad value Message-ID: <4BC36F8A.7080703@nic.cz> Hi there, there is probably a bug in ldns_verify() or in its subfunction. Here is a brief code sample: --- CODE --- p = ldns_resolver_query(res, ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, "www.rhybar.cz"), LDNS_RR_TYPE_A, LDNS_RR_CLASS_IN, LDNS_RD); p2 = ldns_resolver_query(res, ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, "www.rhybar.cz"), LDNS_RR_TYPE_RRSIG, LDNS_RR_CLASS_IN, LDNS_RD); p3 = ldns_resolver_query(res, ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, "rhybar.cz"), LDNS_RR_TYPE_DNSKEY, LDNS_RR_CLASS_IN, LDNS_RD); if (!p || !p2 || !p3) { exit(EXIT_FAILURE); } else { a = ldns_pkt_rr_list_by_type(p, LDNS_RR_TYPE_A, LDNS_SECTION_ANSWER); rrsig = ldns_pkt_rr_list_by_type(p2, LDNS_RR_TYPE_RRSIG, LDNS_SECTION_ANSWER); dnskey = ldns_pkt_rr_list_by_type(p3, LDNS_RR_TYPE_DNSKEY, LDNS_SECTION_ANSWER); if (!a || !rrsig || !dnskey) { exit(EXIT_FAILURE); } else { ldns_rr_list_print(stdout, a); ldns_rr_list_print(stdout, rrsig); ldns_rr_list_print(stdout, dnskey); s = ldns_verify(a, rrsig, dnskey, goodkey); printf("ldns_verify() result: %s\n", ldns_get_errorstr_by_id(s)); } } --- /CODE --- Here are an different outputs when using non-validating resolver: --- OUTPUT1 --- www.rhybar.cz. 248 IN A 217.31.205.50 www.rhybar.cz. 248 IN RRSIG A 5 3 600 20081030080058 20080930080058 5172 rhybar.cz. XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw79jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2FtwNOc= ;{id = 5172} rhybar.cz. 248 IN DNSKEY 256 3 5 AwEAAcrTMVXwOcFCGKtXwdt4XATP43qU96IryyqiZ0oPtuHEEBCikuQDuJhRjNAV4DYvR6fb/suAnd91EVNgHHTXUlAWwmJRrqIwZ6VuGaZqVG+NJh1Okif7CL8no2Z47j6I3HH3pyzrYH2oQVyr64O/8BV2jrk8RteeEqa7V7gcrFfJ ;{id = 5172 (zsk), size = 1024b} rhybar.cz. 248 IN DNSKEY 257 3 5 AwEAAeKle4K3bxJb4k9sMhdm6BmpRK2rISAGh0egMSXgOlQnU+3TLQ0aH1th7ejZnn6Zdkeo8MRXDxLkgp1rUSsRM1Q2SmLJhaat7L15qHmj+vCk5IuSIpAdaRsqOKxHlT6a/LWGwGvDIVxY6J9sXaJ4SInflZpa5wZUCrhDKvpo0hAzNfoK/aFApzZGaAGALYx6YpbG+SBW2K+s92eyoJCCrQQ+Nata41l7K6RFAYjP+g3Kp95McNm3xlBve171u9FUZNUuN2Rn25oEtHHlK9NcHNqWvFJ3VmXcA6CkGrBPV6vOAwwUtPDSWSZbdolS69092ZWYTlOJw6g0LVI2feMMrok= ;{id = 44566 (ksk), size = 2048b} rhybar.cz. 248 IN DNSKEY 256 3 5 AwEAAb/riVUjNfP1to3wkJyul0MjwiPojFgFmMiLj1KIKeVIYCIRNx01Q1we5M17GQFInCXXyTyjCYJfwkL0Xe7ma6m2pHfEMkOiDl42rsgrmkShxPEvZMd5vpT+RyQWQh26TJ42MRoCJSt6XNeFLXRyjfRcDt7ZxYD3bHNeyaDuUUGt ;{id = 34392 (zsk), size = 1024b} ldns_verify() result: Bogus DNSSEC signature --- /OUTPUT1 --- --- OUTPUT2 --- www.rhybar.cz. 321 IN A 217.31.205.50 www.rhybar.cz. 321 IN RRSIG A 5 3 600 20081030080058 20080930080058 5172 rhybar.cz. XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw79jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2FtwNOc= ;{id = 5172} rhybar.cz. 321 IN DNSKEY 257 3 5 AwEAAeKle4K3bxJb4k9sMhdm6BmpRK2rISAGh0egMSXgOlQnU+3TLQ0aH1th7ejZnn6Zdkeo8MRXDxLkgp1rUSsRM1Q2SmLJhaat7L15qHmj+vCk5IuSIpAdaRsqOKxHlT6a/LWGwGvDIVxY6J9sXaJ4SInflZpa5wZUCrhDKvpo0hAzNfoK/aFApzZGaAGALYx6YpbG+SBW2K+s92eyoJCCrQQ+Nata41l7K6RFAYjP+g3Kp95McNm3xlBve171u9FUZNUuN2Rn25oEtHHlK9NcHNqWvFJ3VmXcA6CkGrBPV6vOAwwUtPDSWSZbdolS69092ZWYTlOJw6g0LVI2feMMrok= ;{id = 44566 (ksk), size = 2048b} rhybar.cz. 321 IN DNSKEY 256 3 5 AwEAAb/riVUjNfP1to3wkJyul0MjwiPojFgFmMiLj1KIKeVIYCIRNx01Q1we5M17GQFInCXXyTyjCYJfwkL0Xe7ma6m2pHfEMkOiDl42rsgrmkShxPEvZMd5vpT+RyQWQh26TJ42MRoCJSt6XNeFLXRyjfRcDt7ZxYD3bHNeyaDuUUGt ;{id = 34392 (zsk), size = 1024b} rhybar.cz. 321 IN DNSKEY 256 3 5 AwEAAcrTMVXwOcFCGKtXwdt4XATP43qU96IryyqiZ0oPtuHEEBCikuQDuJhRjNAV4DYvR6fb/suAnd91EVNgHHTXUlAWwmJRrqIwZ6VuGaZqVG+NJh1Okif7CL8no2Z47j6I3HH3pyzrYH2oQVyr64O/8BV2jrk8RteeEqa7V7gcrFfJ ;{id = 5172 (zsk), size = 1024b} ldns_verify() result: No keys with the keytag and algorithm from the RRSIG found --- /OUTPUT2 --- It seems if the zsk is on the first place in dnskey list, ldns_verify() finds it correctly (domain name www.rhybar.cz really has bogus signature), but if the zsk is on the another place, ldns_verify() gets into a trouble with finding that key. Cheers, Zbynek From matthijs at NLnetLabs.nl Tue Apr 13 08:15:07 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 13 Apr 2010 10:15:07 +0200 Subject: [ldns-users] ldns_verify() sometimes returnes bad value In-Reply-To: <4BC36F8A.7080703@nic.cz> References: <4BC36F8A.7080703@nic.cz> Message-ID: <4BC4280B.90901@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek Michl, I believe what happens in the first case is: - - ldns sees a bogus signature. It will mark this as the resulting return value. - - The other keys will not update the resulting return value, unless the key verifies the signature. In the second case: - - ldns sees a key that does not match the signature. It will mark the resulting return value as not matching. - - The other keys will not update the resulting return value, unless the key verifies the signature. So, the first encountered error is remembered. I think we should update the return value if: - - No matching key was found prior to this key. - - This key verifies the signature. I have updated the trunk. Could you try r3227 and see if this works for you? Best regards, Matthijs Zbynek Michl wrote: > Hi there, > > there is probably a bug in ldns_verify() or in its subfunction. Here is > a brief code sample: > > --- CODE --- > p = ldns_resolver_query(res, > ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, > "www.rhybar.cz"), > LDNS_RR_TYPE_A, > LDNS_RR_CLASS_IN, > LDNS_RD); > p2 = ldns_resolver_query(res, > ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, > "www.rhybar.cz"), > LDNS_RR_TYPE_RRSIG, > LDNS_RR_CLASS_IN, > LDNS_RD); > p3 = ldns_resolver_query(res, > ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, > "rhybar.cz"), > LDNS_RR_TYPE_DNSKEY, > LDNS_RR_CLASS_IN, > LDNS_RD); > if (!p || !p2 || !p3) { > exit(EXIT_FAILURE); > } else { > a = ldns_pkt_rr_list_by_type(p, > LDNS_RR_TYPE_A, > LDNS_SECTION_ANSWER); > rrsig = ldns_pkt_rr_list_by_type(p2, > LDNS_RR_TYPE_RRSIG, > LDNS_SECTION_ANSWER); > dnskey = ldns_pkt_rr_list_by_type(p3, > LDNS_RR_TYPE_DNSKEY, > LDNS_SECTION_ANSWER); > if (!a || !rrsig || !dnskey) { > exit(EXIT_FAILURE); > } else { > ldns_rr_list_print(stdout, a); > ldns_rr_list_print(stdout, rrsig); > ldns_rr_list_print(stdout, dnskey); > s = ldns_verify(a, rrsig, dnskey, goodkey); > printf("ldns_verify() result: %s\n", ldns_get_errorstr_by_id(s)); > } > } > --- /CODE --- > > > Here are an different outputs when using non-validating resolver: > > --- OUTPUT1 --- > www.rhybar.cz. 248 IN A 217.31.205.50 > www.rhybar.cz. 248 IN RRSIG A 5 3 600 20081030080058 > 20080930080058 5172 rhybar.cz. > XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw79jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2FtwNOc= > ;{id = 5172} > rhybar.cz. 248 IN DNSKEY 256 3 5 > AwEAAcrTMVXwOcFCGKtXwdt4XATP43qU96IryyqiZ0oPtuHEEBCikuQDuJhRjNAV4DYvR6fb/suAnd91EVNgHHTXUlAWwmJRrqIwZ6VuGaZqVG+NJh1Okif7CL8no2Z47j6I3HH3pyzrYH2oQVyr64O/8BV2jrk8RteeEqa7V7gcrFfJ > ;{id = 5172 (zsk), size = 1024b} > rhybar.cz. 248 IN DNSKEY 257 3 5 > AwEAAeKle4K3bxJb4k9sMhdm6BmpRK2rISAGh0egMSXgOlQnU+3TLQ0aH1th7ejZnn6Zdkeo8MRXDxLkgp1rUSsRM1Q2SmLJhaat7L15qHmj+vCk5IuSIpAdaRsqOKxHlT6a/LWGwGvDIVxY6J9sXaJ4SInflZpa5wZUCrhDKvpo0hAzNfoK/aFApzZGaAGALYx6YpbG+SBW2K+s92eyoJCCrQQ+Nata41l7K6RFAYjP+g3Kp95McNm3xlBve171u9FUZNUuN2Rn25oEtHHlK9NcHNqWvFJ3VmXcA6CkGrBPV6vOAwwUtPDSWSZbdolS69092ZWYTlOJw6g0LVI2feMMrok= > ;{id = 44566 (ksk), size = 2048b} > rhybar.cz. 248 IN DNSKEY 256 3 5 > AwEAAb/riVUjNfP1to3wkJyul0MjwiPojFgFmMiLj1KIKeVIYCIRNx01Q1we5M17GQFInCXXyTyjCYJfwkL0Xe7ma6m2pHfEMkOiDl42rsgrmkShxPEvZMd5vpT+RyQWQh26TJ42MRoCJSt6XNeFLXRyjfRcDt7ZxYD3bHNeyaDuUUGt > ;{id = 34392 (zsk), size = 1024b} > ldns_verify() result: Bogus DNSSEC signature > --- /OUTPUT1 --- > > --- OUTPUT2 --- > www.rhybar.cz. 321 IN A 217.31.205.50 > www.rhybar.cz. 321 IN RRSIG A 5 3 600 20081030080058 > 20080930080058 5172 rhybar.cz. > XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw79jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2FtwNOc= > ;{id = 5172} > rhybar.cz. 321 IN DNSKEY 257 3 5 > AwEAAeKle4K3bxJb4k9sMhdm6BmpRK2rISAGh0egMSXgOlQnU+3TLQ0aH1th7ejZnn6Zdkeo8MRXDxLkgp1rUSsRM1Q2SmLJhaat7L15qHmj+vCk5IuSIpAdaRsqOKxHlT6a/LWGwGvDIVxY6J9sXaJ4SInflZpa5wZUCrhDKvpo0hAzNfoK/aFApzZGaAGALYx6YpbG+SBW2K+s92eyoJCCrQQ+Nata41l7K6RFAYjP+g3Kp95McNm3xlBve171u9FUZNUuN2Rn25oEtHHlK9NcHNqWvFJ3VmXcA6CkGrBPV6vOAwwUtPDSWSZbdolS69092ZWYTlOJw6g0LVI2feMMrok= > ;{id = 44566 (ksk), size = 2048b} > rhybar.cz. 321 IN DNSKEY 256 3 5 > AwEAAb/riVUjNfP1to3wkJyul0MjwiPojFgFmMiLj1KIKeVIYCIRNx01Q1we5M17GQFInCXXyTyjCYJfwkL0Xe7ma6m2pHfEMkOiDl42rsgrmkShxPEvZMd5vpT+RyQWQh26TJ42MRoCJSt6XNeFLXRyjfRcDt7ZxYD3bHNeyaDuUUGt > ;{id = 34392 (zsk), size = 1024b} > rhybar.cz. 321 IN DNSKEY 256 3 5 > AwEAAcrTMVXwOcFCGKtXwdt4XATP43qU96IryyqiZ0oPtuHEEBCikuQDuJhRjNAV4DYvR6fb/suAnd91EVNgHHTXUlAWwmJRrqIwZ6VuGaZqVG+NJh1Okif7CL8no2Z47j6I3HH3pyzrYH2oQVyr64O/8BV2jrk8RteeEqa7V7gcrFfJ > ;{id = 5172 (zsk), size = 1024b} > ldns_verify() result: No keys with the keytag and algorithm from the > RRSIG found > --- /OUTPUT2 --- > > It seems if the zsk is on the first place in dnskey list, ldns_verify() > finds it correctly (domain name www.rhybar.cz really has bogus > signature), but if the zsk is on the another place, ldns_verify() gets > into a trouble with finding that key. > > > Cheers, > Zbynek > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLxCgEAAoJEA8yVCPsQCW5tdIIAN0h+UgmARtRWaOtin2UI+yy O0ckA36vdb2VZS2hd0QamELfF0jcUoAMAoTiScXVfyVtiWmTwv52Xj2MDgBPAFWo OFv//gLn9YlEhDCsk1xQ/WrTe/jLsWFiZhCrIiGqKHrAEbijX2nKUnY0LvqZ+lWO kIBBwSIfw47W41Em1Ru9+mf/MezueD/KFRaFzhZPeAuaxqNApd8N5p65RXEIcGn3 sROXeaZRpbmiGWntX3k4vKgvd7haZA7mFtuHHy4R3q8lFciavo3w/WcAwH8qmh4b PTKb/2PHoiZqEjDwNOibc8x8+L0ZgIjyO6Z1oAyc0NGzLsuMs83X9ErhQGXkJN0= =m7CD -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Tue Apr 13 11:44:25 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Tue, 13 Apr 2010 13:44:25 +0200 Subject: [ldns-users] ldns_verify() sometimes returnes bad value In-Reply-To: <4BC4280B.90901@nlnetlabs.nl> References: <4BC36F8A.7080703@nic.cz> <4BC4280B.90901@nlnetlabs.nl> Message-ID: <4BC45919.7060209@nic.cz> Hi Matthijs, it works fine with r3227. Thanks for your prompt fix! :) Regards, Zbynek On 13.4.2010 10:15, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Zbynek Michl, > > I believe what happens in the first case is: > - - ldns sees a bogus signature. It will mark this as the resulting return > value. > - - The other keys will not update the resulting return value, unless the > key verifies the signature. > > In the second case: > - - ldns sees a key that does not match the signature. It will mark the > resulting return value as not matching. > - - The other keys will not update the resulting return value, unless the > key verifies the signature. > > So, the first encountered error is remembered. I think we should update > the return value if: > - - No matching key was found prior to this key. > - - This key verifies the signature. > > I have updated the trunk. Could you try r3227 and see if this works for you? > > > Best regards, > > Matthijs > > > Zbynek Michl wrote: >> Hi there, >> >> there is probably a bug in ldns_verify() or in its subfunction. Here is >> a brief code sample: >> >> --- CODE --- >> p = ldns_resolver_query(res, >> ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, >> "www.rhybar.cz"), >> LDNS_RR_TYPE_A, >> LDNS_RR_CLASS_IN, >> LDNS_RD); >> p2 = ldns_resolver_query(res, >> ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, >> "www.rhybar.cz"), >> LDNS_RR_TYPE_RRSIG, >> LDNS_RR_CLASS_IN, >> LDNS_RD); >> p3 = ldns_resolver_query(res, >> ldns_rdf_new_frm_str(LDNS_RDF_TYPE_DNAME, >> "rhybar.cz"), >> LDNS_RR_TYPE_DNSKEY, >> LDNS_RR_CLASS_IN, >> LDNS_RD); >> if (!p || !p2 || !p3) { >> exit(EXIT_FAILURE); >> } else { >> a = ldns_pkt_rr_list_by_type(p, >> LDNS_RR_TYPE_A, >> LDNS_SECTION_ANSWER); >> rrsig = ldns_pkt_rr_list_by_type(p2, >> LDNS_RR_TYPE_RRSIG, >> LDNS_SECTION_ANSWER); >> dnskey = ldns_pkt_rr_list_by_type(p3, >> LDNS_RR_TYPE_DNSKEY, >> LDNS_SECTION_ANSWER); >> if (!a || !rrsig || !dnskey) { >> exit(EXIT_FAILURE); >> } else { >> ldns_rr_list_print(stdout, a); >> ldns_rr_list_print(stdout, rrsig); >> ldns_rr_list_print(stdout, dnskey); >> s = ldns_verify(a, rrsig, dnskey, goodkey); >> printf("ldns_verify() result: %s\n", ldns_get_errorstr_by_id(s)); >> } >> } >> --- /CODE --- >> >> >> Here are an different outputs when using non-validating resolver: >> >> --- OUTPUT1 --- >> www.rhybar.cz. 248 IN A 217.31.205.50 >> www.rhybar.cz. 248 IN RRSIG A 5 3 600 20081030080058 >> 20080930080058 5172 rhybar.cz. >> XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw79jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2FtwNOc= >> ;{id = 5172} >> rhybar.cz. 248 IN DNSKEY 256 3 5 >> AwEAAcrTMVXwOcFCGKtXwdt4XATP43qU96IryyqiZ0oPtuHEEBCikuQDuJhRjNAV4DYvR6fb/suAnd91EVNgHHTXUlAWwmJRrqIwZ6VuGaZqVG+NJh1Okif7CL8no2Z47j6I3HH3pyzrYH2oQVyr64O/8BV2jrk8RteeEqa7V7gcrFfJ >> ;{id = 5172 (zsk), size = 1024b} >> rhybar.cz. 248 IN DNSKEY 257 3 5 >> AwEAAeKle4K3bxJb4k9sMhdm6BmpRK2rISAGh0egMSXgOlQnU+3TLQ0aH1th7ejZnn6Zdkeo8MRXDxLkgp1rUSsRM1Q2SmLJhaat7L15qHmj+vCk5IuSIpAdaRsqOKxHlT6a/LWGwGvDIVxY6J9sXaJ4SInflZpa5wZUCrhDKvpo0hAzNfoK/aFApzZGaAGALYx6YpbG+SBW2K+s92eyoJCCrQQ+Nata41l7K6RFAYjP+g3Kp95McNm3xlBve171u9FUZNUuN2Rn25oEtHHlK9NcHNqWvFJ3VmXcA6CkGrBPV6vOAwwUtPDSWSZbdolS69092ZWYTlOJw6g0LVI2feMMrok= >> ;{id = 44566 (ksk), size = 2048b} >> rhybar.cz. 248 IN DNSKEY 256 3 5 >> AwEAAb/riVUjNfP1to3wkJyul0MjwiPojFgFmMiLj1KIKeVIYCIRNx01Q1we5M17GQFInCXXyTyjCYJfwkL0Xe7ma6m2pHfEMkOiDl42rsgrmkShxPEvZMd5vpT+RyQWQh26TJ42MRoCJSt6XNeFLXRyjfRcDt7ZxYD3bHNeyaDuUUGt >> ;{id = 34392 (zsk), size = 1024b} >> ldns_verify() result: Bogus DNSSEC signature >> --- /OUTPUT1 --- >> >> --- OUTPUT2 --- >> www.rhybar.cz. 321 IN A 217.31.205.50 >> www.rhybar.cz. 321 IN RRSIG A 5 3 600 20081030080058 >> 20080930080058 5172 rhybar.cz. >> XVkut4l9mw2MhodZFIOD2L57AU2u+I6wGVlK1fr6w5locFC5NIe8ukw79jYdOCH3WwFgSMscumIz1sGqRPrN/CrhXiU0ymFGFju9x/k10lv6SGS6lslgnZluet04CyibGQ2HBnwTx7qK3j+bNzxKLvjpn7DY9f+YKB8F2FtwNOc= >> ;{id = 5172} >> rhybar.cz. 321 IN DNSKEY 257 3 5 >> AwEAAeKle4K3bxJb4k9sMhdm6BmpRK2rISAGh0egMSXgOlQnU+3TLQ0aH1th7ejZnn6Zdkeo8MRXDxLkgp1rUSsRM1Q2SmLJhaat7L15qHmj+vCk5IuSIpAdaRsqOKxHlT6a/LWGwGvDIVxY6J9sXaJ4SInflZpa5wZUCrhDKvpo0hAzNfoK/aFApzZGaAGALYx6YpbG+SBW2K+s92eyoJCCrQQ+Nata41l7K6RFAYjP+g3Kp95McNm3xlBve171u9FUZNUuN2Rn25oEtHHlK9NcHNqWvFJ3VmXcA6CkGrBPV6vOAwwUtPDSWSZbdolS69092ZWYTlOJw6g0LVI2feMMrok= >> ;{id = 44566 (ksk), size = 2048b} >> rhybar.cz. 321 IN DNSKEY 256 3 5 >> AwEAAb/riVUjNfP1to3wkJyul0MjwiPojFgFmMiLj1KIKeVIYCIRNx01Q1we5M17GQFInCXXyTyjCYJfwkL0Xe7ma6m2pHfEMkOiDl42rsgrmkShxPEvZMd5vpT+RyQWQh26TJ42MRoCJSt6XNeFLXRyjfRcDt7ZxYD3bHNeyaDuUUGt >> ;{id = 34392 (zsk), size = 1024b} >> rhybar.cz. 321 IN DNSKEY 256 3 5 >> AwEAAcrTMVXwOcFCGKtXwdt4XATP43qU96IryyqiZ0oPtuHEEBCikuQDuJhRjNAV4DYvR6fb/suAnd91EVNgHHTXUlAWwmJRrqIwZ6VuGaZqVG+NJh1Okif7CL8no2Z47j6I3HH3pyzrYH2oQVyr64O/8BV2jrk8RteeEqa7V7gcrFfJ >> ;{id = 5172 (zsk), size = 1024b} >> ldns_verify() result: No keys with the keytag and algorithm from the >> RRSIG found >> --- /OUTPUT2 --- >> >> It seems if the zsk is on the first place in dnskey list, ldns_verify() >> finds it correctly (domain name www.rhybar.cz really has bogus >> signature), but if the zsk is on the another place, ldns_verify() gets >> into a trouble with finding that key. >> >> >> Cheers, >> Zbynek >> _______________________________________________ >> 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.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEcBAEBAgAGBQJLxCgEAAoJEA8yVCPsQCW5tdIIAN0h+UgmARtRWaOtin2UI+yy > O0ckA36vdb2VZS2hd0QamELfF0jcUoAMAoTiScXVfyVtiWmTwv52Xj2MDgBPAFWo > OFv//gLn9YlEhDCsk1xQ/WrTe/jLsWFiZhCrIiGqKHrAEbijX2nKUnY0LvqZ+lWO > kIBBwSIfw47W41Em1Ru9+mf/MezueD/KFRaFzhZPeAuaxqNApd8N5p65RXEIcGn3 > sROXeaZRpbmiGWntX3k4vKgvd7haZA7mFtuHHy4R3q8lFciavo3w/WcAwH8qmh4b > PTKb/2PHoiZqEjDwNOibc8x8+L0ZgIjyO6Z1oAyc0NGzLsuMs83X9ErhQGXkJN0= > =m7CD > -----END PGP SIGNATURE----- From msheldon at godaddy.com Thu Apr 15 17:01:38 2010 From: msheldon at godaddy.com (Michael Sheldon) Date: Thu, 15 Apr 2010 10:01:38 -0700 Subject: [ldns-users] =?utf-8?q?Issue_with_ldns=5Fresolver=5Fdeep=5Ffree_a?= =?utf-8?q?nd_TSIG?= Message-ID: <20100415100138.205a61dff9fc1684c258b274662bb912.b2a06b8106.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: From wouter at NLnetLabs.nl Fri Apr 16 12:48:17 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Fri, 16 Apr 2010 14:48:17 +0200 Subject: [ldns-users] Issue with ldns_resolver_deep_free and TSIG In-Reply-To: <20100415100138.205a61dff9fc1684c258b274662bb912.b2a06b8106.wbe@email.secureserver.net> References: <20100415100138.205a61dff9fc1684c258b274662bb912.b2a06b8106.wbe@email.secureserver.net> Message-ID: <4BC85C91.6020204@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, Yes this is wrong. I guess the least-surprising solution is to copy the strings and delete them, for all three values. Best regards, Wouter On 04/15/2010 07:01 PM, Michael Sheldon wrote: > When assigning TSIG parameters to ldns_resolver using > ldns_resolver_tsig_keyname, ldns_resolver_tsig_algorithm and > ldns_resolver_tsig_keydata, those functions merely set the pointer to > the pointer value passed, they do not actually copy the data. However, > when ldns_resolver_deep_free is called, it attempts to free > res->_tsig_keyname. > > First, ldns_resolver_deep_free probably should not attempt to free > these, unless the set functions are modified to make copies instead of > just storing the pointer. > > Second, and possibly more significant, ldns_resolver_deep_free is > inconsistent in that it only attempts to free one of the three values, > but not the others. For someone who *does* expect the values to be > freed, this would result in a memory leak. > > Michael Sheldon > > > > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIXJEACgkQkDLqNwOhpPi6RQCfSMYr9kS8Gkwr9XX04YVKh2Wy BvQAn0tLknzXNsy43oihyLs69/Gd1mGx =wdWJ -----END PGP SIGNATURE----- From msheldon at godaddy.com Fri Apr 16 17:46:54 2010 From: msheldon at godaddy.com (Michael Sheldon) Date: Fri, 16 Apr 2010 10:46:54 -0700 Subject: [ldns-users] =?utf-8?q?Issue_with_ldns=5Fresolver=5Fdeep=5Ffree_a?= =?utf-8?q?nd_TSIG?= Message-ID: <20100416104654.205a61dff9fc1684c258b274662bb912.ad08bb0612.wbe@email.secureserver.net> Another bit of a surprise... Normally, when pushing objects to a container, like an rr to an rrlist, the _push function pushes the pointer to the object, which means that it will later be cleaned up with a deep_free However, when pushing a nameserver rdf to a resolver, it clones it, thus requiring that the original rdf object be separately free'd. This is inconsistent with most other ldns container objects like rr_list, zone, etc. I guess generally I expect simple "primitives" being _set to be cloned (strings, etc) but objects passed to _push to be pushed as pointers. Michael Sheldon -------- Original Message -------- Subject: Re: [ldns-users] Issue with ldns_resolver_deep_free and TSIG From: "W.C.A. Wijngaards" Date: Fri, April 16, 2010 5:48 am To: ldns-users at open.nlnetlabs.nl -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, Yes this is wrong. I guess the least-surprising solution is to copy the strings and delete them, for all three values. Best regards, Wouter On 04/15/2010 07:01 PM, Michael Sheldon wrote: > When assigning TSIG parameters to ldns_resolver using > ldns_resolver_tsig_keyname, ldns_resolver_tsig_algorithm and > ldns_resolver_tsig_keydata, those functions merely set the pointer to > the pointer value passed, they do not actually copy the data. However, > when ldns_resolver_deep_free is called, it attempts to free > res->_tsig_keyname. > > First, ldns_resolver_deep_free probably should not attempt to free > these, unless the set functions are modified to make copies instead of > just storing the pointer. > > Second, and possibly more significant, ldns_resolver_deep_free is > inconsistent in that it only attempts to free one of the three values, > but not the others. For someone who *does* expect the values to be > freed, this would result in a memory leak. > > Michael Sheldon > > > > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIXJEACgkQkDLqNwOhpPi6RQCfSMYr9kS8Gkwr9XX04YVKh2Wy BvQAn0tLknzXNsy43oihyLs69/Gd1mGx =wdWJ -----END PGP SIGNATURE----- _______________________________________________ ldns-users mailing list ldns-users at open.nlnetlabs.nl http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From zbynek.michl at nic.cz Mon Apr 19 12:30:35 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 19 Apr 2010 14:30:35 +0200 Subject: [ldns-users] ldns_resolver_new_frm_fp_l() comment lines bug In-Reply-To: <4BA2495B.7090507@nlnetlabs.nl> References: <4BA22D0F.5090107@nic.cz> <4BA2495B.7090507@nlnetlabs.nl> Message-ID: <4BCC4CEB.9020205@nic.cz> Hi Wouter, there is probably another bug in ldns_resolver_new_frm_fp_l(). Function can not read "search" list from resolv.conf. Thanks, Zbynek On 18.3.2010 16:40, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Zbynek, > > Fixed in svn r 3210 > > The example you gave did not fail for me? It failed with different > whitespace. But anyway, the comment handling did not properly handle > skipping onto the next line, so I fixed that :-) > > Thanks for the report! > Wouter > > On 03/18/2010 02:39 PM, Zbynek Michl wrote: >> there is probably a bug in ldns_resolver_new_frm_fp_l() function. When I >> use ldns_resolver_new_frm_file() to read /etc/resolv.conf, it >> incorrectly handles comment lines. >> >> So it seems if some line is commented out, then the next line is ommited >> too. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuiSVsACgkQkDLqNwOhpPiHrgCeKKQ1fV5Oa3m2JC1XCEiSGJmW > r0IAnAxa2XF4C5PUzj76+qdK3v22Y746 > =xDkF > -----END PGP SIGNATURE----- > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From zbynek.michl at nic.cz Mon Apr 19 12:51:10 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 19 Apr 2010 14:51:10 +0200 Subject: [ldns-users] _recursive and _igntc flags in ldns_struct_resolver Message-ID: <4BCC51BE.9070208@nic.cz> Hi there, what are these flags good for? I guess that they are not in use, however ldns_resolver_print() function prints their uninitialized values. So will not be better to remove them from ldns_resolver_print() or initialize them by ldns_resolver_new()? Thanks, Zbynek From zbynek.michl at nic.cz Mon Apr 19 14:15:19 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 19 Apr 2010 16:15:19 +0200 Subject: [ldns-users] _recursive and _igntc flags in ldns_struct_resolver In-Reply-To: <4BCC51BE.9070208@nic.cz> References: <4BCC51BE.9070208@nic.cz> Message-ID: <4BCC6577.607@nic.cz> ...and I will be lucky if ldns_resolver_print() will also print _fallback, _dnssec and _dnssec_cd flags :) Thanks again, Zbynek On 19.4.2010 14:51, Zbynek Michl wrote: > Hi there, > > what are these flags good for? I guess that they are not in use, however > ldns_resolver_print() function prints their uninitialized values. So > will not be better to remove them from ldns_resolver_print() or > initialize them by ldns_resolver_new()? > > Thanks, > Zbynek From zbynek.michl at nic.cz Mon Apr 19 16:58:37 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 19 Apr 2010 18:58:37 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? Message-ID: <4BCC8BBD.8070902@nic.cz> Hello, I am trying to use search list, but unsuccessfully. Here is an sample: --- CODE --- ldns_rdf *domain = ldns_dname_new_frm_str("myhostname"); ldns_rdf *search = ldns_dname_new_frm_str("mydomain.cz"); ldns_resolver_push_searchlist(res, search); p = ldns_resolver_search(res, domain, LDNS_RR_TYPE_A, LDNS_RR_CLASS_IN, LDNS_RD); --- /CODE --- The problem is that "myhostname.mydomain.cz" will never be tried, because of ldns_dname_new_frm_str() adds "." to the end of "myhostname" and therefore ldns_resolver_search() will not concatenate "mydomain.cz". So how can I create "myhostname" RDF without trailing "."? Or any other suggestion? Cheers, Zbynek From matthijs at NLnetLabs.nl Wed Apr 21 08:47:49 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 21 Apr 2010 10:47:49 +0200 Subject: [ldns-users] ldns_resolver_new_frm_fp_l() comment lines bug In-Reply-To: <4BCC4CEB.9020205@nic.cz> References: <4BA22D0F.5090107@nic.cz> <4BA2495B.7090507@nlnetlabs.nl> <4BCC4CEB.9020205@nic.cz> Message-ID: <4BCEBBB5.3010308@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, What seems to be the error? It reads my resolv.conf (including search line) fine. Best regards, Matthijs Zbynek Michl wrote: > Hi Wouter, > > there is probably another bug in ldns_resolver_new_frm_fp_l(). Function > can not read "search" list from resolv.conf. > > Thanks, > Zbynek > > On 18.3.2010 16:40, W.C.A. Wijngaards wrote: > Hi Zbynek, > > Fixed in svn r 3210 > > The example you gave did not fail for me? It failed with different > whitespace. But anyway, the comment handling did not properly handle > skipping onto the next line, so I fixed that :-) > > Thanks for the report! > Wouter > > On 03/18/2010 02:39 PM, Zbynek Michl wrote: >>>> there is probably a bug in ldns_resolver_new_frm_fp_l() function. When I >>>> use ldns_resolver_new_frm_file() to read /etc/resolv.conf, it >>>> incorrectly handles comment lines. >>>> >>>> So it seems if some line is commented out, then the next line is ommited >>>> too. _______________________________________________ ldns-users mailing list ldns-users at open.nlnetlabs.nl http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLzruzAAoJEA8yVCPsQCW5OfwIAKAEknSe89OyHGV45upC850m IxaRQdxrIPZYCBwuf76p00/KnZAjAmsnhYUlUYydUadUTbAlLO9rI4seHJE5NnyC i5cFCfvYERzT3BVM9E2LoiiIiVLPbqHDFCgUi+qogH/Aq9UWxnpMCrSiF6UDLSyr TUks6TGZ8sy5IasbKvHdjIl7QZ8I8ch+DO/2ugl1lZAhVys6C5cc34BJEjFzORL+ vqBQG+JoTlGDbvXg0m99peIiyI9urhbxiUmul2zZ6IUweftbH/jkJWzO8q9/EJtS 0tmIR6V+c8Gh9rKQ1qzeQYCg3V3ycx14qRQreJll3x+YYRqAU2I18gpoCQ13/LI= =hlHb -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Wed Apr 21 10:00:55 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Wed, 21 Apr 2010 12:00:55 +0200 Subject: [ldns-users] ldns_resolver_new_frm_fp_l() comment lines bug In-Reply-To: <4BCEBBB5.3010308@nlnetlabs.nl> References: <4BA22D0F.5090107@nic.cz> <4BA2495B.7090507@nlnetlabs.nl> <4BCC4CEB.9020205@nic.cz> <4BCEBBB5.3010308@nlnetlabs.nl> Message-ID: <4BCECCD7.8000405@nic.cz> Hi Matthijs, I have got simple resolv.conf: nameserver 172.20.20.40 search mydomain.cz and using function ldns_resolver_new_frm_file(&res, NULL) I am getting empty _searchlist (nameserver is read correctly). So what could be wrong? Thanks, Zbynek On 21.4.2010 10:47, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Zbynek, > > What seems to be the error? It reads my resolv.conf (including search > line) fine. > > Best regards, > > Matthijs > > Zbynek Michl wrote: >> Hi Wouter, >> >> there is probably another bug in ldns_resolver_new_frm_fp_l(). Function >> can not read "search" list from resolv.conf. >> >> Thanks, >> Zbynek >> >> On 18.3.2010 16:40, W.C.A. Wijngaards wrote: >> Hi Zbynek, >> >> Fixed in svn r 3210 >> >> The example you gave did not fail for me? It failed with different >> whitespace. But anyway, the comment handling did not properly handle >> skipping onto the next line, so I fixed that :-) >> >> Thanks for the report! >> Wouter >> >> On 03/18/2010 02:39 PM, Zbynek Michl wrote: >>>>> there is probably a bug in ldns_resolver_new_frm_fp_l() function. When I >>>>> use ldns_resolver_new_frm_file() to read /etc/resolv.conf, it >>>>> incorrectly handles comment lines. >>>>> >>>>> So it seems if some line is commented out, then the next line is ommited >>>>> too. > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> _______________________________________________ >> 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.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEcBAEBAgAGBQJLzruzAAoJEA8yVCPsQCW5OfwIAKAEknSe89OyHGV45upC850m > IxaRQdxrIPZYCBwuf76p00/KnZAjAmsnhYUlUYydUadUTbAlLO9rI4seHJE5NnyC > i5cFCfvYERzT3BVM9E2LoiiIiVLPbqHDFCgUi+qogH/Aq9UWxnpMCrSiF6UDLSyr > TUks6TGZ8sy5IasbKvHdjIl7QZ8I8ch+DO/2ugl1lZAhVys6C5cc34BJEjFzORL+ > vqBQG+JoTlGDbvXg0m99peIiyI9urhbxiUmul2zZ6IUweftbH/jkJWzO8q9/EJtS > 0tmIR6V+c8Gh9rKQ1qzeQYCg3V3ycx14qRQreJll3x+YYRqAU2I18gpoCQ13/LI= > =hlHb > -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Wed Apr 21 11:34:22 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 21 Apr 2010 13:34:22 +0200 Subject: [ldns-users] ldns_resolver_new_frm_fp_l() comment lines bug In-Reply-To: <4BCECCD7.8000405@nic.cz> References: <4BA22D0F.5090107@nic.cz> <4BA2495B.7090507@nlnetlabs.nl> <4BCC4CEB.9020205@nic.cz> <4BCEBBB5.3010308@nlnetlabs.nl> <4BCECCD7.8000405@nic.cz> Message-ID: <4BCEE2BE.6040006@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah yes, you are right. The parsing goes wrong, we hit the limit too early and we don't allow for the word to be closed with the '\0' character. A fix is in trunk r3236. Thanks! Matthijs Zbynek Michl wrote: > Hi Matthijs, > > I have got simple resolv.conf: > > nameserver 172.20.20.40 > search mydomain.cz > > and using function ldns_resolver_new_frm_file(&res, NULL) I am getting > empty _searchlist (nameserver is read correctly). So what could be wrong? > > Thanks, > Zbynek > > On 21.4.2010 10:47, Matthijs Mekking wrote: > Hi Zbynek, > > What seems to be the error? It reads my resolv.conf (including search > line) fine. > > Best regards, > > Matthijs > > Zbynek Michl wrote: >>>> Hi Wouter, >>>> >>>> there is probably another bug in ldns_resolver_new_frm_fp_l(). Function >>>> can not read "search" list from resolv.conf. >>>> >>>> Thanks, >>>> Zbynek >>>> >>>> On 18.3.2010 16:40, W.C.A. Wijngaards wrote: >>>> Hi Zbynek, >>>> >>>> Fixed in svn r 3210 >>>> >>>> The example you gave did not fail for me? It failed with different >>>> whitespace. But anyway, the comment handling did not properly handle >>>> skipping onto the next line, so I fixed that :-) >>>> >>>> Thanks for the report! >>>> Wouter >>>> >>>> On 03/18/2010 02:39 PM, Zbynek Michl wrote: >>>>>>> there is probably a bug in ldns_resolver_new_frm_fp_l() function. >>>>>>> When I >>>>>>> use ldns_resolver_new_frm_file() to read /etc/resolv.conf, it >>>>>>> incorrectly handles comment lines. >>>>>>> >>>>>>> So it seems if some line is commented out, then the next line is >>>>>>> ommited >>>>>>> too. > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>> _______________________________________________ >>>> 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLzuK8AAoJEA8yVCPsQCW5/NcIALtpYDFyo3XbaO2ezkbqCvoj oUa1f9vLNiFHqKOFKInVerMwoRulNuQy7bomNVYmUACePbdjbW6u8WBJhDkD2JJc OaO3bKwU8uyulLqK06DDhpF9KGDbXpi8vTfbTJvypsAlj12zLZsXRWqPtY/pr+GQ Mj/g5dsm8mgL/rATtbaOe3vzElpubLRVstvmph6pNc9IqR7GdSrCaSNYTZ1LtM6k f+OZQXG3DFnX3qxkTTbnYHJYpKqnmhmnutPfDiYpJI17HG18v1yxnVYbkuj/dnok MIKwpPdK7BDxKmFUsmO27UNLls8ko/ecd+x35vq/n0vE4nGceZSNifXde+oX8Co= =0yqM -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Wed Apr 21 12:15:07 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 21 Apr 2010 14:15:07 +0200 Subject: [ldns-users] _recursive and _igntc flags in ldns_struct_resolver In-Reply-To: <4BCC6577.607@nic.cz> References: <4BCC51BE.9070208@nic.cz> <4BCC6577.607@nic.cz> Message-ID: <4BCEEC4B.50802@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, I have completed the list of defaults in ldns_resolver_new() and add more printouts in ldns_resolver_print(). Best regards, Matthijs Zbynek Michl wrote: > ...and I will be lucky if ldns_resolver_print() will also print > _fallback, _dnssec and _dnssec_cd flags :) > > Thanks again, > Zbynek > > On 19.4.2010 14:51, Zbynek Michl wrote: >> Hi there, >> >> what are these flags good for? I guess that they are not in use, however >> ldns_resolver_print() function prints their uninitialized values. So >> will not be better to remove them from ldns_resolver_print() or >> initialize them by ldns_resolver_new()? >> >> Thanks, >> Zbynek > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLzuxDAAoJEA8yVCPsQCW5w+sH/1Fd25Ytru8DpwSYwffhyLsQ Frn2JFC2ibOQ1/1BscG/DCWRSZUWcWAgTtp6LG6iQaGmLBUts2U7dzxeOUDAc2t2 Ny7/7ZALke5yu4gGZ8gBTamZ/AR1UH66n4tLEhPg7NUxsy/FeYsC8cm8NKeiT439 dox1axxKvDJW8BHuwdK/B7SS8Xv81ynnjozzTBrOfr/vc2TPq2Af0dF+nN9bCikm zzHQqYOiNeXBd9EIORys8LdM9bCFpa7cV+lzIRr7R05mnNqSUrPvC8jflVAr69HK LJiHEps4Gvzy+cauov+yZuo/fYb6xvT534gGmNmdUYpOKF8POP2ftGE+9ih83uI= =sjDM -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Wed Apr 21 13:53:30 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Wed, 21 Apr 2010 15:53:30 +0200 Subject: [ldns-users] _recursive and _igntc flags in ldns_struct_resolver In-Reply-To: <4BCEEC4B.50802@nlnetlabs.nl> References: <4BCC51BE.9070208@nic.cz> <4BCC6577.607@nic.cz> <4BCEEC4B.50802@nlnetlabs.nl> Message-ID: <4BCF035A.5010905@nic.cz> Thanks Matthijs, btw some items in ldns_resolver_print() are duplicated (e.g. ldns_resolver_ip6(), ldns_resolver_usevc(), ldns_resolver_igntc()). Regards, Zbynek On 21.4.2010 14:15, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Zbynek, > > I have completed the list of defaults in ldns_resolver_new() and add > more printouts in ldns_resolver_print(). > > Best regards, > > Matthijs > > Zbynek Michl wrote: >> ...and I will be lucky if ldns_resolver_print() will also print >> _fallback, _dnssec and _dnssec_cd flags :) >> >> Thanks again, >> Zbynek >> >> On 19.4.2010 14:51, Zbynek Michl wrote: >>> Hi there, >>> >>> what are these flags good for? I guess that they are not in use, however >>> ldns_resolver_print() function prints their uninitialized values. So >>> will not be better to remove them from ldns_resolver_print() or >>> initialize them by ldns_resolver_new()? >>> >>> Thanks, >>> Zbynek >> _______________________________________________ >> 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.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEcBAEBAgAGBQJLzuxDAAoJEA8yVCPsQCW5w+sH/1Fd25Ytru8DpwSYwffhyLsQ > Frn2JFC2ibOQ1/1BscG/DCWRSZUWcWAgTtp6LG6iQaGmLBUts2U7dzxeOUDAc2t2 > Ny7/7ZALke5yu4gGZ8gBTamZ/AR1UH66n4tLEhPg7NUxsy/FeYsC8cm8NKeiT439 > dox1axxKvDJW8BHuwdK/B7SS8Xv81ynnjozzTBrOfr/vc2TPq2Af0dF+nN9bCikm > zzHQqYOiNeXBd9EIORys8LdM9bCFpa7cV+lzIRr7R05mnNqSUrPvC8jflVAr69HK > LJiHEps4Gvzy+cauov+yZuo/fYb6xvT534gGmNmdUYpOKF8POP2ftGE+9ih83uI= > =sjDM > -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Wed Apr 21 15:08:11 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 21 Apr 2010 17:08:11 +0200 Subject: [ldns-users] _recursive and _igntc flags in ldns_struct_resolver In-Reply-To: <4BCF035A.5010905@nic.cz> References: <4BCC51BE.9070208@nic.cz> <4BCC6577.607@nic.cz> <4BCEEC4B.50802@nlnetlabs.nl> <4BCF035A.5010905@nic.cz> Message-ID: <4BCF14DB.5060909@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was trigger happy. Removed the duplicates. Thanks, Matthijs Zbynek Michl wrote: > Thanks Matthijs, btw some items in ldns_resolver_print() are duplicated > (e.g. ldns_resolver_ip6(), ldns_resolver_usevc(), ldns_resolver_igntc()). > > Regards, > Zbynek > > On 21.4.2010 14:15, Matthijs Mekking wrote: > Hi Zbynek, > > I have completed the list of defaults in ldns_resolver_new() and add > more printouts in ldns_resolver_print(). > > Best regards, > > Matthijs > > Zbynek Michl wrote: >>>> ...and I will be lucky if ldns_resolver_print() will also print >>>> _fallback, _dnssec and _dnssec_cd flags :) >>>> >>>> Thanks again, >>>> Zbynek >>>> >>>> On 19.4.2010 14:51, Zbynek Michl wrote: >>>>> Hi there, >>>>> >>>>> what are these flags good for? I guess that they are not in use, >>>>> however >>>>> ldns_resolver_print() function prints their uninitialized values. So >>>>> will not be better to remove them from ldns_resolver_print() or >>>>> initialize them by ldns_resolver_new()? >>>>> >>>>> Thanks, >>>>> Zbynek >>>> _______________________________________________ >>>> 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLzxTZAAoJEA8yVCPsQCW5NBYH/2BuBuL5U683dSA+LgQQoF0n GEvIlmGBRNG0MXlE7U7v/ctHDbl4d7T9e9/fwsKam5DtHNA+oQDUhzw7hFBtkpzp aC7hn2JkqonEG2LpbCUhUd6ATnwYVKKEjhVouwF7BNZmYBvXoO+5wWqL7WSlqrSg Aw7lBIY5b+QrMWiKAhshJzbFsphb+v75pVRGsgvIi09L0X5ortKEFd3sRaijh1fD TOmaMqg19+qdWER31VuNSrSH4Q+LvytKQxWLkKwhosa406+DhG3htHsPhh6eg5Uq r0uhvfLZf6uAi7QD9c4O2KWxvrX0zWbwDQVn/10m9E7OxfsSgGackSL8YUYTopA= =hEOl -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Wed Apr 21 17:20:16 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Wed, 21 Apr 2010 19:20:16 +0200 Subject: [ldns-users] Improper randomness in ldns_resolver_nameservers_randomize() function Message-ID: <4BCF33D0.1040303@nic.cz> Hi, there is no seed initialization before random() function and it leads to select the first resolver everytime from the list if it contains exactly two resolvers. I guess that init with "srandom((unsigned int)time(NULL))" should be enough for this purpose. Thanks, Zbynek From fetchmail at chrissmith.org Thu Apr 29 14:05:13 2010 From: fetchmail at chrissmith.org (Chris Smith) Date: Thu, 29 Apr 2010 10:05:13 -0400 Subject: [ldns-users] building drill dies Message-ID: When trying to build drill with ldns (I'm using svn trunk) and the Gentoo ebuild system the autoreconf dies with: aclocal-1.10: couldn't open directory `m4': No such file or directory I can remove the line: ACLOCAL_AMFLAGS = -Im4 from drill's Makefile.in and all works fine. Not a programmer so I don't know the best way to fix this, but I'm guessing there should either be an m4 directory or that line should not be there. Chris From wouter at NLnetLabs.nl Thu Apr 29 15:14:22 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Thu, 29 Apr 2010 17:14:22 +0200 Subject: [ldns-users] building drill dies In-Reply-To: References: Message-ID: <4BD9A24E.7030002@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris, In svn trunk the drill Makefile.in does not have that line in it? It does exist in the ldns/trunk/Makefile.in but that works fine? Did you overwrite the drill/Makefile.in with the other one somehow? Or what is the sequence of steps I can take to reproduce this? Best regards, Wouter On 04/29/2010 04:05 PM, Chris Smith wrote: > When trying to build drill with ldns (I'm using svn trunk) and the > Gentoo ebuild system the autoreconf dies with: > aclocal-1.10: couldn't open directory `m4': No such file or directory > > I can remove the line: > ACLOCAL_AMFLAGS = -Im4 > from drill's Makefile.in and all works fine. > > Not a programmer so I don't know the best way to fix this, but I'm > guessing there should either be an m4 directory or that line should > not be there. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvZok0ACgkQkDLqNwOhpPilOQCeJVVzqjrPAd0ypNhEb6LLiIEz O3EAnRBMqQblPhu6+/RPmLPJgkh7KkHz =t0V7 -----END PGP SIGNATURE-----