From bedrich.kosata at nic.cz Wed May 4 07:26:23 2011 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Wed, 04 May 2011 09:26:23 +0200 Subject: [ldns-users] pyldns - memory leaks and double freeing In-Reply-To: <4DA5B936.30606@nlnetlabs.nl> References: <4D8C56E1.7040301@nic.cz> <4DA546A3.5030600@nic.cz> <4DA5B936.30606@nlnetlabs.nl> Message-ID: <4DC0FF9F.5020202@nic.cz> Hi Willem, by looking at the current SVN code, I found out, that I actually did not include part of the code into the patch I sent last time. This is the part about RRSIG checking - marked in my last post below. I am attaching the patch for ldns_rr.i now. Best regards Beda p.s.- I am currently working on some more memory issues related to rr and rdf sharing the same data. I hope to be able to send something soon. On 04/13/2011 04:54 PM, Willem Toorop wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Bedrich, > > I've applied your patches in trunk. > The tests run all fine with me. > Thanks for fixing this. > > Best regards, Willem > > > On 04/13/11 08:45, Bedrich Kosata wrote: >> Hi again, >> >> as nobody seemed to have anything against my proposal, I prepared the >> patches that should fix the problems I outlined before :) >> >> When the patches are applied, the python bindings should always have >> rr_list and rr structs separated in memory. This is accomplished by >> always cloning rr data when either adding them to an rr_list or >> retrieving them from the rr_list. This was not in the last patch.. >> Most of the changes should be transparent and should not require >> modifications to existing code. The only outside change I had to make >> was in the "ldns_verify_rrsig_keylist_notime" and >> "ldns_verify_rrsig_keylist" functions, because it copies pointers to the >> correct keys into a second rr_list. I solved this by replacing each of >> these functions by two new ones (thus creating four functions). All >> versions take only 3 arguments and differ in the way they treat the >> good_keys value. One versions name ends with "_status_only" (e.g. >> ldns_verify_rrsig_keylist_notime_status_only) and this does not report >> the good_keys at all, just the result of verification. The other ends >> with "_" (e.g. ldns_verify_rrsig_keylist_notime_) and returns a tuple >> (status, good_keys) where good_keys are indexes of the keys in the key >> list supplied to the function. Thus the whole business of two rr_lists >> sharing the same data is sidestepped. >> .. and here it ends >> The patches are made for each file separately because the fixes are >> mostly independent. I also included several test scripts which should >> show how the situation was fixed. They either show a situation where the >> old version would crash with a segmentation fault or display the amount >> of memory the app has used thus pointing to a memory leak. When used >> with patched sources, none of the scripts should crash and none should >> report more that ~30MB of memory used. >> >> Best regards >> >> Beda >> >> p.s.- the patch for ldns_rdf.i is in fact not related to the rest and >> fixes and unrelated memory leak in ldns_rdf.new_frm_str >> >> p.p.s.- I did not touch a related issue of rr and rdf relationship. In >> current version, the rdf data does not live beyond the lifetime of the >> corresponding rr. This is demonstrated in the attached >> test-rrlist-get-rdf.py. The problem could again be solved by cloning all >> rdfs on retrieval and addition from/into an rr. >> However, I will wait how the current patch is received before I start >> thinking about fixing it. >> >> >> On 03/25/2011 09:48 AM, Bedrich Kosata wrote: >>> Hi everybody, >>> >>> while trying to find a cause of a memory leak in a simple script, I >>> found a nest of memory related issues in the python bindings. >>> The problems are all related to one common problem - who takes care of >>> memory of composite objects, such as ldns_rr_lists or ldns_pkt. >>> For example, in the current version, ldns_pkt bindings use ldns_pkt_free >>> to free a packet structure, however, when a rr_list is taken from the >>> packet and returned from a function, the packet gets out of scope, is >>> freed and the rr_list refers to already freed memory. >>> On the other hand, a rr_list only frees its own memory, not memory of >>> the stored rrs. This can lead to memory leaks. >>> I am attaching two scripts that demonstrate these problems (it might be >>> necessary to have the sources patched with the "freeing None" patch I >>> sent last week). >>> I would be willing to have a stab at the problems (provided I get >>> clearance from my boss :)), but the only solution I think would be clean >>> enough, is to clone the necessary bits where needed. This might lead to >>> some inefficiency and slowdowns (probably not big), so I would like to >>> ask if this is ok. >>> If there is anyone else willing to fix this, I would be happy to act as >>> a tester. >>> >>> Cheers >>> >>> Beda >>> >>> p.s.- test-pkt-free.py crashes with a segmentation fault, >>> test-rr-list.py ends up eating about 130 MB of memory and more than >>> 400000 python objects which python cannot free. >>> >>> >>> >>> _______________________________________________ >>> 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 v2.0.17 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNpbk2AAoJEOX4+CEvd6SYMx0P/i4X059sn9fXRk7WzEdOdsz4 > AtDbi1B/rf2D26WN2rjrQwJRhmaC6s20YKeo9h4cFBqcZrROaOWseeMqN24iOYsI > Rt1ltWPbe+2th+G1o9r6F7keZU3i1PUxPGEgzpTe8o8xicq5tP9pJlpI/43ISj2T > KHKLi1Ps6B/TPOM519q50FCapTFU/IlaybONGJ12Ts3QhtwUB/Q0uUL5DmJWM8B6 > iz2Jqy5/ABJYmyiVDup2rtVW/nZI0t032PCP8qHBEVlfZvRyX7Cm0TMLpXLH80cH > w6AXkdj+FUOD7uDi8cxGxMeQnYg/OtgjerTaVqc0+1v3XgwxflReIxpZ1rudUz81 > YGf04XFuzk8+2/X3wukfXLoNAMQCSaqsQLtR5N1u/JMDt5KlBRcpzEPQJjLbxTBc > ABsCuCuhrVgVclMTkLXZ/aIVAcx1Rjwjgppxr3Rc0Ixp+gPEWZb8SZc5ZAvucAI1 > lVHVi7gohiFdQ9tILByxkFVvbzTYvbkojUJ2zgobJuGdfJ/KnIQ/mt9lZ3PF3IEu > jkPpNRKGqY9diTuMQt9hQvKbXQF0KedP1kjUYFDhHql2li0xpdVzvHq+Xpgc/jGj > owj4faYKHo9QSxbMhshuypV3+QF3Ck9l2IwGCTWw2qM9ffXKH+eB8HA5aXsuz70p > dSfoo4W83DQRqjdS3Vk/ > =LBN9 > -----END PGP SIGNATURE----- -- Bedrich Kosata CZ.NIC Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns_rr.i-rrsig_wrappers.patch Type: text/x-patch Size: 3001 bytes Desc: not available URL: From bedrich.kosata at nic.cz Thu May 5 08:33:49 2011 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Thu, 05 May 2011 10:33:49 +0200 Subject: [ldns-users] python wrapper for ldns_rr_new_frm_fp_l Message-ID: <4DC260ED.3070106@nic.cz> Hi everybody, after working with the python wrapper around ldns_rr_new_frm_fp_l, I would like to propose a few changes. The C version of the ldns_rr_new_frm_fp_l function stores the state of zone file parsing in 3 different variables - origin, prev(ious owner) and (default) ttl. Due to pointer and pointer to pointer usage, these are automatically updated by calls to ldns_rr_new_frm_fp_l and the only thing the programmer has to take care of it not to touch these. However, in Python this is not possible and the wrapper goes around this problem by returning the new values of origin, prev and ttl as part of the result of the function. It is then left to the programmer to send these updated values back to the subsequent calls of ldns.ldns_rr_new_frm_fp_l_. I attach a script that shows how to do this and I would suggest putting it into the examples directory as reference. I also added a convenience function (a generator) into the python interface, so that the context is managed automatically and the programmer does not have to take care of it. It is part of the patch I attach. There is also a demo script for this function attached. Another change that I made in the patch is that I removed the 5th argument, which indicated whether the result should contain line number. As the value of this argument influenced the number and order of items in the returned tuple, which I do not consider a good design, I removed it and changed the result, so that it always contains the number of lines parsed in this step and the format of the result is always the same. Please let me know if these changes are acceptable or if there is something else needed. With best regards Beda -- Bedrich Kosata CZ.NIC Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns_rr_new_frm_fp_l_iter.patch Type: text/x-patch Size: 5063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns_rr_iter_frm_fp_l.demo.py Type: text/x-python Size: 212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns_rr_new_frm_fp_l.demo.py Type: text/x-python Size: 1210 bytes Desc: not available URL: From bedrich.kosata at nic.cz Thu May 5 09:04:48 2011 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Thu, 05 May 2011 11:04:48 +0200 Subject: [ldns-users] decoupling rr and rdf in the python wrapper Message-ID: <4DC26830.6020702@nic.cz> Hi, as I wrote some time ago, there is still a problem with the ldns Python wrapper, because an RR shares its data with the included RDF and if the RDF is stored in a variable and the RR is garbage collected, the RDF data is no longer available. I attach two scripts that demonstrate this problem (one gives empty RDF instead of the actual data and one segfaults). I also attach a patch which clones all RDFs when retreived from an RR and also when RDF is set to an RR. This should decouple the RDF and RR data completely in the Python wrapper, thus making it possible for the objects to be garbage collected in any order at any time. Best regards Beda p.s.- as with the patch in the previous email, the patch is against the current svn version. -- Bedrich Kosata CZ.NIC Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: ldns_rr_rdf_decoupling.patch Type: text/x-patch Size: 21456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-rrlist-get-rdf.py Type: text/x-python Size: 533 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-set-owner.new2.py Type: text/x-python Size: 256 bytes Desc: not available URL: From willem at NLnetLabs.nl Tue May 17 20:56:32 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 17 May 2011 22:56:32 +0200 Subject: [ldns-users] pyldns - memory leaks and double freeing In-Reply-To: <4DC0FF9F.5020202@nic.cz> References: <4D8C56E1.7040301@nic.cz> <4DA546A3.5030600@nic.cz> <4DA5B936.30606@nlnetlabs.nl> <4DC0FF9F.5020202@nic.cz> Message-ID: <4DD2E100.90104@nlnetlabs.nl> Hi Bedrich, I've applied the patch in trunk. Thanks! Willem Op 04-05-11 09:26, Bedrich Kosata schreef: > Hi Willem, > > by looking at the current SVN code, I found out, that I actually did not include part of the code into the patch I sent last time. > This is the part about RRSIG checking - marked in my last post below. > I am attaching the patch for ldns_rr.i now. > > Best regards > > Beda > > p.s.- I am currently working on some more memory issues related to rr and rdf sharing the same data. I hope to be able to send something soon. > > > On 04/13/2011 04:54 PM, Willem Toorop wrote: > Hi Bedrich, > > I've applied your patches in trunk. > The tests run all fine with me. > Thanks for fixing this. > > Best regards, Willem > > > On 04/13/11 08:45, Bedrich Kosata wrote: > >>> Hi again, > >>> > >>> as nobody seemed to have anything against my proposal, I prepared the > >>> patches that should fix the problems I outlined before :) > >>> > >>> When the patches are applied, the python bindings should always have > >>> rr_list and rr structs separated in memory. This is accomplished by > >>> always cloning rr data when either adding them to an rr_list or > >>> retrieving them from the rr_list. > > > This was not in the last patch.. > > >>> Most of the changes should be transparent and should not require > >>> modifications to existing code. The only outside change I had to make > >>> was in the "ldns_verify_rrsig_keylist_notime" and > >>> "ldns_verify_rrsig_keylist" functions, because it copies pointers > to the > >>> correct keys into a second rr_list. I solved this by replacing each of > >>> these functions by two new ones (thus creating four functions). All > >>> versions take only 3 arguments and differ in the way they treat the > >>> good_keys value. One versions name ends with "_status_only" (e.g. > >>> ldns_verify_rrsig_keylist_notime_status_only) and this does not report > >>> the good_keys at all, just the result of verification. The other ends > >>> with "_" (e.g. ldns_verify_rrsig_keylist_notime_) and returns a tuple > >>> (status, good_keys) where good_keys are indexes of the keys in the key > >>> list supplied to the function. Thus the whole business of two rr_lists > >>> sharing the same data is sidestepped. > >>> > > > .. and here it ends > > >>> The patches are made for each file separately because the fixes are > >>> mostly independent. I also included several test scripts which should > >>> show how the situation was fixed. They either show a situation > where the > >>> old version would crash with a segmentation fault or display the > amount > >>> of memory the app has used thus pointing to a memory leak. When used > >>> with patched sources, none of the scripts should crash and none should > >>> report more that ~30MB of memory used. > >>> > >>> Best regards > >>> > >>> Beda > >>> > >>> p.s.- the patch for ldns_rdf.i is in fact not related to the rest and > >>> fixes and unrelated memory leak in ldns_rdf.new_frm_str > >>> > >>> p.p.s.- I did not touch a related issue of rr and rdf relationship. In > >>> current version, the rdf data does not live beyond the lifetime of the > >>> corresponding rr. This is demonstrated in the attached > >>> test-rrlist-get-rdf.py. The problem could again be solved by > cloning all > >>> rdfs on retrieval and addition from/into an rr. > >>> However, I will wait how the current patch is received before I start > >>> thinking about fixing it. > >>> > >>> > >>> On 03/25/2011 09:48 AM, Bedrich Kosata wrote: > >>>> Hi everybody, > >>>> > >>>> while trying to find a cause of a memory leak in a simple script, I > >>>> found a nest of memory related issues in the python bindings. > >>>> The problems are all related to one common problem - who takes > care of > >>>> memory of composite objects, such as ldns_rr_lists or ldns_pkt. > >>>> For example, in the current version, ldns_pkt bindings use > ldns_pkt_free > >>>> to free a packet structure, however, when a rr_list is taken from the > >>>> packet and returned from a function, the packet gets out of scope, is > >>>> freed and the rr_list refers to already freed memory. > >>>> On the other hand, a rr_list only frees its own memory, not memory of > >>>> the stored rrs. This can lead to memory leaks. > >>>> I am attaching two scripts that demonstrate these problems (it > might be > >>>> necessary to have the sources patched with the "freeing None" patch I > >>>> sent last week). > >>>> I would be willing to have a stab at the problems (provided I get > >>>> clearance from my boss :)), but the only solution I think would > be clean > >>>> enough, is to clone the necessary bits where needed. This might > lead to > >>>> some inefficiency and slowdowns (probably not big), so I would > like to > >>>> ask if this is ok. > >>>> If there is anyone else willing to fix this, I would be happy to > act as > >>>> a tester. > >>>> > >>>> Cheers > >>>> > >>>> Beda > >>>> > >>>> p.s.- test-pkt-free.py crashes with a segmentation fault, > >>>> test-rr-list.py ends up eating about 130 MB of memory and more than > >>>> 400000 python objects which python cannot free. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at NLnetLabs.nl Tue May 17 20:58:12 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 17 May 2011 22:58:12 +0200 Subject: [ldns-users] python wrapper for ldns_rr_new_frm_fp_l In-Reply-To: <4DC260ED.3070106@nic.cz> References: <4DC260ED.3070106@nic.cz> Message-ID: <4DD2E164.5060906@nlnetlabs.nl> Hi Bedrich, I love the generator function. Looks like the pytonicly correct way to access ldns_rr_new_frm_fp_l from python to me! The patch is applied in trunk, and the demo scripts added to the example directory. Thanks again! Willem Op 05-05-11 10:33, Bedrich Kosata schreef: > Hi everybody, > > after working with the python wrapper around ldns_rr_new_frm_fp_l, I > would like to propose a few changes. > > The C version of the ldns_rr_new_frm_fp_l function stores the state of > zone file parsing in 3 different variables - origin, prev(ious owner) > and (default) ttl. Due to pointer and pointer to pointer usage, these > are automatically updated by calls to ldns_rr_new_frm_fp_l and the > only thing the programmer has to take care of it not to touch these. > > However, in Python this is not possible and the wrapper goes around > this problem by returning the new values of origin, prev and ttl as > part of the result of the function. It is then left to the programmer > to send these updated values back to the subsequent calls of > ldns.ldns_rr_new_frm_fp_l_. I attach a script that shows how to do > this and I would suggest putting it into the examples directory as > reference. > > I also added a convenience function (a generator) into the python > interface, so that the context is managed automatically and the > programmer does not have to take care of it. It is part of the patch I > attach. There is also a demo script for this function attached. > > Another change that I made in the patch is that I removed the 5th > argument, which indicated whether the result should contain line > number. As the value of this argument influenced the number and order > of items in the returned tuple, which I do not consider a good design, > I removed it and changed the result, so that it always contains the > number of lines parsed in this step and the format of the result is > always the same. > > Please let me know if these changes are acceptable or if there is > something else needed. > > With best regards > > Beda > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at NLnetLabs.nl Tue May 17 21:03:16 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 17 May 2011 23:03:16 +0200 Subject: [ldns-users] decoupling rr and rdf in the python wrapper In-Reply-To: <4DC26830.6020702@nic.cz> References: <4DC26830.6020702@nic.cz> Message-ID: <4DD2E294.30706@nlnetlabs.nl> Thanks for the fix. I've applied the patch in trunk! Best regards, Willem Op 05-05-11 11:04, Bedrich Kosata schreef: > Hi, > > as I wrote some time ago, there is still a problem with the ldns > Python wrapper, because an RR shares its data with the included RDF > and if the RDF is stored in a variable and the RR is garbage > collected, the RDF data is no longer available. > I attach two scripts that demonstrate this problem (one gives empty > RDF instead of the actual data and one segfaults). > I also attach a patch which clones all RDFs when retreived from an RR > and also when RDF is set to an RR. This should decouple the RDF and RR > data completely in the Python wrapper, thus making it possible for the > objects to be garbage collected in any order at any time. > > Best regards > > Beda > > p.s.- as with the patch in the previous email, the patch is against > the current svn version. > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at NLnetLabs.nl Wed May 18 09:34:09 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 18 May 2011 11:34:09 +0200 Subject: [ldns-users] drill uses local resolvers In-Reply-To: <4DB8192D.7070100@pernau.at> References: <4DB8192D.7070100@pernau.at> Message-ID: <4DD39291.1010708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Klaus, I've not been able to reproduce this. What does your query look like exactly? Do you use a trace (-T)? With me it doesn't even query the local resolver when I don't use the -r option (because of the hard-coded root-servers). Best regards, Willem On 04/27/11 15:25, Klaus Darilion wrote: > Hi! > > I experienced strange problems with drill 1.6.6 and 1.6.9. Although I > specify root servers with -r, sometimes (50% chance) the local > configured resolver is asked for a root-server list. With drill 1.6.4 > this random behavior was not seen yet. > > Are there any known issues? > > Thanks > Klaus > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN05KRAAoJEOX4+CEvd6SYcSkP/iXlG9rMmVS5vpVA75CdQkiJ Uavd2shF49DhR99NgIAYDdsDSGjFetZgizAFcEjiuH9s6oVHWwfEinVSCVN5s2xJ Gh2QXJWWP3apT4imZIIfk/9CCsXywDeNKWAkKng3nbbH4H/cBb8xw8cvRTdy2aRr Drwv6xuFIhuSohACLZiZIWWaKxzEjP1Hs6GFaOJpKJhF0AjEuOU4PysiT/zzof21 BuDEz0or8uxYKhkRPuwILKbJuMdczg4PUpXOo7qrMh5aPZ26zNyKIKA1hHV0aU1u kNuOMyrzZxf5isUyRzKvSv9BmQrGBemTAE8SizijilCCKYJGWCxfFyrABn4p6VFO XBZFQacV2YlTLMQ/C172vxPCjjwPEEpPpXUeNNJfIBDPB+yZVLqDpJSBUL4y5tAH 17auDYpjrErU4CrI+KmaQ40RWVLHLIvd6U6taW+W3uZKOyDzid9m5PDiq7AeA3rR 4HAIHTlh4FLCAKJITsqGxKff3PY/pTP3jrRcGlow6p4ftHvab7pOKqI1MP7i7bg9 WTY2haRmFTH0w8LgAntsPeUkSqaDk60N85F2Y7Ijp5tvqTGAMvmK317Q5G/zGn9J rQKDK8vaPCBeJ2Di2x2gWw0hAu/dG5Ebf7jet7M5TRQ0nBFwA4slE3Th59Mf+Khn 6oZ+a55K66+ovl6/5vL/ =4yfl -----END PGP SIGNATURE----- From klaus.mailinglists at pernau.at Wed May 18 11:35:14 2011 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 18 May 2011 13:35:14 +0200 Subject: [ldns-users] drill uses local resolvers In-Reply-To: <4DD39291.1010708@nlnetlabs.nl> References: <4DB8192D.7070100@pernau.at> <4DD39291.1010708@nlnetlabs.nl> Message-ID: <4DD3AEF2.8070504@pernau.at> Hi Willem! # cat /etc/resolv.conf nameserver 83.136.32.189 nameserver 83.136.32.190 # cat root.key . IN DNSKEY 257 3 8 AwEAAYH7ht0DNAz3M8mmyhbuEMTXAPrUoLNKgUnTo4ELMBfKefUgBrp9+hJ3ThgIu2rfCWAudeGQlGSTAGvpPYwvXdQUXhT1mogDM7bg2yTUgP+XaRNn2GtLEEW5qWgb3LSqkq191bYZO4/ic43I1lfoY4frkv/eccTsLMSByc9iV7N+6Fk93cZnKY5AfeE+kqkSrBYHNkgk43exMBqUXV6XasmxZjv4mMppMHHMYR203KXYqgyEvNwa7T0oS/hsfx0Eygq5jqNmnb4zlYRiu7UfZ9Nw3Z/0H4MJxq5+By2aMM5p6xyapBV/3j5mcYdAPVQcgnYX68y+lxVD8cge93VoBLU= ;{id = 63086 (ksk), size = 2048b} # cat root.hint . 3600000 IN NS root.dnssec-test.nic.at. root.dnssec-test.nic.at. 3600000 A 131.130.200.227 # drill -TD -k root.key -r root.hint ftp.radiopannen.at A Thus, drill should use the root server from the file root.key -> 131.130.200.227 Sometimes drill starts with this root hint and switches to the local resolvers after some time. Sometimes drill even starts with the local resolver. tshark trace of what drill is doing: 9.083159 83.136.32.148 -> 83.136.32.189 DNS Standard query NS 9.083490 83.136.32.189 -> 83.136.32.148 DNS Standard query response NS i.root-servers.net NS l.root-servers.net NS m.root-servers.net NS c.root-servers.net NS g.root-servers.net NS h.root-servers.net NS a.root-servers.net NS b.root-servers.net NS d.root-servers.net NS f.root-servers.net NS e.root-servers.net NS j.root-servers.net NS k.root-servers.net RRSIG 9.083734 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA l.root-servers.net 9.124785 83.136.32.189 -> 83.136.32.148 DNS Standard query response AAAA 2001:500:3::42 9.124911 83.136.32.148 -> 83.136.32.190 DNS Standard query A l.root-servers.net 9.125700 83.136.32.190 -> 83.136.32.148 DNS Standard query response A 199.7.83.42 9.125948 83.136.32.148 -> 131.130.200.227 DNS Standard query AAAA b.root-servers.net 9.127723 131.130.200.227 -> 83.136.32.148 DNS Standard query response, No such name 9.127796 83.136.32.148 -> 83.136.32.189 DNS Standard query A b.root-servers.net 9.166865 83.136.32.189 -> 83.136.32.148 DNS Standard query response A 192.228.79.201 9.167098 83.136.32.148 -> 131.130.200.227 DNS Standard query AAAA f.root-servers.net 9.168655 131.130.200.227 -> 83.136.32.148 DNS Standard query response, No such name 9.168721 83.136.32.148 -> 131.130.200.227 DNS Standard query A f.root-servers.net 9.170164 131.130.200.227 -> 83.136.32.148 DNS Standard query response, No such name 9.170352 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA f.root-servers.net 9.283713 83.136.32.189 -> 83.136.32.148 DNS Standard query response AAAA 2001:500:2f::f 9.283908 83.136.32.148 -> 83.136.32.189 DNS Standard query A f.root-servers.net 9.310273 83.136.32.189 -> 83.136.32.148 DNS Standard query response A 192.5.5.241 9.310579 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA j.root-servers.net 9.310838 83.136.32.189 -> 83.136.32.148 DNS Standard query response AAAA 2001:503:c27::2:30 9.310922 83.136.32.148 -> 83.136.32.189 DNS Standard query A j.root-servers.net 9.493322 83.136.32.189 -> 83.136.32.148 DNS Standard query response A 192.58.128.30 9.493618 83.136.32.148 -> 83.136.32.190 DNS Standard query AAAA k.root-servers.net 9.494389 83.136.32.190 -> 83.136.32.148 DNS Standard query response AAAA 2001:7fd::1 9.494461 83.136.32.148 -> 83.136.32.190 DNS Standard query A k.root-servers.net 9.495215 83.136.32.190 -> 83.136.32.148 DNS Standard query response A 193.0.14.129 9.495403 83.136.32.148 -> 192.5.5.241 DNS Standard query DNSKEY 9.678349 192.5.5.241 -> 83.136.32.148 DNS Standard query response DNSKEY DNSKEY RRSIG 9.681066 83.136.32.148 -> 128.63.2.53 DNS Standard query DS at 9.786338 128.63.2.53 -> 83.136.32.148 DNS Standard query response 9.786711 83.136.32.148 -> 192.58.128.30 DNS Standard query DNSKEY ftp.radiopannen.at 9.811558 192.58.128.30 -> 83.136.32.148 DNS Standard query response 9.811801 83.136.32.148 -> 198.41.0.4 DNS Standard query DS at 9.851583 198.41.0.4 -> 83.136.32.148 DNS Standard query response 9.852179 2a02:850:1:1:216:3eff:fe4f:69b7 -> 2001:503:c27::2:30 DNS Standard query NS at 10.034797 2001:503:c27::2:30 -> 2a02:850:1:1:216:3eff:fe4f:69b7 DNS Standard query response 10.035221 83.136.32.148 -> 193.171.255.2 DNS Standard query DNSKEY at 10.035966 193.171.255.2 -> 83.136.32.148 DNS Standard query response 10.036100 83.136.32.148 -> 194.0.10.100 DNS Standard query DS radiopannen.at 10.043381 194.0.10.100 -> 83.136.32.148 DNS Standard query response 10.043501 83.136.32.148 -> 194.146.106.50 DNS Standard query DNSKEY ftp.radiopannen.at 10.044135 194.146.106.50 -> 83.136.32.148 DNS Standard query response 10.044261 83.136.32.148 -> 81.91.161.98 DNS Standard query DS radiopannen.at 10.075231 81.91.161.98 -> 83.136.32.148 DNS Standard query response 10.075433 83.136.32.148 -> 87.233.175.130 DNS Standard query NS radiopannen.at 10.113906 87.233.175.130 -> 83.136.32.148 DNS Standard query response 10.114454 83.136.32.148 -> 195.66.241.82 DNS Standard query AAAA ns1.world4you.at 10.161133 195.66.241.82 -> 83.136.32.148 DNS Standard query response 10.161262 83.136.32.148 -> 81.91.161.98 DNS Standard query A ns1.world4you.at 10.192491 81.91.161.98 -> 83.136.32.148 DNS Standard query response 10.192877 83.136.32.148 -> 83.136.32.190 DNS Standard query AAAA ns1.world4you.at 10.198029 83.136.32.190 -> 83.136.32.148 DNS Standard query response 10.198162 83.136.32.148 -> 83.136.32.190 DNS Standard query A ns1.world4you.at 10.202997 83.136.32.190 -> 83.136.32.148 DNS Standard query response A 81.19.145.5 10.203281 83.136.32.148 -> 81.91.161.98 DNS Standard query AAAA ns2.world4you.at 10.234486 81.91.161.98 -> 83.136.32.148 DNS Standard query response 10.234605 83.136.32.148 -> 87.233.175.130 DNS Standard query A ns2.world4you.at 10.272834 87.233.175.130 -> 83.136.32.148 DNS Standard query response 10.273105 83.136.32.148 -> 83.136.32.190 DNS Standard query AAAA ns2.world4you.at 10.278093 83.136.32.190 -> 83.136.32.148 DNS Standard query response AAAA 2a00:1a68:80a1::d02 10.278194 83.136.32.148 -> 83.136.32.189 DNS Standard query A ns2.world4you.at 10.278469 83.136.32.189 -> 83.136.32.148 DNS Standard query response A 81.19.147.5 10.278610 83.136.32.148 -> 81.19.147.5 DNS Standard query DNSKEY radiopannen.at 10.279060 81.19.147.5 -> 83.136.32.148 DNS Standard query response 10.279200 83.136.32.148 -> 81.19.147.5 DNS Standard query DS ftp.radiopannen.at 10.279666 81.19.147.5 -> 83.136.32.148 DNS Standard query response 10.279775 83.136.32.148 -> 81.19.145.5 DNS Standard query DNSKEY ftp.radiopannen.at 10.283634 81.19.145.5 -> 83.136.32.148 DNS Standard query response 10.283763 2a02:850:1:1:216:3eff:fe4f:69b7 -> 2a00:1a68:80a1::d02 DNS Standard query DS ftp.radiopannen.at 10.284272 2a00:1a68:80a1::d02 -> 2a02:850:1:1:216:3eff:fe4f:69b7 DNS Standard query response 10.284411 83.136.32.148 -> 81.19.147.5 DNS Standard query NS ftp.radiopannen.at 10.284904 81.19.147.5 -> 83.136.32.148 DNS Standard query response 10.285017 83.136.32.148 -> 81.19.145.5 DNS Standard query DNSKEY ftp.radiopannen.at 10.288602 81.19.145.5 -> 83.136.32.148 DNS Standard query response 10.288772 83.136.32.148 -> 81.19.147.5 DNS Standard query A ftp.radiopannen.at 10.289195 81.19.147.5 -> 83.136.32.148 DNS Standard query response A 81.19.145.146 32.987231 83.136.32.148 -> 83.136.32.189 DNS Standard query A gucci 32.987242 83.136.32.148 -> 83.136.32.189 DNS Standard query A gucci 32.987246 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA gucci 32.987278 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA gucci 32.989809 83.136.32.189 -> 83.136.32.148 DNS Standard query response, No such name 32.989845 83.136.32.189 -> 83.136.32.148 DNS Standard query response, No such name 33.028541 83.136.32.189 -> 83.136.32.148 DNS Standard query response, No such name 33.028576 83.136.32.189 -> 83.136.32.148 DNS Standard query response, No such name regards Klaus Am 18.05.2011 11:34, schrieb Willem Toorop: > Hi Klaus, > > I've not been able to reproduce this. What does your query look like > exactly? Do you use a trace (-T)? > > With me it doesn't even query the local resolver when I don't use the -r > option (because of the hard-coded root-servers). > > Best regards, Willem > > On 04/27/11 15:25, Klaus Darilion wrote: >> Hi! > >> I experienced strange problems with drill 1.6.6 and 1.6.9. Although I >> specify root servers with -r, sometimes (50% chance) the local >> configured resolver is asked for a root-server list. With drill 1.6.4 >> this random behavior was not seen yet. > >> Are there any known issues? > >> Thanks >> Klaus >> _______________________________________________ >> 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 From willem at NLnetLabs.nl Wed May 18 13:09:25 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Wed, 18 May 2011 15:09:25 +0200 Subject: [ldns-users] drill uses local resolvers In-Reply-To: <4DD3AEF2.8070504@pernau.at> References: <4DB8192D.7070100@pernau.at> <4DD39291.1010708@nlnetlabs.nl> <4DD3AEF2.8070504@pernau.at> Message-ID: <4DD3C505.3050901@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Klaus, I've found the culprit. On line 266 till 270 of securetrace.c the nameservers of the local resolver are copied to the ``resolver to be used''. The comment text justifying this states: /* if no servers is given with @, start by asking local resolver */ /* first part todo :) */ Now there is something to say for querying "." at the local resolver when no root-servers are available to start a trace from, but that piece of code was the right way nor place for that. I have it fixed in trunk. The fix will be in the next release that will follow shortly. Thanks for noticing and the report! Willem On 05/18/11 13:35, Klaus Darilion wrote: > Hi Willem! > > > # cat /etc/resolv.conf > nameserver 83.136.32.189 > nameserver 83.136.32.190 > > > > # cat root.key > . IN DNSKEY 257 3 8 > AwEAAYH7ht0DNAz3M8mmyhbuEMTXAPrUoLNKgUnTo4ELMBfKefUgBrp9+hJ3ThgIu2rfCWAudeGQlGSTAGvpPYwvXdQUXhT1mogDM7bg2yTUgP+XaRNn2GtLEEW5qWgb3LSqkq191bYZO4/ic43I1lfoY4frkv/eccTsLMSByc9iV7N+6Fk93cZnKY5AfeE+kqkSrBYHNkgk43exMBqUXV6XasmxZjv4mMppMHHMYR203KXYqgyEvNwa7T0oS/hsfx0Eygq5jqNmnb4zlYRiu7UfZ9Nw3Z/0H4MJxq5+By2aMM5p6xyapBV/3j5mcYdAPVQcgnYX68y+lxVD8cge93VoBLU= > ;{id = 63086 (ksk), size = 2048b} > > > > > # cat root.hint > . 3600000 IN NS root.dnssec-test.nic.at. > root.dnssec-test.nic.at. 3600000 A 131.130.200.227 > > > > > # drill -TD -k root.key -r root.hint ftp.radiopannen.at A > > Thus, drill should use the root server from the > file root.key -> 131.130.200.227 > Sometimes drill starts with this root hint and switches to the local > resolvers after some time. Sometimes drill even starts with the local > resolver. > > tshark trace of what drill is doing: > > 9.083159 83.136.32.148 -> 83.136.32.189 DNS Standard query NS > 9.083490 83.136.32.189 -> 83.136.32.148 DNS Standard query response NS > i.root-servers.net NS l.root-servers.net NS m.root-servers.net NS > c.root-servers.net NS g.root-servers.net NS h.root-servers.net NS > a.root-servers.net NS b.root-servers.net NS d.root-servers.net NS > f.root-servers.net NS e.root-servers.net NS j.root-servers.net NS > k.root-servers.net RRSIG > 9.083734 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA > l.root-servers.net > 9.124785 83.136.32.189 -> 83.136.32.148 DNS Standard query response > AAAA 2001:500:3::42 > 9.124911 83.136.32.148 -> 83.136.32.190 DNS Standard query A > l.root-servers.net > 9.125700 83.136.32.190 -> 83.136.32.148 DNS Standard query response A > 199.7.83.42 > 9.125948 83.136.32.148 -> 131.130.200.227 DNS Standard query AAAA > b.root-servers.net > 9.127723 131.130.200.227 -> 83.136.32.148 DNS Standard query response, > No such name > 9.127796 83.136.32.148 -> 83.136.32.189 DNS Standard query A > b.root-servers.net > 9.166865 83.136.32.189 -> 83.136.32.148 DNS Standard query response A > 192.228.79.201 > 9.167098 83.136.32.148 -> 131.130.200.227 DNS Standard query AAAA > f.root-servers.net > 9.168655 131.130.200.227 -> 83.136.32.148 DNS Standard query response, > No such name > 9.168721 83.136.32.148 -> 131.130.200.227 DNS Standard query A > f.root-servers.net > 9.170164 131.130.200.227 -> 83.136.32.148 DNS Standard query response, > No such name > 9.170352 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA > f.root-servers.net > 9.283713 83.136.32.189 -> 83.136.32.148 DNS Standard query response > AAAA 2001:500:2f::f > 9.283908 83.136.32.148 -> 83.136.32.189 DNS Standard query A > f.root-servers.net > 9.310273 83.136.32.189 -> 83.136.32.148 DNS Standard query response A > 192.5.5.241 > 9.310579 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA > j.root-servers.net > 9.310838 83.136.32.189 -> 83.136.32.148 DNS Standard query response > AAAA 2001:503:c27::2:30 > 9.310922 83.136.32.148 -> 83.136.32.189 DNS Standard query A > j.root-servers.net > 9.493322 83.136.32.189 -> 83.136.32.148 DNS Standard query response A > 192.58.128.30 > 9.493618 83.136.32.148 -> 83.136.32.190 DNS Standard query AAAA > k.root-servers.net > 9.494389 83.136.32.190 -> 83.136.32.148 DNS Standard query response > AAAA 2001:7fd::1 > 9.494461 83.136.32.148 -> 83.136.32.190 DNS Standard query A > k.root-servers.net > 9.495215 83.136.32.190 -> 83.136.32.148 DNS Standard query response A > 193.0.14.129 > 9.495403 83.136.32.148 -> 192.5.5.241 DNS Standard query DNSKEY > 9.678349 192.5.5.241 -> 83.136.32.148 DNS Standard query response > DNSKEY DNSKEY RRSIG > 9.681066 83.136.32.148 -> 128.63.2.53 DNS Standard query DS at > 9.786338 128.63.2.53 -> 83.136.32.148 DNS Standard query response > 9.786711 83.136.32.148 -> 192.58.128.30 DNS Standard query DNSKEY > ftp.radiopannen.at > 9.811558 192.58.128.30 -> 83.136.32.148 DNS Standard query response > 9.811801 83.136.32.148 -> 198.41.0.4 DNS Standard query DS at > 9.851583 198.41.0.4 -> 83.136.32.148 DNS Standard query response > 9.852179 2a02:850:1:1:216:3eff:fe4f:69b7 -> 2001:503:c27::2:30 DNS > Standard query NS at > 10.034797 2001:503:c27::2:30 -> 2a02:850:1:1:216:3eff:fe4f:69b7 DNS > Standard query response > 10.035221 83.136.32.148 -> 193.171.255.2 DNS Standard query DNSKEY at > 10.035966 193.171.255.2 -> 83.136.32.148 DNS Standard query response > 10.036100 83.136.32.148 -> 194.0.10.100 DNS Standard query DS > radiopannen.at > 10.043381 194.0.10.100 -> 83.136.32.148 DNS Standard query response > 10.043501 83.136.32.148 -> 194.146.106.50 DNS Standard query DNSKEY > ftp.radiopannen.at > 10.044135 194.146.106.50 -> 83.136.32.148 DNS Standard query response > 10.044261 83.136.32.148 -> 81.91.161.98 DNS Standard query DS > radiopannen.at > 10.075231 81.91.161.98 -> 83.136.32.148 DNS Standard query response > 10.075433 83.136.32.148 -> 87.233.175.130 DNS Standard query NS > radiopannen.at > 10.113906 87.233.175.130 -> 83.136.32.148 DNS Standard query response > 10.114454 83.136.32.148 -> 195.66.241.82 DNS Standard query AAAA > ns1.world4you.at > 10.161133 195.66.241.82 -> 83.136.32.148 DNS Standard query response > 10.161262 83.136.32.148 -> 81.91.161.98 DNS Standard query A > ns1.world4you.at > 10.192491 81.91.161.98 -> 83.136.32.148 DNS Standard query response > 10.192877 83.136.32.148 -> 83.136.32.190 DNS Standard query AAAA > ns1.world4you.at > 10.198029 83.136.32.190 -> 83.136.32.148 DNS Standard query response > 10.198162 83.136.32.148 -> 83.136.32.190 DNS Standard query A > ns1.world4you.at > 10.202997 83.136.32.190 -> 83.136.32.148 DNS Standard query response A > 81.19.145.5 > 10.203281 83.136.32.148 -> 81.91.161.98 DNS Standard query AAAA > ns2.world4you.at > 10.234486 81.91.161.98 -> 83.136.32.148 DNS Standard query response > 10.234605 83.136.32.148 -> 87.233.175.130 DNS Standard query A > ns2.world4you.at > 10.272834 87.233.175.130 -> 83.136.32.148 DNS Standard query response > 10.273105 83.136.32.148 -> 83.136.32.190 DNS Standard query AAAA > ns2.world4you.at > 10.278093 83.136.32.190 -> 83.136.32.148 DNS Standard query response > AAAA 2a00:1a68:80a1::d02 > 10.278194 83.136.32.148 -> 83.136.32.189 DNS Standard query A > ns2.world4you.at > 10.278469 83.136.32.189 -> 83.136.32.148 DNS Standard query response A > 81.19.147.5 > 10.278610 83.136.32.148 -> 81.19.147.5 DNS Standard query DNSKEY > radiopannen.at > 10.279060 81.19.147.5 -> 83.136.32.148 DNS Standard query response > 10.279200 83.136.32.148 -> 81.19.147.5 DNS Standard query DS > ftp.radiopannen.at > 10.279666 81.19.147.5 -> 83.136.32.148 DNS Standard query response > 10.279775 83.136.32.148 -> 81.19.145.5 DNS Standard query DNSKEY > ftp.radiopannen.at > 10.283634 81.19.145.5 -> 83.136.32.148 DNS Standard query response > 10.283763 2a02:850:1:1:216:3eff:fe4f:69b7 -> 2a00:1a68:80a1::d02 DNS > Standard query DS ftp.radiopannen.at > 10.284272 2a00:1a68:80a1::d02 -> 2a02:850:1:1:216:3eff:fe4f:69b7 DNS > Standard query response > 10.284411 83.136.32.148 -> 81.19.147.5 DNS Standard query NS > ftp.radiopannen.at > 10.284904 81.19.147.5 -> 83.136.32.148 DNS Standard query response > 10.285017 83.136.32.148 -> 81.19.145.5 DNS Standard query DNSKEY > ftp.radiopannen.at > 10.288602 81.19.145.5 -> 83.136.32.148 DNS Standard query response > 10.288772 83.136.32.148 -> 81.19.147.5 DNS Standard query A > ftp.radiopannen.at > 10.289195 81.19.147.5 -> 83.136.32.148 DNS Standard query response A > 81.19.145.146 > 32.987231 83.136.32.148 -> 83.136.32.189 DNS Standard query A gucci > 32.987242 83.136.32.148 -> 83.136.32.189 DNS Standard query A gucci > 32.987246 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA gucci > 32.987278 83.136.32.148 -> 83.136.32.189 DNS Standard query AAAA gucci > 32.989809 83.136.32.189 -> 83.136.32.148 DNS Standard query response, > No such name > 32.989845 83.136.32.189 -> 83.136.32.148 DNS Standard query response, > No such name > 33.028541 83.136.32.189 -> 83.136.32.148 DNS Standard query response, > No such name > 33.028576 83.136.32.189 -> 83.136.32.148 DNS Standard query response, > No such name > > > > regards > Klaus > > > > > > > > > > > Am 18.05.2011 11:34, schrieb Willem Toorop: >> Hi Klaus, >> >> I've not been able to reproduce this. What does your query look like >> exactly? Do you use a trace (-T)? >> >> With me it doesn't even query the local resolver when I don't use the -r >> option (because of the hard-coded root-servers). >> >> Best regards, Willem >> >> On 04/27/11 15:25, Klaus Darilion wrote: >>> Hi! >> >>> I experienced strange problems with drill 1.6.6 and 1.6.9. Although I >>> specify root servers with -r, sometimes (50% chance) the local >>> configured resolver is asked for a root-server list. With drill 1.6.4 >>> this random behavior was not seen yet. >> >>> Are there any known issues? >> >>> Thanks >>> Klaus >>> _______________________________________________ >>> 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 > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN08UFAAoJEOX4+CEvd6SYyckP/jdrwSGWVHPEC+AvKl9tp1Xp 7+PF4ntvVODhwEUvpQq/9DYv6PC92Z1uu0gXYI8pPkRt80/Z81/+TkXuw3B7oG5l XpZ+WbwasUcEg4uvaz+pnXSUeDI9P1dFxLvbPwLoXz1fPuwK5XF+TbLrq/Lq9pJx V7iZPMsaRXThkdFQTfEbGgRDuNq61PwnSasGH5xAXWVEEdGbasuKDzE1cyVD7OBC 6A0f0wpeSRI6U7sTAPTxv/OA6WIS3vl/ZA9+yraqcHUH//W6XL2F0ObeL6YSYZ6p qPikAfevFza7GEWMvZ1k2N+rOX1bNlYUJWBHo8AX2W1BqqffbD4oflpspTht344R 4E1Fk9UraohNMdHzLYfx9CBDixC5iVt9HglIHhBstlUEqkCky5JMqCSeS6RBUs/x 5RDfcWaI2qUWwkr1/+qwL2ZiN0YkxfwZbiKAV2ecQ2m0D04dHOndmxM9wX+tNSNk XRkctpjwunNhZyqQtJu/sawQwXGwnycRYfAB5QHRsii7m48kmEDfCduU0z7ZHWPu E7dTiNxzK2haxXHZ3Q4wnOVTCSt6bGS1HU9fSDxtTKwfzzFGIv0PhmWWxc+7jqJB e2t0AVtnvmbhamoLZHV1KKBrfLuRgoXLcqitaOYLWaCMAMbtOPRQD8tAbhjnI4zc 5KJRuToxqgIBgeVmicBQ =CkUF -----END PGP SIGNATURE----- From mje at posix.co.za Thu May 19 15:23:39 2011 From: mje at posix.co.za (Mark Elkins) Date: Thu, 19 May 2011 17:23:39 +0200 Subject: [ldns-users] Update request for ldns-key2ds Message-ID: <1305818619.15999.535.camel@mje99.posix.co.za> Hi everyone. I have an update request for the example program "ldns-key2ds". Right now - it works in a similar fashion to the BIND equivalent - in that it only reads DNSKEYs from a file off the file system. I have a need to allow it to read its stdin - allows me to skip creating temporary files.... I edited the sample and my very simple diff looks like.... # diff ldns-key2ds.c ldns-key2dsmje.c 132,133c132,133 < < keyfp = fopen(keyname, "r"); --- > if(strncmp(keyname,"stdin",5) == 0) keyfp=stdin; > else keyfp = fopen(keyname, "r"); ie - if the 'file' to read from is 'stdin' then use 'sdtin' otherwise open the given file for reading... and the whole wrapper thingie leaves me weak at the knees. ie - the code change was easy - but if I try and move the resultant program -it all breaks.... The crux of the matter is I've been unable to work out the algorithm from the RFC's on how to code the creation of DS records in Python (or better still in PHP....) so am left with calling an external program (hint hint).. that is - given a KSK DNSKEY - how to correctly calculate the appropriate DS records... :-) So currently - my very fragile coding works.... just - so fragile. -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6696 bytes Desc: not available URL: From miek at miek.nl Thu May 19 17:18:17 2011 From: miek at miek.nl (Miek Gieben) Date: Thu, 19 May 2011 19:18:17 +0200 Subject: [ldns-users] Update request for ldns-key2ds In-Reply-To: <1305818619.15999.535.camel@mje99.posix.co.za> References: <1305818619.15999.535.camel@mje99.posix.co.za> Message-ID: <20110519171817.GA20451@miek.nl> [ Quoting Mark Elkins at 17:23 on May 19 in "[ldns-users] Update request for ldn"... ] > I edited the sample and my very simple diff looks like.... Just use /dev/stdin much more easy. grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From ondrej at sury.org Thu May 19 17:09:18 2011 From: ondrej at sury.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 19 May 2011 19:09:18 +0200 Subject: [ldns-users] Update request for ldns-key2ds In-Reply-To: <1305818619.15999.535.camel@mje99.posix.co.za> References: <1305818619.15999.535.camel@mje99.posix.co.za> Message-ID: <37812EE3-5D51-4B7F-BF41-65C6F582EEC5@sury.org> Hi Mark, the convention is to use '-' (without quotes) as a identifier for stdin/stdout. Also please use unified diff (diff -urNap is a good default set of diff options). Ottherwise I think your patch looks sane. Ond?ej Sur? On 19.5.2011, at 17:23, Mark Elkins wrote: > Hi everyone. > I have an update request for the example program "ldns-key2ds". Right > now - it works in a similar fashion to the BIND equivalent - in that it > only reads DNSKEYs from a file off the file system. > > I have a need to allow it to read its stdin - allows me to skip creating > temporary files.... > > I edited the sample and my very simple diff looks like.... > > > # diff ldns-key2ds.c ldns-key2dsmje.c > 132,133c132,133 > < > < keyfp = fopen(keyname, "r"); > --- >> if(strncmp(keyname,"stdin",5) == 0) keyfp=stdin; >> else keyfp = fopen(keyname, "r"); > > > ie - if the 'file' to read from is 'stdin' then use 'sdtin' otherwise > open the given file for reading... and the whole wrapper thingie leaves > me weak at the knees. ie - the code change was easy - but if I try and > move the resultant program -it all breaks.... > > The crux of the matter is I've been unable to work out the algorithm > from the RFC's on how to code the creation of DS records in Python (or > better still in PHP....) so am left with calling an external program > (hint hint).. > that is - given a KSK DNSKEY - how to correctly calculate the > appropriate DS records... > > :-) > > So currently - my very fragile coding works.... just - so fragile. > -- > . . ___. .__ Posix Systems - (South) Africa > /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE > / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From mje at posix.co.za Thu May 19 19:22:27 2011 From: mje at posix.co.za (Mark Elkins) Date: Thu, 19 May 2011 21:22:27 +0200 Subject: [ldns-users] Update request for ldns-key2ds In-Reply-To: References: Message-ID: <1305832947.655.32.camel@ilinux.posix.co.za> On Thu, 2011-05-19 at 18:11 +0200, Miek Gieben wrote: Ouch! - and I've only been using Unix for 32 years.... Yes - that works fine. Can anyone help me with the DNSKEY-->DS algorithm - so I can code it in PHP??? > Just use /dev/stdin as the filename > > Mark Elkins wrote: > > >Hi everyone. > >I have an update request for the example program "ldns-key2ds". Right > >now - it works in a similar fashion to the BIND equivalent - in that it > >only reads DNSKEYs from a file off the file system. > > > >I have a need to allow it to read its stdin - allows me to skip creating > >temporary files.... > > > >I edited the sample and my very simple diff looks like.... > > > > > ># diff ldns-key2ds.c ldns-key2dsmje.c > >132,133c132,133 > >< > >< keyfp = fopen(keyname, "r"); > >--- > >> if(strncmp(keyname,"stdin",5) == 0) keyfp=stdin; > >> else keyfp = fopen(keyname, "r"); > > > > > >ie - if the 'file' to read from is 'stdin' then use 'sdtin' otherwise > >open the given file for reading... and the whole wrapper thingie leaves > >me weak at the knees. ie - the code change was easy - but if I try and > >move the resultant program -it all breaks.... > > > >The crux of the matter is I've been unable to work out the algorithm > >from the RFC's on how to code the creation of DS records in Python (or > >better still in PHP....) so am left with calling an external program > >(hint hint).. > >that is - given a KSK DNSKEY - how to correctly calculate the > >appropriate DS records... > > > >:-) > > > >So currently - my very fragile coding works.... just - so fragile. -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4490 bytes Desc: not available URL: From henri at asseily.com Fri May 27 08:03:03 2011 From: henri at asseily.com (Henri Asseily) Date: Fri, 27 May 2011 11:03:03 +0300 Subject: [ldns-users] serializing a response Message-ID: <98B2D9CD-A5C1-42C2-B157-4584803704F4@asseily.com> Hello, I'm looking to cache in a persistent data store (for offline use) ldns resolver responses. I'm at this point trying to find the optimal spot in my codebase to do that. My DNS queries involve a lot of data (tens of NAPTR and TXT records, among others) and a lot of post-processing of those into objects. I could serialize at the object level or at the ldns query level before storing in the data store. For code reuse reasons I would prefer not to do direct object mapping into the data store but I might just have to do that. Anyway, my question for this list is if there's an existing deep serialization technique for rr structs, or barring that if there's a way to easily access the original incoming wire buffers that I'd just store as binary data in the data store. Then for deserialization I'd send those buffers to the resolver for it to recreate an rr list. Ideas? Thanks. -- Henri Asseily henri.tel From willem at NLnetLabs.nl Tue May 31 13:26:08 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 31 May 2011 15:26:08 +0200 Subject: [ldns-users] ldns 1.6.10 released Message-ID: <4DE4EC70.3040806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Version 1.6.10 of ldns is now available. Best regards, Willem Toorop link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.10.tar.gz sha1: 7798a32c6f50a4fb7d56ddf772163dc1cb79c1a4 * New example tool added: ldns-gen-zone. * bugfix #359: Serial-arithmetic for the inception and expiration fields of a RRSIG and correctly converting them to broken-out time information. * bugfix #364: Slight performance increase of ldns-verifyzone. * bugfix #367: Fix to allow glue records with the same name as the delegation. * Fix ldns-verifyzone to allow NSEC3-less records for NS rrsets *and* glue when the zone is opt-out. * bugfix #376: Adapt ldns_nsec3_salt, ldns_nsec3_iterations, ldns_nsec3_flags and ldns_nsec3_algorithm to work for NSEC3PARAMS too. * pyldns memory leaks fixed by Bedrich Kosata (at the cost of a bit performance) * Better handling of reference variables in ldns_rr_new_frm_fp_l from pyldns, with a very nice generator function by Bedrich Kosata. * Decoupling of the rdfs in rrs in the python wrappers to enable the python garbage collector by Bedrich Kosata. * bugfix #380: Minimizing effect of discrepancies in sizeof(bool) at build time and when used. * bugfix #383: Fix detection of empty nonterminals of multiple labels. * Fixed the ommission of rrsets in nsec(3)s and rrsigs to all occluded names (in stead of just the ones that contain glue only) and all occluded records on the delegation points (in stead of just the glue). * Clarify the operation of ldns_dnssec_mark_glue and the usage of ldns_dnssec_node_next_nonglue functions in the documentation. * Added function ldns_dnssec_mark_and_get_glue as an real fast alternative for ldns_zone_glue_rr_list. * Fix parse buffer overflow for max length domain names. * Fix Makefile for U in environment, since wrong U is more common than deansification necessity. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5OxvAAoJEOX4+CEvd6SY62AQAJxUgwaoyC3c6rdjqqxMVj2H +5hGfKuMwmzAKNJxjNbhQOZ3f0tKyYcyUAnMjDw0Hgo1rqTJwasmxtgImu6PvUzc jPc82onEoIbsNoCJGVtrLSJwgmNxd3swFhSmjc6wGHH5g4wt+K4k/Ssue6UmSy2s +Jiu4z7RVzmerj6iQsm/OGxq61a9zOJrlbR+D0TOBu++/SPNS2ELvvIno0+VqDvQ kAaQkQzJ8/A8IdP7AhOzdCA1KCUG6MgS3q3vyih4CQKlqwQ8jpmwim6FwAaTQGop flkosKXGVE7XulGHLflcAqj3EXPVmrCGuhTlF4rZCGztseWWY7p02kIzOOdpZ4fu fi4OstaaF557XG9W/iU4H1VUcTzECQGkVP2HM55KPK7aWG0qQ01hKaqJea4dgLqy j0ueU9qUCyr82ExPY738xmmPvWPEYGLrS6/CiHQ4myOuzJInVMM3w5dd39MzMfn2 YOv+fXfQDkqd8M3QNlP93mZojaovOukRiFxL5oDn4BZCZTEdTx497HxMrDyZ4oMK YpydT8Cq7EyuBCVwARFkiZPZp0tzaR7w0s4/ohKHSz5tlxdaz8K0VumU78ztstaZ CBSKhpAQA3wc0s7OoWLEYICLBpMSo/GkVDHea7Ylfah+thrDIiEKlnmjAmulCPXX t+SabjqO3jJBmRorV4cx =ayyv -----END PGP SIGNATURE-----