From jv at fcelda.cz Tue Apr 4 14:28:54 2017 From: jv at fcelda.cz (Jan Vcelak) Date: Tue, 4 Apr 2017 16:28:54 +0200 Subject: [ldns-users] [PATCH 0/2] allocation errors in packet parsing Message-ID: <20170404142856.70953-1-jv@fcelda.cz> Hello, the attached patches fix some issues in ldns_wire2pkt function. I don't exactly remember the circumstance of finding the first problem because the patch has been laying in my repository for a while. But the fix is pretty obvious. The second patch fixes memory leak when parsing malformed packet that contains multiple EDNS records. The old EDNS buffer needs to be deallocated first. (The patches apply cleanly on develop branch.) Regards, Jan Jan Vcelak (2): ldns_wire2pkt: fix null pointer dereference if pkt allocation fails ldns_wire2pkt: fix memory leak with more EDNS sections wire2host.c | 5 +++++ 1 file changed, 5 insertions(+) -- 2.12.2 From jv at fcelda.cz Tue Apr 4 14:28:55 2017 From: jv at fcelda.cz (Jan Vcelak) Date: Tue, 4 Apr 2017 16:28:55 +0200 Subject: [ldns-users] [PATCH 1/2] ldns_wire2pkt: fix null pointer dereference if pkt allocation fails In-Reply-To: <20170404142856.70953-1-jv@fcelda.cz> References: <20170404142856.70953-1-jv@fcelda.cz> Message-ID: <20170404142856.70953-2-jv@fcelda.cz> --- wire2host.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/wire2host.c b/wire2host.c index 680d2f9d..0788e7bc 100644 --- a/wire2host.c +++ b/wire2host.c @@ -412,6 +412,10 @@ ldns_wire2pkt(ldns_pkt **packet_p, const uint8_t *wire, size_t max) uint8_t data[4]; + if (!packet) { + return LDNS_STATUS_MEM_ERR; + } + status = ldns_wire2pkt_hdr(packet, wire, max, &pos); LDNS_STATUS_CHECK_GOTO(status, status_error); -- 2.12.2 From jv at fcelda.cz Tue Apr 4 14:28:56 2017 From: jv at fcelda.cz (Jan Vcelak) Date: Tue, 4 Apr 2017 16:28:56 +0200 Subject: [ldns-users] [PATCH 2/2] ldns_wire2pkt: fix memory leak with more EDNS sections In-Reply-To: <20170404142856.70953-1-jv@fcelda.cz> References: <20170404142856.70953-1-jv@fcelda.cz> Message-ID: <20170404142856.70953-3-jv@fcelda.cz> --- wire2host.c | 1 + 1 file changed, 1 insertion(+) diff --git a/wire2host.c b/wire2host.c index 0788e7bc..a30e89e7 100644 --- a/wire2host.c +++ b/wire2host.c @@ -468,6 +468,7 @@ ldns_wire2pkt(ldns_pkt **packet_p, const uint8_t *wire, size_t max) ldns_pkt_set_edns_z(packet, ldns_read_uint16(&data[2])); /* edns might not have rdfs */ if (ldns_rr_rdf(rr, 0)) { + ldns_rdf_deep_free(ldns_pkt_edns_data(packet)); ldns_pkt_set_edns_data(packet, ldns_rdf_clone(ldns_rr_rdf(rr, 0))); } ldns_rr_free(rr); -- 2.12.2 From wouter at nlnetlabs.nl Tue Apr 4 14:37:49 2017 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 4 Apr 2017 16:37:49 +0200 Subject: [ldns-users] [PATCH 0/2] allocation errors in packet parsing In-Reply-To: <20170404142856.70953-1-jv@fcelda.cz> References: <20170404142856.70953-1-jv@fcelda.cz> Message-ID: <50d168fc-571d-d8d8-32e1-4accd76e3945@nlnetlabs.nl> Hi Jan, Thank you for the fixes. I have applied them to the develop branch. Best regards, Wouter On 04/04/17 16:28, Jan Vcelak wrote: > Hello, > > the attached patches fix some issues in ldns_wire2pkt function. > > I don't exactly remember the circumstance of finding the first problem > because the patch has been laying in my repository for a while. But > the fix is pretty obvious. > > The second patch fixes memory leak when parsing malformed packet that > contains multiple EDNS records. The old EDNS buffer needs to be > deallocated first. > > (The patches apply cleanly on develop branch.) > > Regards, > > Jan > > > Jan Vcelak (2): > ldns_wire2pkt: fix null pointer dereference if pkt allocation fails > ldns_wire2pkt: fix memory leak with more EDNS sections > > wire2host.c | 5 +++++ > 1 file changed, 5 insertions(+) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jv at fcelda.cz Tue Apr 4 17:03:14 2017 From: jv at fcelda.cz (=?UTF-8?B?SmFuIFbEjWVsw6Fr?=) Date: Tue, 4 Apr 2017 19:03:14 +0200 Subject: [ldns-users] redefinition of bool, overlap of Z and DO in EDNS Message-ID: Hello ldns developers. I have some more patches for ldns in queue. But first I want to make sure that all the changes make sense and that I'm not making your job difficult. Is the repository on GitHub [1] supported and open for pull requests? It seems a bit behind the official one [2]. It's easier for me to send contribution via pull request than via e-mail. I also just noticed that all tags disappeared from the official repository. Please, can you check? We have been using ldns in C++ but hit the problem that ldns redefines default bool type in common.h [3]. That breaks some constexpr definitions which involve boolean types and follow that include. Ugly workaround is to include ldns.h and then undefine true, false, and bool. Does the code still make sense today? Can I just update the macro conditions to include stdbool.h with C and do nothing with C++? And the last thing: The ldns_pkt_set_edns_z() function clears the DO flag. This looks intentional. But the only way to clear all but DO flag in EDNS (if I want to use ldns API) is to read the DO flag, use the function above the clear all flags, and set DO to its original value. This is confusing as EDNS(0) RFC [4] shows Z and DO as separate fields. I was thinking about changing getter/setter function for Z to exclude DO flag. Does it make sense or do you suggest different solution? [1] https://github.com/NLnetLabs/ldns [2] https://git.nlnetlabs.nl/ldns/ [3] https://github.com/NLnetLabs/ldns/blob/release-1.7.0/ldns/common.h.in#L40-L56 [4] https://tools.ietf.org/html/rfc6891#section-6.1.3 Regards, Jan From willem at nlnetlabs.nl Thu Apr 6 07:06:33 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 6 Apr 2017 09:06:33 +0200 Subject: [ldns-users] redefinition of bool, overlap of Z and DO in EDNS In-Reply-To: References: Message-ID: Op 04-04-17 om 19:03 schreef Jan V?el?k: > Hello ldns developers. > > I have some more patches for ldns in queue. But first I want to make > sure that all the changes make sense and that I'm not making your job > difficult. Is the repository on GitHub [1] supported and open for pull > requests? It seems a bit behind the official one [2]. It's easier for > me to send contribution via pull request than via e-mail. Hi Jan, I'll take pull requests via github. That is actually slightly easier than applying mailbox patches for me too. > I also just noticed that all tags disappeared from the official > repository. Please, can you check? Yes, something went wrong with the move to a new gitlab instance. They should be back now. > We have been using ldns in C++ but hit the problem that ldns redefines > default bool type in common.h [3]. That breaks some constexpr > definitions which involve boolean types and follow that include. Ugly > workaround is to include ldns.h and then undefine true, false, and > bool. Does the code still make sense today? Can I just update the > macro conditions to include stdbool.h with C and do nothing with C++? Yes that seems more stable than what we have now. Use of stdbool.h in a library is regrettable really. We have had problems before where the type of bool differed during library compile time and library usage. Maybe a more stable but still backwards compatible behavioural mechanism would be to define a DONT_HAVE_STDBOOL_H when the header was not detected during configure..., I'll try to think of something for you to review... > And the last thing: The ldns_pkt_set_edns_z() function clears the DO > flag. This looks intentional. But the only way to clear all but DO > flag in EDNS (if I want to use ldns API) is to read the DO flag, use > the function above the clear all flags, and set DO to its original > value. This is confusing as EDNS(0) RFC [4] shows Z and DO as separate > fields. I was thinking about changing getter/setter function for Z to > exclude DO flag. Does it make sense or do you suggest different > solution? Yes, I am conservative to the extreme with changing behaviour with ldns, sorry. I suggest to update the documentation to make it more clear, and add another getter/setter that only changes the Z bits. -- Willem > > [1] https://github.com/NLnetLabs/ldns > [2] https://git.nlnetlabs.nl/ldns/ > [3] https://github.com/NLnetLabs/ldns/blob/release-1.7.0/ldns/common.h.in#L40-L56 > [4] https://tools.ietf.org/html/rfc6891#section-6.1.3 > > Regards, > > Jan > _______________________________________________ > ldns-users mailing list > ldns-users at nlnetlabs.nl > https://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From willem at nlnetlabs.nl Mon Apr 10 08:08:33 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 10 Apr 2017 10:08:33 +0200 Subject: [ldns-users] ldns-read-zone and $INCLUDE In-Reply-To: <20170323105546.Horde.HJvdPVIVwky7l6X4xDbHII0@andreasschulze.de> References: <20170323105546.Horde.HJvdPVIVwky7l6X4xDbHII0@andreasschulze.de> Message-ID: <6f263997-81ea-be52-2aa3-86a2832295d3@nlnetlabs.nl> Op 23-03-17 om 10:55 schreef A. Schulze: > > Hello, Hi Andreas, > looks like $INCLUDE inside a zone is ignored by ldns-read-zone, right? Yes. > $ cat /path/to/zone: > example.org. SOA ns.example.org. me.example.org 1 43200 7200 2419200 > 3600 > example.org. NS ns.example.org. > ns.example.org. A 192.0.2.53 > $INCLUDE /path/to/include > > $ cat /path/to/include > www.example.org. A 192.0.2.80 > > # read zone, sort and increment SOA by one > $ ldns-read-zone -z -S +1 path/to/zone > example.org. 3600 IN SOA ns.example.org. > me.example.org. 2 43200 7200 2419200 3600 > example.org. 3600 IN NS ns.example.org. > ns.example.org. 3600 IN A 192.0.2.53 > > While NSD handle the include, the included data are lost here. > Is that intentional? Possibly, though I wouldn't know what the reason might have been. Easiest to fix would be to process the $INCLUDE statement while reading the zone. Maintaining the $INCLUDE statement would be a lot harder... Would you like me to address these issues one way or the other? Or both? -- Willem > > Thanks for clarification, > Andreas > > > > _______________________________________________ > ldns-users mailing list > ldns-users at nlnetlabs.nl > https://open.nlnetlabs.nl/mailman/listinfo/ldns-users From willem at nlnetlabs.nl Mon Apr 10 09:18:13 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 10 Apr 2017 11:18:13 +0200 Subject: [ldns-users] ldns-verify-zone and double signature In-Reply-To: References: Message-ID: Emil, Acknowledged. This is clearly a bug. I've just committed a fix on the develop branch: https://git.nlnetlabs.nl/ldns/commit/?id=4c142888 Thanks for reporting! -- Willem Op 29-03-17 om 17:20 schreef Emil Natan: > Hello, > > ldns-verify-zone is one of the tools I use to verify freshly signed > zonefiles. Since my "signer" machine does not have access to the real > world I provide ldns-verify-zone with the signed zonefile and DS record > like this: > > ldns-verify-zone -S -k Ktest.org.+008+57589.ds test.zone.signed > > When the zonefile is signed with a single ZSK and single KSK there are > no complaints. > When the zonefile is signed with single ZSK and two KSKs (as during KSK > rollover, both KSKs are added to the zone and the DNSKEY RRset is signed > by both KSKs), the above command fails with: > > # ldns-verify-zone -S -k Ktest.org.+008+57589.ds test.zone.signed > Error: No keys with the keytag and algorithm from the RRSIG found for > test.org . DNSKEY > There were errors in the zone > > Just for testing I tried to provide the DSes for both KSKs and no errors > were emitted. > # ldns-verify-zone -k Ktest.org.+008+57589.ds -k Ktest.org.+008+34735.ds > test.zone.signed > Zone is verified and complete > > That's never real world scenario since there is only single DS in the > parent zone during a KSK rollover, first it's the DS generated for the > initial key, then it's replaced with the DS for the successor key. > > The issue is easy to reproduce, generate 3 keys, 1 ZSK and 2 KSK, sign > the zone with one ZSK and both KSK, then run ldns-verify-zone with a > single DS file. > The same happens with and without the "-S" flag. > > Emil > > > _______________________________________________ > ldns-users mailing list > ldns-users at nlnetlabs.nl > https://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From sca at andreasschulze.de Mon Apr 10 09:23:21 2017 From: sca at andreasschulze.de (A. Schulze) Date: Mon, 10 Apr 2017 11:23:21 +0200 Subject: [ldns-users] ldns-read-zone and $INCLUDE In-Reply-To: <6f263997-81ea-be52-2aa3-86a2832295d3@nlnetlabs.nl> References: <20170323105546.Horde.HJvdPVIVwky7l6X4xDbHII0@andreasschulze.de> <6f263997-81ea-be52-2aa3-86a2832295d3@nlnetlabs.nl> Message-ID: <20170410112321.Horde.przR-cu7Gtb0Xn8gJzTgnIa@andreasschulze.de> Willem Toorop: > Would you like me to address these issues one way or the other? Or both? Hello Willem, Thanks for clarification. No, I could workaround that behaviour. I only wanted to make sure I didn't missed something. Andreas From jv at fcelda.cz Mon Apr 10 17:00:33 2017 From: jv at fcelda.cz (=?UTF-8?B?SmFuIFbEjWVsw6Fr?=) Date: Mon, 10 Apr 2017 19:00:33 +0200 Subject: [ldns-users] redefinition of bool, overlap of Z and DO in EDNS In-Reply-To: References: Message-ID: Hello Willem, >> I also just noticed that all tags disappeared from the official >> repository. Please, can you check? > > Yes, something went wrong with the move to a new gitlab instance. They > should be back now. Thank you for a quick fix. >> We have been using ldns in C++ but hit the problem that ldns redefines >> default bool type in common.h [3]. That breaks some constexpr >> definitions which involve boolean types and follow that include. Ugly >> workaround is to include ldns.h and then undefine true, false, and >> bool. Does the code still make sense today? Can I just update the >> macro conditions to include stdbool.h with C and do nothing with C++? > > Yes that seems more stable than what we have now. Use of stdbool.h in a > library is regrettable really. We have had problems before where the > type of bool differed during library compile time and library usage. > Maybe a more stable but still backwards compatible behavioural mechanism > would be to define a DONT_HAVE_STDBOOL_H when the header was not > detected during configure..., I'll try to think of something for you to > review... Perfect. I'm looking forward to it. >> And the last thing: The ldns_pkt_set_edns_z() function clears the DO >> flag. This looks intentional. But the only way to clear all but DO >> flag in EDNS (if I want to use ldns API) is to read the DO flag, use >> the function above the clear all flags, and set DO to its original >> value. This is confusing as EDNS(0) RFC [4] shows Z and DO as separate >> fields. I was thinking about changing getter/setter function for Z to >> exclude DO flag. Does it make sense or do you suggest different >> solution? > > Yes, I am conservative to the extreme with changing behaviour with ldns, > sorry. I suggest to update the documentation to make it more clear, and > add another getter/setter that only changes the Z bits. What do you think about https://github.com/NLnetLabs/ldns/pull/2 ? Cheers, Jan From willem at nlnetlabs.nl Tue Apr 11 08:39:12 2017 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 11 Apr 2017 10:39:12 +0200 Subject: [ldns-users] redefinition of bool, overlap of Z and DO in EDNS In-Reply-To: References: Message-ID: <7432dbf0-1b38-c0fc-d93c-405ca09a69c4@nlnetlabs.nl> Op 10-04-17 om 19:00 schreef Jan V?el?k: >> Yes, I am conservative to the extreme with changing behaviour with ldns, >> sorry. I suggest to update the documentation to make it more clear, and >> add another getter/setter that only changes the Z bits. > > What do you think about https://github.com/NLnetLabs/ldns/pull/2 ? Perfect :) Thanks! -- Willem From aranea at aixah.de Thu Apr 27 14:24:28 2017 From: aranea at aixah.de (Luis Ressel) Date: Thu, 27 Apr 2017 16:24:28 +0200 Subject: [ldns-users] configure scripts in subdirectories Message-ID: <20170427162428.38873fa8@gentp.lnet> Hello, the ldns sources contain separate configure scripts in several subdirectories (such as examples/ and drill/). I suppose those are meant to be used when one wants to compile the code in those subdirectories and link it against an already-installed libldns? If that's the case, I've found a bug: The examples/configure script contains no logic to define HAVE_LIBRESSL, even though this macro is used in the example code. Thus, the example code compiles fine when using "cd ldns-1.7.0; ./configure --with-examples; make", but fails to compile with "cd ldns-1.7.0/examples; ./configure" (on a system using libressl, of course). I can open a bug report, but currently I'm not sure whether this is a bug at all, since I don't have much experience with autotools. Regards, Luis Ressel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: