From peter.van.dijk at netherlabs.nl Fri Mar 2 10:05:37 2012 From: peter.van.dijk at netherlabs.nl (Peter van Dijk) Date: Fri, 2 Mar 2012 11:05:37 +0100 Subject: [ldns-users] ldns-signzone -p generates invalid NSEC3PARAM Message-ID: Hello, ldns-signzone currently sets flags=1 in NSEC3PARAM generation, when NSEC3 (the -p flag) is enabled. The issue is that RFC5155 does not count bits in the same direction as ldns_set_bit. This patch is one way of fixing it; another could be to change ldns_set_bit (it is not used in that many places). diff --git a/dnssec_sign.c b/dnssec_sign.c index 1d283bc..6c27682 100644 --- a/dnssec_sign.c +++ b/dnssec_sign.c @@ -1280,7 +1280,7 @@ ldns_dnssec_zone_sign_nsec3_flg_mkmap(ldns_dnssec_zone *zone, salt); /* always set bit 7 of the flags to zero, according to * rfc5155 section 11 */ - ldns_set_bit(ldns_rdf_data(ldns_rr_rdf(nsec3param, 1)), 7, 0); + ldns_set_bit(ldns_rdf_data(ldns_rr_rdf(nsec3param, 1)), 0, 0); result = ldns_dnssec_zone_add_rr(zone, nsec3param); if (result != LDNS_STATUS_OK) { return result; Kind regards, Peter van Dijk From peter.van.dijk at netherlabs.nl Fri Mar 2 10:28:25 2012 From: peter.van.dijk at netherlabs.nl (Peter van Dijk) Date: Fri, 2 Mar 2012 11:28:25 +0100 Subject: [ldns-users] ldns-signzone -p generates invalid NSEC3PARAM In-Reply-To: References: Message-ID: Hi, On Mar 2, 2012, at 11:05 , Peter van Dijk wrote: > Hello, > > ldns-signzone currently sets flags=1 in NSEC3PARAM generation, when NSEC3 (the -p flag) is enabled. when NSEC3 *opt-out* is enabled, of course. Kind regards, Peter van Dijk From Willem at NLnetLabs.nl Fri Mar 2 12:46:48 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Fri, 02 Mar 2012 13:46:48 +0100 Subject: [ldns-users] ldns-signzone -p generates invalid NSEC3PARAM In-Reply-To: References: Message-ID: <4F50C138.6030303@NLnetLabs.nl> Absolutely! Thanks for finding this bug. Committed in the subversion trunk. -- Willem Op 02-03-12 11:05, Peter van Dijk schreef: > Hello, > > ldns-signzone currently sets flags=1 in NSEC3PARAM generation, when NSEC3 (the -p flag) is enabled. > The issue is that RFC5155 does not count bits in the same direction as ldns_set_bit. > > This patch is one way of fixing it; another could be to change ldns_set_bit (it is not used in that many places). > > diff --git a/dnssec_sign.c b/dnssec_sign.c > index 1d283bc..6c27682 100644 > --- a/dnssec_sign.c > +++ b/dnssec_sign.c > @@ -1280,7 +1280,7 @@ ldns_dnssec_zone_sign_nsec3_flg_mkmap(ldns_dnssec_zone *zone, > salt); > /* always set bit 7 of the flags to zero, according to > * rfc5155 section 11 */ > - ldns_set_bit(ldns_rdf_data(ldns_rr_rdf(nsec3param, 1)), 7, 0); > + ldns_set_bit(ldns_rdf_data(ldns_rr_rdf(nsec3param, 1)), 0, 0); > result = ldns_dnssec_zone_add_rr(zone, nsec3param); > if (result != LDNS_STATUS_OK) { > return result; > > > Kind regards, > Peter van Dijk > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From rguadagn at hsr.ch Wed Mar 7 16:08:21 2012 From: rguadagn at hsr.ch (rguadagn at hsr.ch) Date: Wed, 7 Mar 2012 16:08:21 +0000 Subject: [ldns-users] Caching of DNSKEY/DS RRs for trust chain validation Message-ID: <5C7CC292B6422E4EAB9FC2C3573F74EE11B8D033@SID00203.hsr.ch> Hello, I'm using the ldns function "ldns_verify_trusted" to verify the Resource Records I get. As I noticed all Resource Records which form the trust chain are fetched again and again (through a call to "ldns_fetch_valid_domain_keys_time") each time I call the function "ldns_verfiy_trusted". Is there any caching mechanism in the library which caches DNSKEY/DS Resource Records which have already been validated to speed up the verification process? Thanks Reto From Willem at NLnetLabs.nl Thu Mar 8 09:00:04 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Thu, 08 Mar 2012 10:00:04 +0100 Subject: [ldns-users] Caching of DNSKEY/DS RRs for trust chain validation In-Reply-To: <5C7CC292B6422E4EAB9FC2C3573F74EE11B8D033@SID00203.hsr.ch> References: <5C7CC292B6422E4EAB9FC2C3573F74EE11B8D033@SID00203.hsr.ch> Message-ID: <4F587514.2010800@NLnetLabs.nl> Hi Reto, Proper caching is not an ambition of ldns; At NLnet Labs we also distribute a resolver library that does just that: libunbound. I suggest you to have a look at it. See: http://unbound.net/documentation/libunbound.html and: http://unbound.net/documentation/libunbound-tutorial-1.html Good luck, -- Willem Op 07-03-12 17:08, rguadagn at hsr.ch schreef: > Hello, > > I'm using the ldns function "ldns_verify_trusted" to verify the Resource Records I get. > As I noticed all Resource Records which form the trust chain are fetched again and again (through a call to "ldns_fetch_valid_domain_keys_time") each time I call the function "ldns_verfiy_trusted". > > Is there any caching mechanism in the library which caches DNSKEY/DS Resource Records which have already been validated to speed up the verification process? > > > Thanks > > Reto > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From edwardfjellskaal at gmail.com Sat Mar 17 07:53:52 2012 From: edwardfjellskaal at gmail.com (=?ISO-8859-1?Q?Edward_Fjellsk=E5l?=) Date: Sat, 17 Mar 2012 08:53:52 +0100 Subject: [ldns-users] How to get CLASS from RDF... Message-ID: <4F644310.8060107@gmail.com> Hi, Im working on a sniffer that collects dns info passivly [1]. Im trying to record nxdomains atm, and from the logic of ldns code, I would assume that there was a function like: ldns_rdf_class ldns_rdf_get_class(const ldns_rdf *rd) { assert(rd != NULL); return rd->_class; } (which is not there) Im recording only the answers from the server, so thats the payload Im looking at. I cant seem to find a good way of extracting this with the ldns library :/ Any pointers would be nice :) If not, I will just have to make my own class parser :) from the ldns_struct_rdf/ldns_rdf _data. Thanks :) Edward [1] https://github.com/gamelinux/passivedns From miek at miek.nl Sat Mar 17 09:29:09 2012 From: miek at miek.nl (Miek Gieben) Date: Sat, 17 Mar 2012 10:29:09 +0100 Subject: [ldns-users] How to get CLASS from RDF... In-Reply-To: <4F644310.8060107@gmail.com> References: <4F644310.8060107@gmail.com> Message-ID: <20120317092909.GA20986@miek.nl> [ Quoting at 08:53 on Mar 17 in "[ldns-users] How to ..." ] > Hi, > > Im working on a sniffer that collects dns info passivly [1]. > > Im trying to record nxdomains atm, and from the logic of ldns code, > I would assume that there was a function like: > > ldns_rdf_class > ldns_rdf_get_class(const ldns_rdf *rd) > { > assert(rd != NULL); > return rd->_class; > } > > (which is not there) rdfs describe the rdata, as such they don't have a class. The class in only there at the RR level. Maybe a ldns_rr_class()-like function is more what you need? 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 edwardfjellskaal at gmail.com Sat Mar 17 11:14:49 2012 From: edwardfjellskaal at gmail.com (=?ISO-8859-1?Q?Edward_Fjellsk=E5l?=) Date: Sat, 17 Mar 2012 12:14:49 +0100 Subject: [ldns-users] How to get CLASS from RDF... In-Reply-To: <20120317092909.GA20986@miek.nl> References: <4F644310.8060107@gmail.com> <20120317092909.GA20986@miek.nl> Message-ID: <4F647229.9090309@gmail.com> On 03/17/2012 10:29 AM, Miek Gieben wrote: > [ Quoting at 08:53 on Mar 17 in "[ldns-users] How to ..." ] >> Hi, >> >> Im working on a sniffer that collects dns info passivly [1]. >> >> Im trying to record nxdomains atm, and from the logic of ldns code, >> I would assume that there was a function like: >> >> ldns_rdf_class >> ldns_rdf_get_class(const ldns_rdf *rd) >> { >> assert(rd != NULL); >> return rd->_class; >> } >> >> (which is not there) > > rdfs describe the rdata, as such they don't have a class. The class > in only there at the RR level. Maybe a ldns_rr_class()-like function > is more what you need? Thanks for the pointer :) Problem solved! E > grtz Miek > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From edwardfjellskaal at gmail.com Sun Mar 18 09:07:43 2012 From: edwardfjellskaal at gmail.com (=?ISO-8859-1?Q?Edward_Fjellsk=E5l?=) Date: Sun, 18 Mar 2012 10:07:43 +0100 Subject: [ldns-users] qualifying a dns packet before processing Message-ID: <4F65A5DF.10206@gmail.com> Hi again list :) So, I parse dns packets, and today I use ldns_wire2pkt to determine if I should go on or not, like: -----8<----- status = ldns_wire2pkt(&decoded_dns,payload, payload_length); if (status != LDNS_STATUS_OK) { debug_log("[D] ldns_wire2pkt status = %d\n", status); return; } -----8<----- But some packets processed give me: *** stack smashing detected *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x2622d0] /lib/tls/i686/cmov/libc.so.6(+0xe227a)[0x26227a] /usr/lib/libldns.so.1(+0x37204)[0xf16204] /usr/lib/libldns.so.1(ldns_wire2dname+0x253)[0xef5b23] /usr/lib/libldns.so.1(ldns_wire2rr+0x49)[0xef5db9] /usr/lib/libldns.so.1(ldns_wire2pkt+0x239)[0xef6119] Are there any other good way to do pre-qualifying of incoming data, so it might make popping my stack a bit harder with lib ldns ? great lib btw :) E From Willem at NLnetLabs.nl Sun Mar 18 11:27:28 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Sun, 18 Mar 2012 12:27:28 +0100 Subject: [ldns-users] qualifying a dns packet before processing In-Reply-To: <4F65A5DF.10206@gmail.com> References: <4F65A5DF.10206@gmail.com> Message-ID: <4F65C6A0.5050202@NLnetLabs.nl> Hi Edward, I agree ldns_wire2pkt shouldn't be able to crash like this. Even when the input data would be garbage (provided playload_length doesn't exceed the memory for the data of course). Can you reproduce the error? Could you file a bug report here: https://www.nlnetlabs.nl/bugs-script/enter_bug.cgi?product=ldns Thanks! -- Willem Op 18-03-12 10:07, Edward Fjellsk?l schreef: > Hi again list :) > > So, I parse dns packets, and today I use ldns_wire2pkt to determine > if I should go on or not, like: > > -----8<----- > status = ldns_wire2pkt(&decoded_dns,payload, payload_length); > > if (status != LDNS_STATUS_OK) { > debug_log("[D] ldns_wire2pkt status = %d\n", status); > return; > } > -----8<----- > > But some packets processed give me: > > *** stack smashing detected *** > ======= Backtrace: ========= > /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x2622d0] > /lib/tls/i686/cmov/libc.so.6(+0xe227a)[0x26227a] > /usr/lib/libldns.so.1(+0x37204)[0xf16204] > /usr/lib/libldns.so.1(ldns_wire2dname+0x253)[0xef5b23] > /usr/lib/libldns.so.1(ldns_wire2rr+0x49)[0xef5db9] > /usr/lib/libldns.so.1(ldns_wire2pkt+0x239)[0xef6119] > > > Are there any other good way to do pre-qualifying of incoming data, > so it might make popping my stack a bit harder with lib ldns ? > > great lib btw :) > > E > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From edwardfjellskaal at gmail.com Sun Mar 18 12:33:43 2012 From: edwardfjellskaal at gmail.com (=?ISO-8859-1?Q?Edward_Fjellsk=E5l?=) Date: Sun, 18 Mar 2012 13:33:43 +0100 Subject: [ldns-users] qualifying a dns packet before processing In-Reply-To: <4F65C6A0.5050202@NLnetLabs.nl> References: <4F65A5DF.10206@gmail.com> <4F65C6A0.5050202@NLnetLabs.nl> Message-ID: <4F65D627.90904@gmail.com> On 03/18/2012 12:27 PM, Willem Toorop wrote: > Hi Edward, > > I agree ldns_wire2pkt shouldn't be able to crash like this. Even when > the input data would be garbage (provided playload_length doesn't exceed > the memory for the data of course). Can you reproduce the error? Could > you file a bug report here: > > https://www.nlnetlabs.nl/bugs-script/enter_bug.cgi?product=ldns > > Thanks! > > -- Willem Hi Willem, I have located the session (and packet) I have in my test pcap that crashes ldns_wire2pkt. It is actually a pop3 (port 110) traffic. I noticed this as I forgot to put a proper BPF on my libpcap, but I would not want anyone to craft such a package :) Its also TCP over IPv4. Do I need to add an bugzilla account to report a bug ? And will the bug be public ? Regarding reproducing and stacksmashing other libldns apps :) I tested with printing out the calculated length of the payload vs the payload length that tcpdump reports, both are 1308. For processing DNS over TCP, I do like this: status = ldns_wire2pkt(&decoded_dns,payload + 2, payloadlength - 2); (Correct me if thats way off :) As from what I can read, the first two bytes tells us something about how much data to expect, and are not in the normal DNS header. I can probably send the one packet that causes this off list (pcap). E > > Op 18-03-12 10:07, Edward Fjellsk?l schreef: >> Hi again list :) >> >> So, I parse dns packets, and today I use ldns_wire2pkt to determine >> if I should go on or not, like: >> >> -----8<----- >> status = ldns_wire2pkt(&decoded_dns,payload, payload_length); >> >> if (status != LDNS_STATUS_OK) { >> debug_log("[D] ldns_wire2pkt status = %d\n", status); >> return; >> } >> -----8<----- >> >> But some packets processed give me: >> >> *** stack smashing detected *** >> ======= Backtrace: ========= >> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x2622d0] >> /lib/tls/i686/cmov/libc.so.6(+0xe227a)[0x26227a] >> /usr/lib/libldns.so.1(+0x37204)[0xf16204] >> /usr/lib/libldns.so.1(ldns_wire2dname+0x253)[0xef5b23] >> /usr/lib/libldns.so.1(ldns_wire2rr+0x49)[0xef5db9] >> /usr/lib/libldns.so.1(ldns_wire2pkt+0x239)[0xef6119] >> >> >> Are there any other good way to do pre-qualifying of incoming data, >> so it might make popping my stack a bit harder with lib ldns ? >> >> great lib btw :) >> >> E >> _______________________________________________ >> 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 Mon Mar 19 21:11:02 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 19 Mar 2012 22:11:02 +0100 Subject: [ldns-users] qualifying a dns packet before processing In-Reply-To: <4F65D627.90904@gmail.com> References: <4F65A5DF.10206@gmail.com> <4F65C6A0.5050202@NLnetLabs.nl> <4F65D627.90904@gmail.com> Message-ID: <4F67A0E6.7030408@NLnetLabs.nl> Hi Edward, Op 18-03-12 13:33, Edward Fjellsk?l schreef: > I can probably send the one packet that causes this off list (pcap). Thanks for sending the packet off list and giving information on the version you use. The issue is resolved in ldns-1.6.4 and higher. The bug report leading to the fix: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=292 Cheers, -- Willem