From calle at init.se Thu Dec 12 14:01:13 2013 From: calle at init.se (Calle Dybedahl) Date: Thu, 12 Dec 2013 15:01:13 +0100 Subject: [ldns-users] Perl-module using ldns Message-ID: <5D69158A-CDC8-427C-B5B4-2B4909DE56EB@init.se> Hello. We (as in the project I?m involved in at .SE) felt the need for an alternative to the Net::DNS Perl module, and the easiest way to get one turned out to be to write our own based on ldns. It is now feature-complete enough for our current needs, and it?s possible that it may be useful for others. The interface is very similar, but not quite identical, to Net::DNS. You can find it on CPAN under the name Net::LDNS, or on github at https://github.com/dotse/net-ldns As of now, it?s only tested with ldns version 1.6.16. It?s being developed on OSX, regularly used on Ubuntu Server 12.04LTS and occasionally tested on other Debian-derivatives, FreeBSD and OpenBSD. At least in theory, it should be usable on any platform where ldns itself works and which has a /dev/null (that last bit is because we need somewhere to temporarily point STDERR, to silence output from ldns). Feedback on how well (if at all) it works on various platforms as well as wishes for what features to add next are welcome. If you want something done (like support for currently half-supported RR types), the best way is as Github issues. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 From calle at init.se Mon Dec 16 10:43:55 2013 From: calle at init.se (Calle Dybedahl) Date: Mon, 16 Dec 2013 11:43:55 +0100 Subject: [ldns-users] Please remove prints to stderr? Message-ID: If you?re about to make a new release, could you please remove the bits in ldns that print to standard error, or put them behind #ifdefs or something? At least the one in ldns_axfr_next()? It?s very annoying to get the spurious error messages, and we hit that particular one a lot, since we?re testing that nameservers aren?t open for zone transfer from just anybody who asks. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 From willem at nlnetlabs.nl Tue Dec 17 13:45:51 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 17 Dec 2013 14:45:51 +0100 Subject: [ldns-users] Please remove prints to stderr? In-Reply-To: References: Message-ID: <52B0558F.50707@nlnetlabs.nl> op 16-12-13 11:43, Calle Dybedahl schreef: > If you?re about to make a new release, could you please remove the bits in ldns that print to standard error, or put them behind #ifdefs or something? At least the one in ldns_axfr_next()? It?s very annoying to get the spurious error messages, and we hit that particular one a lot, since we?re testing that nameservers aren?t open for zone transfer from just anybody who asks. > OK. Added a --disable-stderr-msgs configure option. -- Willem From willem at nlnetlabs.nl Tue Dec 24 12:07:19 2013 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 24 Dec 2013 13:07:19 +0100 Subject: [ldns-users] ldns SONAME, what shall I do? In-Reply-To: References: <01dd1ba6dc1f42bdbe463ac262b00c9b@SRV04.dikkenberg.local> <3bc0908ddae84b5c981c43b80b0d05cb@SRV07.dikkenberg.local> <51E53FBA.4080101@nlnetlabs.nl> Message-ID: <52B978F7.5060407@nlnetlabs.nl> Hi Ond?ej and other list members, I am about to release the new ldns and I am still not completely sure what to do with the SONAME. Advice and input from you on the ldns-users and the the maintainers would be much appreciated. ldns before version 1.6.14 had a bug (#459) which caused all symbols (including symbols for compatibility support functions) to be visible. The disappearance of one such symbol (strlcpy) caused the OpenDNSSEC build on Debian to break. As a consequence of bug fix #459 the Application Binary Interface (ABI) of ldns had changed. Normally, when the ABI is broken on purpose, the SONAME version is bumped so that builds against the earlier ABI version don't try to link against the current one. Ond?ej worked around the issue by a hard build dependency on ldns >= 1.6.14 for OpenDNSSEC. No other issues involving disappeared symbols seem to have popped up; at least, not that I'm aware of. Now I can release the new ldns with a updated SONAME. In our other dns library, libunbound, this reversioning of the SONAME (not the bug) has been done several times before. It even has a specific versioning scheme for this. My hesitation for doing so is that this will hinder people with a source/build based package management systems the most. People that use ports on FreeBSD and OpenBSD, or pkgsrc on NetBSD. They have to rebuild everything dependent on ldns, and have to be warned to do so manually (via UPDATING file in FreeBSD). This is even more painful because those systems do have strlcpy in their system libraries. For them ldns versions before and after 1.6.14 are completely binary compatible! For them there is absolutely no reason to update the SONAME! Now, if it is all the same to everybody, I'm fine with releasing ldns-1.6.17 that will install libldns.so.1.6.17. But strictly 1.6.14 should have been released as libldns.so.2. How realistic do you think it is that ldns will be updated to 1.6.17 from a version earlier than 1.6.14? In other words, what do you think that should happen? Thanks for your advice and a Happy Christmas :) -- Willem op 17-07-13 08:35, Ond?ej Sur? schreef: > Hi Willem, > > On Tue, Jul 16, 2013 at 2:42 PM, Willem Toorop > wrote: > > Hi Ond?ej, Bas, > > This is unfortunate. > Those symbols disappeared in 1.6.14 when addressing bugfix #459. > (https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=459) > > B.t.w. I cannot reproduce myself. When I compile OpenDNSSEC 1.3.14 or > 1.3.4 with ldns 1.6.11, configure detects the absence of strlcpy and > compiles and links the replacement function via libcompat.a (even though > strlcpy is also available in libldns.so.1 !). This is with gcc 4.6.3. It > would be interesting to see the output of the build process, to see > where it differs. > > > All build logs are here (also my analysis could be just wrong): > > https://launchpad.net/~pkg-opendnssec/+archive/ppa/+builds?build_state=built > > > [...] > Most convenient for me would be to postpone the soname bumping release > (1.7.0) until the end of August (to be on the safe side). Would that be > acceptable for you? It means that the libldns1 package may not be > updated to 1.6.14 or beyond until that time. Alternatively you could > package a patched libldns1 1.6.16 that does export the strlcpy symbol > (nasty). I have attached a patch that does just that. > > > I will just add hard build dependency on ldns >= 1.6.14 and that will > fix the problem. And let's hope it will not pop-out somewhere else. > > Ondrej > -- > ?Ond?ej Sur? > From vladimir.levijev at gmail.com Tue Dec 31 14:50:29 2013 From: vladimir.levijev at gmail.com (Vladimir Levijev) Date: Tue, 31 Dec 2013 16:50:29 +0200 Subject: [ldns-users] Finding out which signatures belong to which RRs Message-ID: Hi, Imagine I'm parsing AUTHORITY section of output of "IN A" request. I get 2 NSEC3 RRs and 2 signatures for each, something like: IN NSEC3 <-- let's call it A IN RRSIG NSEC3 <-- first rrsig of A IN RRSIG NSEC3 <-- second rrsig of A IN NSEC3 <-- let's call it B IN RRSIG NSEC3 <-- first rrsig of B IN RRSIG NSEC3 <-- second rrsig of B So, how can I verify which NSEC3 the signatures belong to? In other words, what do RRs that sign and that are being signed have in common, and which ldns function I could use to get it? Cheers, VL