From erik.ostlyngen at uninett.no Fri Jan 11 12:08:08 2013 From: erik.ostlyngen at uninett.no (Erik P. Ostlyngen) Date: Fri, 11 Jan 2013 13:08:08 +0100 Subject: [ldns-users] perl wrapper for ldns Message-ID: <50F000A8.7090608@uninett.no> Hi, I'm thinking of writing a perl xs wrapper for the ldns library because I want to learn more about perl xs wrappers and because it could be useful. Do any of you know if this has already been done? Regards, Erik ?stlyngen From marco.davids at sidn.nl Fri Jan 11 12:57:55 2013 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Fri, 11 Jan 2013 13:57:55 +0100 Subject: [ldns-users] perl wrapper for ldns In-Reply-To: <50F000A8.7090608@uninett.no> References: <50F000A8.7090608@uninett.no> Message-ID: <50F00C53.8080504@sidn.nl> Hi Erik, On 01/11/13 13:08, Erik P. Ostlyngen wrote: > I'm thinking of writing a perl xs wrapper for the ldns library because > I want to learn more about perl xs wrappers and because it could be > useful. Do any of you know if this has already been done? You may be interested in (contributing to) Perl::Net::DNS. http://www.net-dns.org/ -- Marco From mk at npulsetech.com Wed Jan 16 15:24:54 2013 From: mk at npulsetech.com (Matthew Keeler) Date: Wed, 16 Jan 2013 10:24:54 -0500 Subject: [ldns-users] ldns memory management Message-ID: I have a question which I have not been able to answer by reading through the documentation. There are many methods such as lens_pkt_all, lens_rr_list_pop_rr or lens_rr_owner etc.. These methods return pointers to ldns structures. 1) Are the pointers to copies of the data? 2) Should the respective _free functions be called on them once finished and if so will a subsequent call to the function still return data? In general if I make a call to ldns_pkt_all it returns a list of rrs. I loop over it and pop the rrs. When I am done processing the rr should I free it as I don't think it is associated with the list. If I do free them, what happens if I call ldns_pkt_all again in another part of the code? Is the actual underlying data still there? Thanks Matt Keeler -------------------------------------------------------------------- The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's organization for planning purposes only. Further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang.nagele at ausregistry.com.au Thu Jan 17 08:54:05 2013 From: wolfgang.nagele at ausregistry.com.au (Wolfgang Nagele) Date: Thu, 17 Jan 2013 19:54:05 +1100 Subject: [ldns-users] Resolver to use TCP if UDP > bufsize Message-ID: <1F8B8C7F-9336-4F5A-A3A7-9016FAB6F7DF@ausregistry.com.au> Hi all, I have a case where we are sending large DNS packets that exceed 4096 bytes using 'ldns_resolver_send_pkt()'. I noticed that it will not realize that it exceeds the UDP bufsize and fallback to TCP but rather sends the message using UDP which will result in a FORMERR from BIND. As far as I can see in the code there is no way in the resolver to make it behave this way. Am I missing something? At this point I have implemented a check in our code that will set 'usevc()' for packets that exceed the bufsize. That brings me to another question - is there no better way to get the size of my packet than this? uint8_t *wire = NULL; size_t size; ldns_pkt2wire(&wire, pkt, &size); LDNS_FREE(wire); Cheers, -- Wolfgang Nagele Senior Systems and Network Administrator AusRegistry Pty Ltd Level 8, 10 Queens Road Melbourne, Victoria, Australia, 3004 Phone +61 3 9090 1756 Email: wolfgang.nagele at ausregistry.com.au Web: www.ausregistry.com.au The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. From willem at nlnetlabs.nl Thu Jan 17 15:39:02 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 17 Jan 2013 16:39:02 +0100 Subject: [ldns-users] ldns memory management In-Reply-To: References: Message-ID: <50F81B16.7000504@nlnetlabs.nl> Hi Matthew, Op 16-01-13 16:24, Matthew Keeler schreef: > I have a question which I have not been able to answer by reading > through the documentation. > > There are many methods such as lens_pkt_all, lens_rr_list_pop_rr or > lens_rr_owner etc.. These methods return pointers to ldns structures. > > 1) Are the pointers to copies of the data? > 2) Should the respective _free functions be called on them once finished > and if so will a subsequent call to the function still return data? - ldns_pkt_all, The documentation states that a new rr_list clone is returned. This means that the list is newly created and must be freed, and every rr in the list is copied (cloned) so they must be freed (with all their data) as well. When after popping some rr's you have a piece of list left you wish to dispose of, you have to use ldns_rr_list_deep_free so that both the list and the rr's (with all their data) are freed. Every call to ldns_pkt_all creates a new rr_list with all rr's cloned from the original question, answer, authority and additional section. - ldns_rr_list_pop_rr, The rr comes directly from the list and is not copied. You inherit the responsibility to free it from the list. When the list came from ldns_pkt_all, it means you inherit the responsibility to free the rr! - ldns_rr_owner, A reference to the rr's owner is returned and should thus not be freed separately. > In general if I make a call to ldns_pkt_all it returns a list of rrs. I > loop over it and pop the rrs. When I am done processing the rr should I > free it as I don't think it is associated with the list. The rr on a ldns_pkt_all list is a clone of the original rr and should be freed. > If I do free > them, what happens if I call ldns_pkt_all again in another part of the > code? Is the actual underlying data still there? Yes, you get a new created list with all rr's cloned. > Thanks > Matt Keeler Welcome, -- Willem PS. I have to admit that in many cases (but perhaps not this one) the details about memory responsibility are missing from the documentation. I usually check the source in such cases to be sure. If you use doxygen documentation (like at http://www.nlnetlabs.nl/projects/ldns/doc/index.html ) you can conveniently follow the link from the documentation to the source. I do think that this information should actually be mentioned with the return value in the documentation. I guess I need to review it some day... From willem at nlnetlabs.nl Thu Jan 17 16:18:27 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 17 Jan 2013 17:18:27 +0100 Subject: [ldns-users] Resolver to use TCP if UDP > bufsize In-Reply-To: <1F8B8C7F-9336-4F5A-A3A7-9016FAB6F7DF@ausregistry.com.au> References: <1F8B8C7F-9336-4F5A-A3A7-9016FAB6F7DF@ausregistry.com.au> Message-ID: <50F82453.7080202@nlnetlabs.nl> Op 17-01-13 09:54, Wolfgang Nagele schreef: > Hi all, > > I have a case where we are sending large DNS packets that exceed 4096 bytes using 'ldns_resolver_send_pkt()'. I noticed that it will not realize that it exceeds the UDP bufsize and fallback to TCP but rather sends the message using UDP which will result in a FORMERR from BIND. Interesting case! In the OPT rr you state the maximum size you are willing to receive (but not what you can send). But, since the bind server does not convey this information... still ldns should be able to sent big (fragmented) udp messages. The ldns_resolver_edns_udp_size can not be used. It is about what message sizes we are willing to receive, not what the other site is willing to receive... I guess you should copy the ldns_resolver_send_pkt function into a my_ldns_resolver_send_pkt and replace ldns_send with my_ldns_send. Which then could look like: my_ldns_send(ldns_pkt **result_packet, ldns_resolver *r, const ldns_pkt *query_pkt) { ldns_buffer *qb; ldns_status result; ldns_rdf *tsig_mac = NULL; bool prev_usevc = ldns_resolver_usevc(r); qb = ldns_buffer_new(LDNS_MIN_BUFLEN); if (query_pkt && ldns_pkt_tsig(query_pkt)) { tsig_mac = ldns_rr_rdf(ldns_pkt_tsig(query_pkt), 3); } if (!query_pkt || ldns_pkt2buffer_wire(qb, query_pkt) != LDNS_STATUS_OK) { result = LDNS_STATUS_ERR; } else { if (ldns_buffer_position(qb) > 4096) { ldns_resolver_set_usevc(true); } result = ldns_send_buffer(result_packet, r, qb, tsig_mac); ldns_resolver_set_usevc(prev_usevc); } ldns_buffer_free(qb); return result; } > At this point I have implemented a check in our code that will set 'usevc()' for packets that exceed the bufsize. That brings me to another question - is there no better way to get the size of my packet than this? No. Except for the method described above :( Cheers, Willem From mk at npulsetech.com Thu Jan 17 15:41:42 2013 From: mk at npulsetech.com (Matthew Keeler) Date: Thu, 17 Jan 2013 10:41:42 -0500 Subject: [ldns-users] ldns memory management In-Reply-To: <50F81B16.7000504@nlnetlabs.nl> References: <50F81B16.7000504@nlnetlabs.nl> Message-ID: Thanks a lot. This is exactly what I was looking for. Matt Keeler On Thu, Jan 17, 2013 at 10:39 AM, Willem Toorop wrote: > Hi Matthew, > > Op 16-01-13 16:24, Matthew Keeler schreef: > > I have a question which I have not been able to answer by reading > > through the documentation. > > > > There are many methods such as lens_pkt_all, lens_rr_list_pop_rr or > > lens_rr_owner etc.. These methods return pointers to ldns structures. > > > > 1) Are the pointers to copies of the data? > > 2) Should the respective _free functions be called on them once finished > > and if so will a subsequent call to the function still return data? > > - ldns_pkt_all, The documentation states that a new rr_list clone > is returned. This means that the list is newly created and must > be freed, and every rr in the list is copied (cloned) so they > must be freed (with all their data) as well. > > When after popping some rr's you have a piece of list left you > wish to dispose of, you have to use ldns_rr_list_deep_free so > that both the list and the rr's (with all their data) are freed. > > Every call to ldns_pkt_all creates a new rr_list with all rr's > cloned from the original question, answer, authority and > additional section. > > - ldns_rr_list_pop_rr, The rr comes directly from the list and is not > copied. You inherit the responsibility to free it from the list. > When the list came from ldns_pkt_all, it means you inherit the > responsibility to free the rr! > > - ldns_rr_owner, A reference to the rr's owner is returned and should > thus not be freed separately. > > > > In general if I make a call to ldns_pkt_all it returns a list of rrs. I > > loop over it and pop the rrs. When I am done processing the rr should I > > free it as I don't think it is associated with the list. > > The rr on a ldns_pkt_all list is a clone of the original rr and should > be freed. > > > If I do free > > them, what happens if I call ldns_pkt_all again in another part of the > > code? Is the actual underlying data still there? > > Yes, you get a new created list with all rr's cloned. > > > Thanks > > Matt Keeler > > Welcome, > > -- Willem > > PS. I have to admit that in many cases (but perhaps not this one) the > details about memory responsibility are missing from the documentation. > I usually check the source in such cases to be sure. If you use doxygen > documentation (like at > http://www.nlnetlabs.nl/projects/ldns/doc/index.html ) you can > conveniently follow the link from the documentation to the source. > > I do think that this information should actually be mentioned with the > return value in the documentation. I guess I need to review it some day... > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > -------------------------------------------------------------------- The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's organization for planning purposes only. Further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leo.Baltus at omroep.nl Thu Jan 31 13:30:58 2013 From: Leo.Baltus at omroep.nl (Leo Baltus) Date: Thu, 31 Jan 2013 14:30:58 +0100 Subject: [ldns-users] ldns --with-drill: cannot find -lcrypto Message-ID: <20130131133057.GA7661@omroep.nl> Hi, I just wanted to compile ldns --with-drill compiling against openssl which I have installed in /compile/openssl-1.0.0j $ ./configure --with-ssl=/compile/openssl-1.0.0j --with-drill $ make ./libtool --tag=CC --quiet --mode=link gcc -I. -I. -DHAVE_CONFIG_H -I/compile/openssl-1.0.0j/include -Wwrite-strings -W -Wall -O2 -g -D_GNU_SOURCE drill/chasetrace.lo drill/dnssec.lo drill/drill.lo drill/drill_util.lo drill/error.lo drill/root.lo drill/securetrace.lo drill/work.lo -lcrypto -ldl -lldns -o drill/drill /usr/bin/ld: cannot find -lcrypto I think that '-I/compile/openssl-1.0.0j/include' should read '-L/compile/openssl-1.0.0j/lib' as it is linking and not compiling at this stage. Attached patch fixes this, however I have not extensively tested this so maybe there is a valid reason to use LIBSSL_CPPFLAGS here. -- Leo Baltus, internetbeheerder /\ NPO ICT Internet Services /NPO/\ Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ servicedesk at omroep.nl, 035-6773555 \/ -------------- next part -------------- --- ldns-1.6.16/Makefile.in.org 2013-01-29 12:46:56.000000000 +0100 +++ ldns-1.6.16/Makefile.in 2013-01-29 12:47:04.000000000 +0100 @@ -95,7 +95,7 @@ LINK_LIB = $(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(LDFLAGS) \ $(LIBS) -version-number $(version_info) -no-undefined LINK_EXE = $(LIBTOOL) --mode=link $(CC) $(CPPFLAGS) \ - $(LIBSSL_CPPFLAGS) $(CFLAGS) $(LDFLAGS) + $(LIBSSL_LDFLAGS) $(CFLAGS) $(LDFLAGS) .PHONY: clean realclean docclean manpages doc lint all lib pyldns test .PHONY: install uninstall install-doc uninstall-doc uninstall-pyldns