From calle at init.se  Fri Jun 13 09:07:24 2014
From: calle at init.se (Calle Dybedahl)
Date: Fri, 13 Jun 2014 11:07:24 +0200
Subject: [ldns-users] Segfault bug in ldns 1.6.17
Message-ID: <CAPnYScXPjSfNWn5s_g60gQk2F1LDVdJeErdJmz1VjT9zB+EFMw@mail.gmail.com>

Hello.

Here's some C code that, at least right now, makes ldns segfault when
trying to free memory that was never allocated. The server in question does
send back data that is in some way malformed, so in some way I guess ldns
is insufficiently paranoid.

I'm trying to look into the problem, but since I'm neither a very good C
programmer nor very familiar with the ldns internals I'm not proceeding
very quickly. So I'm hoping someone else will go "Oh, right, that's the
problem" and fix it right away :-)

/Calle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140613/647535ea/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.c
Type: text/x-csrc
Size: 638 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140613/647535ea/attachment.bin>

From calle at init.se  Fri Jun 13 09:59:20 2014
From: calle at init.se (Calle Dybedahl)
Date: Fri, 13 Jun 2014 11:59:20 +0200
Subject: [ldns-users] Segfault bug in ldns 1.6.17
In-Reply-To: <CAPnYScXPjSfNWn5s_g60gQk2F1LDVdJeErdJmz1VjT9zB+EFMw@mail.gmail.com>
References: <CAPnYScXPjSfNWn5s_g60gQk2F1LDVdJeErdJmz1VjT9zB+EFMw@mail.gmail.com>
Message-ID: <CAPnYScXeWyT2f9o7F9GxKSycFqQNKxtLSo=atdaAK0fKW+q54A@mail.gmail.com>

I think I found the problem. At line 1137 in resolver.c, ldns_pkt_free() is
unconditionally called on answer_pkt, but if ldns_wire2pkt() failed
answer_pkt is not pointing at allocated memory. Changing it so that
ldns_pkt_free() is only called if stat is LDNS_STATUS_OK seems to fix the
problem. At least my code doesn't segfault any more if I do that.

/Calle


On 13 June 2014 11:07, Calle Dybedahl <calle at init.se> wrote:

> Hello.
>
> Here's some C code that, at least right now, makes ldns segfault when
> trying to free memory that was never allocated. The server in question does
> send back data that is in some way malformed, so in some way I guess ldns
> is insufficiently paranoid.
>
> I'm trying to look into the problem, but since I'm neither a very good C
> programmer nor very familiar with the ldns internals I'm not proceeding
> very quickly. So I'm hoping someone else will go "Oh, right, that's the
> problem" and fix it right away :-)
>
> /Calle
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140613/06e755a1/attachment.htm>

From yuri at nlnetlabs.nl  Fri Jun 13 11:58:52 2014
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Fri, 13 Jun 2014 13:58:52 +0200
Subject: [ldns-users] Segfault bug in ldns 1.6.17
In-Reply-To: <CAPnYScXeWyT2f9o7F9GxKSycFqQNKxtLSo=atdaAK0fKW+q54A@mail.gmail.com>
References: <CAPnYScXPjSfNWn5s_g60gQk2F1LDVdJeErdJmz1VjT9zB+EFMw@mail.gmail.com>
 <CAPnYScXeWyT2f9o7F9GxKSycFqQNKxtLSo=atdaAK0fKW+q54A@mail.gmail.com>
Message-ID: <539AE77C.4050407@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Calle,

> Changing it so that ldns_pkt_free() is only called if stat is
> LDNS_STATUS_OK seems to fix the problem. At least my code doesn't
> segfault any more if I do that.

Thank you for your bug report. I've seen your suggested patch and you
are on the right track but I think it is not entirely correct. and the
real bug is 18 or so lines higher. Where the answer_pkt is freed but
not set to null.

Attached diff.

Regards,
Yuri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlOa53wACgkQI3PTR4mhavg3uACff3agzvFmXVgx+C3oZYhjyfgM
k0EAoMoW5mtdWkvgBMjL8BypbeCHQXqs
=E+i0
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldns.diff
Type: text/x-patch
Size: 427 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140613/9d3e983b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldns.diff.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140613/9d3e983b/attachment-0001.bin>

From yuri at nlnetlabs.nl  Fri Jun 13 14:58:01 2014
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Fri, 13 Jun 2014 16:58:01 +0200
Subject: [ldns-users] Segfault bug in ldns 1.6.17
In-Reply-To: <539AE77C.4050407@nlnetlabs.nl>
References: <CAPnYScXPjSfNWn5s_g60gQk2F1LDVdJeErdJmz1VjT9zB+EFMw@mail.gmail.com>
 <CAPnYScXeWyT2f9o7F9GxKSycFqQNKxtLSo=atdaAK0fKW+q54A@mail.gmail.com>
 <539AE77C.4050407@nlnetlabs.nl>
Message-ID: <539B1179.8030706@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just noticed Willem already plugged that hole last January in commit
2853eb352b4461e98f2926ace4ea3810cedf4167 [0]. So it will be part of
the next release.

Thanks,
Yuri

[0]
http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=2853eb352b4461e98f2926ace4ea3810cedf4167

On 13-06-14 13:58, Yuri Schaeffer wrote:
> Hi Calle,
> 
>> Changing it so that ldns_pkt_free() is only called if stat is 
>> LDNS_STATUS_OK seems to fix the problem. At least my code
>> doesn't segfault any more if I do that.
> 
> Thank you for your bug report. I've seen your suggested patch and
> you are on the right track but I think it is not entirely correct.
> and the real bug is 18 or so lines higher. Where the answer_pkt is
> freed but not set to null.
> 
> Attached diff.
> 
> Regards, Yuri
> 
> 
> 
> _______________________________________________ ldns-users mailing
> list ldns-users at open.nlnetlabs.nl 
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlObEXkACgkQI3PTR4mhavh3PgCcCycZlAWTf2VDOIQglwbMDikt
AMEAoIs7da4IS/h/2e2i3ptLdxSOYmC2
=vOkm
-----END PGP SIGNATURE-----


From edmonds at debian.org  Tue Jun 17 18:25:02 2014
From: edmonds at debian.org (Robert Edmonds)
Date: Tue, 17 Jun 2014 14:25:02 -0400
Subject: [ldns-users] whitespace bug in ldns-read-zone?
Message-ID: <20140617182502.GA13577@mycre.ws>

Hi,

I was editing a zone file today and found a case that named-checkzone
parses without error, but ldns-read-zone does not.  Here is a reduced
test case reproducing the issue:

edmonds at chase{0}:/tmp$ cat test.zone
$TTL 1
@ SOA test. test. 1 1 1 1 1
 NS ns1.
 ; Comment.
 NS ns2.
edmonds at chase{0}:/tmp$ named-checkzone -D test ./test.zone
zone test/IN: loaded serial 1
test.                         1 IN SOA      test. test. 1 1 1 1 1
test.                         1 IN NS       ns1.
test.                         1 IN NS       ns2.
OK
edmonds at chase{0}:/tmp$ ldns-read-zone -z ./test.zone 
Syntax error, could not parse the RR's TTL at 4
edmonds at chase{1}:/tmp$ ldns-read-zone -v
read zone version 1.6.17 (ldns version 1.6.17)
edmonds at chase{0}:/tmp$ 

Is this maybe a bug in ldns?

-- 
Robert Edmonds
edmonds at debian.org


From matthijs at nlnetlabs.nl  Wed Jun 18 08:03:22 2014
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 18 Jun 2014 10:03:22 +0200
Subject: [ldns-users] whitespace bug in ldns-read-zone?
In-Reply-To: <20140617182502.GA13577@mycre.ws>
References: <20140617182502.GA13577@mycre.ws>
Message-ID: <53A147CA.8030009@nlnetlabs.nl>

Hi Robert,

A bug: the comment line starts with whitespace and ends with a comment,
but it is not catched as an empty line. Quick workaround is to remove
the left side whitespace before the comment.

I have committed a fix in our git repository so that ldns-read-zone does
read this zone without errors.

http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=d6037a22fbedb8ef3a22de4107e4eaa36840865b

Best regards,
  Matthijs

On 06/17/2014 08:25 PM, Robert Edmonds wrote:
> Hi,
> 
> I was editing a zone file today and found a case that named-checkzone
> parses without error, but ldns-read-zone does not.  Here is a reduced
> test case reproducing the issue:
> 
> edmonds at chase{0}:/tmp$ cat test.zone
> $TTL 1
> @ SOA test. test. 1 1 1 1 1
>  NS ns1.
>  ; Comment.
>  NS ns2.
> edmonds at chase{0}:/tmp$ named-checkzone -D test ./test.zone
> zone test/IN: loaded serial 1
> test.                         1 IN SOA      test. test. 1 1 1 1 1
> test.                         1 IN NS       ns1.
> test.                         1 IN NS       ns2.
> OK
> edmonds at chase{0}:/tmp$ ldns-read-zone -z ./test.zone 
> Syntax error, could not parse the RR's TTL at 4
> edmonds at chase{1}:/tmp$ ldns-read-zone -v
> read zone version 1.6.17 (ldns version 1.6.17)
> edmonds at chase{0}:/tmp$ 
> 
> Is this maybe a bug in ldns?
> 



From klaus.mailinglists at pernau.at  Mon Jun 23 09:19:35 2014
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Mon, 23 Jun 2014 11:19:35 +0200
Subject: [ldns-users] drill validation issue
Message-ID: <53A7F127.1090207@pernau.at>

Hi!

I periodically validate some signed domains with drill. Once in a while
the validation fails and the reported problem is always in the root
zone. I coudln't find any problems there and I guess if the problem is
really in the root zone it would cause some noise.

Thus I think that drill is buggy which checking the signatures. See the
example attached.

1. The TTL of the RRSIG is different to the TTL of the DNSKEY. Thus I
suspect that drill mixes responses from several resolvers and checks the
RRSIG of one response against the records from another responses.

2. drill shows 2 DNSKEY RRs of the root zone. But there are 3 (2 ZSK + 1
KSK).

regards
Klaus






-------------- next part --------------
drill -k /etc/bind/root-dnskey -S www.dev-nsec.rc0-testing.dnssec-signiert.at
;; Number of trusted keys: 1
;; Chasing: www.dev-nsec.rc0-testing.dnssec-signiert.at. A


DNSSEC Trust tree:
www.dev-nsec.rc0-testing.dnssec-signiert.at. (A)
|---dev-nsec.rc0-testing.dnssec-signiert.at. (DNSKEY keytag: 63780 alg: 5 flags: 256)
    |---dev-nsec.rc0-testing.dnssec-signiert.at. (DNSKEY keytag: 55591 alg: 5 flags: 257)
    |---dev-nsec.rc0-testing.dnssec-signiert.at. (DS keytag: 55591 digest type: 2)
        |---rc0-testing.dnssec-signiert.at. (DNSKEY keytag: 9618 alg: 5 flags: 256)
            |---rc0-testing.dnssec-signiert.at. (DNSKEY keytag: 59227 alg: 5 flags: 257)
            |---rc0-testing.dnssec-signiert.at. (DS keytag: 59227 digest type: 2)
                |---dnssec-signiert.at. (DNSKEY keytag: 60710 alg: 7 flags: 256)
                    |---dnssec-signiert.at. (DNSKEY keytag: 39606 alg: 7 flags: 257)
                    |---dnssec-signiert.at. (DS keytag: 39606 digest type: 2)
                        |---at. (DNSKEY keytag: 7906 alg: 8 flags: 256)
                            |---at. (DNSKEY keytag: 60836 alg: 8 flags: 257)
                            |---at. (DS keytag: 56489 digest type: 2)
                            |   |---. (DNSKEY keytag: 40926 alg: 8 flags: 256)
                            |       |---Bogus DNSSEC signature:
.	116937	IN	RRSIG	DNSKEY 8 0 172800 20140705235959 20140620000000 19036 . OWYyUDHJjQxh2KGaNdXqkvnmPj8E5Jafyya42A9oPOBBZ1L16Db7PTa4/pwbuSgteAI3gGP3hPRUAnGLx87c0JK6DUWnbiElMY/eUmZO6j2sq0mLKZKM7CRdOd8erIlFiPUnOwOPOEDolH0RxdJYkV4N0z6cujA/Bfx8i8NSlnIu/yvDPxSwio5CrdSQ2UgDKY3WUVyoGWePySYd2i6kHyd7DqTVkWfkvMqcU1kQbABlDO0GPL9UQym/WAf13qXA/rN49aQyiVsldzyug8EDWhZIbcviBPf2McJnLz6X1hTMD7nT3kVGSbLnBmgyu2QJc10wVv+M4iuUtSWsmo8Byw==
For RRset:
.	46368	IN	DNSKEY	256 3 8 AwEAAZvJd8ORk+jmZ41QMYbQ1XCpf60l6YJuHtnxn0VSh5a5vqwEjTST3/PZ4xhUFu2YcTfRNWxs9WTiGZl3MY/UlBIvzpLhKgKnf9Vk8sEU3q0nmOGFgE6jTi/cU95ATU/2dTQovMDv9XyWvrmj8KIG2brj6mF4S8GTae6G2GwbMF5v ;{id = 40926 (zsk), size = 1024b}
.	46368	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b}
With key:
.	46368	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b}
                            |       |---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
                            |---at. (DS keytag: 60836 digest type: 2)
                                |---. (DNSKEY keytag: 40926 alg: 8 flags: 256)
                                    |---Bogus DNSSEC signature:
.	116937	IN	RRSIG	DNSKEY 8 0 172800 20140705235959 20140620000000 19036 . OWYyUDHJjQxh2KGaNdXqkvnmPj8E5Jafyya42A9oPOBBZ1L16Db7PTa4/pwbuSgteAI3gGP3hPRUAnGLx87c0JK6DUWnbiElMY/eUmZO6j2sq0mLKZKM7CRdOd8erIlFiPUnOwOPOEDolH0RxdJYkV4N0z6cujA/Bfx8i8NSlnIu/yvDPxSwio5CrdSQ2UgDKY3WUVyoGWePySYd2i6kHyd7DqTVkWfkvMqcU1kQbABlDO0GPL9UQym/WAf13qXA/rN49aQyiVsldzyug8EDWhZIbcviBPf2McJnLz6X1hTMD7nT3kVGSbLnBmgyu2QJc10wVv+M4iuUtSWsmo8Byw==
For RRset:
.	46368	IN	DNSKEY	256 3 8 AwEAAZvJd8ORk+jmZ41QMYbQ1XCpf60l6YJuHtnxn0VSh5a5vqwEjTST3/PZ4xhUFu2YcTfRNWxs9WTiGZl3MY/UlBIvzpLhKgKnf9Vk8sEU3q0nmOGFgE6jTi/cU95ATU/2dTQovMDv9XyWvrmj8KIG2brj6mF4S8GTae6G2GwbMF5v ;{id = 40926 (zsk), size = 1024b}
.	46368	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b}
With key:
.	46368	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b}
                                    |---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
No trusted keys found in tree: first error was: Bogus DNSSEC signature
;; Chase failed.

From klaus.mailinglists at pernau.at  Mon Jun 23 09:22:03 2014
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Mon, 23 Jun 2014 11:22:03 +0200
Subject: [ldns-users] drill validation issue
In-Reply-To: <53A7F127.1090207@pernau.at>
References: <53A7F127.1090207@pernau.at>
Message-ID: <53A7F1BB.7030902@pernau.at>

I forgot to mention that I use drill 1.6.17



darilion at dnsmaster:~$ dpkg -l|grep ldns
ii  ldnsutils                          1.6.17-1
amd64        ldns library for DNS programming
ii  libldns1                           1.6.17-1
amd64        ldns library for DNS programming
darilion at dnsmaster:~$ drill -v
drill version 1.6.17 (ldns version 1.6.17)
Written by NLnet Labs.

Copyright (c) 2004-2008 NLnet Labs.
Licensed under the revised BSD license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.


On 23.06.2014 11:19, Klaus Darilion wrote:
> Hi!
> 
> I periodically validate some signed domains with drill. Once in a while
> the validation fails and the reported problem is always in the root
> zone. I coudln't find any problems there and I guess if the problem is
> really in the root zone it would cause some noise.
> 
> Thus I think that drill is buggy which checking the signatures. See the
> example attached.
> 
> 1. The TTL of the RRSIG is different to the TTL of the DNSKEY. Thus I
> suspect that drill mixes responses from several resolvers and checks the
> RRSIG of one response against the records from another responses.
> 
> 2. drill shows 2 DNSKEY RRs of the root zone. But there are 3 (2 ZSK + 1
> KSK).
> 
> regards
> Klaus
> 
> 
> 
> 
> 
> 


From willem at nlnetlabs.nl  Mon Jun 23 11:41:24 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Mon, 23 Jun 2014 13:41:24 +0200
Subject: [ldns-users] drill validation issue
In-Reply-To: <53A7F1BB.7030902@pernau.at>
References: <53A7F127.1090207@pernau.at> <53A7F1BB.7030902@pernau.at>
Message-ID: <53A81264.5020409@nlnetlabs.nl>

Thanks Klaus,

I'll see if I can reproduce (and capture the exact circumstances (packet
capture etc.)).  Does it also happen tracing instead of chasing?

Regards,

-- Willem

op 23-06-14 11:22, Klaus Darilion schreef:
> I forgot to mention that I use drill 1.6.17
> 
> 
> 
> darilion at dnsmaster:~$ dpkg -l|grep ldns
> ii  ldnsutils                          1.6.17-1
> amd64        ldns library for DNS programming
> ii  libldns1                           1.6.17-1
> amd64        ldns library for DNS programming
> darilion at dnsmaster:~$ drill -v
> drill version 1.6.17 (ldns version 1.6.17)
> Written by NLnet Labs.
> 
> Copyright (c) 2004-2008 NLnet Labs.
> Licensed under the revised BSD license.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS
> FOR A PARTICULAR PURPOSE.
> 
> 
> On 23.06.2014 11:19, Klaus Darilion wrote:
>> Hi!
>>
>> I periodically validate some signed domains with drill. Once in a while
>> the validation fails and the reported problem is always in the root
>> zone. I coudln't find any problems there and I guess if the problem is
>> really in the root zone it would cause some noise.
>>
>> Thus I think that drill is buggy which checking the signatures. See the
>> example attached.
>>
>> 1. The TTL of the RRSIG is different to the TTL of the DNSKEY. Thus I
>> suspect that drill mixes responses from several resolvers and checks the
>> RRSIG of one response against the records from another responses.
>>
>> 2. drill shows 2 DNSKEY RRs of the root zone. But there are 3 (2 ZSK + 1
>> KSK).
>>
>> regards
>> Klaus
>>
>>
>>
>>
>>
>>
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 



From mail at maxliebkies.de  Mon Jun 23 17:34:31 2014
From: mail at maxliebkies.de (Max Liebkies)
Date: Mon, 23 Jun 2014 17:34:31 +0000
Subject: [ldns-users] Missing NULL check in ldns_rr_compare_ds
Message-ID: <1403552044.30757.0.camel@failenovo.lan>

Hi,

I recently stumbled over a segfault in the Python ldns wrapper in the
ldns_rr_compare_ds method. I seem to have been calling the method with
at least one argument being None. As the underlying C method clones both
ldns_rr structs first but doesn't check the return value of
ldns_rr_clone, the subsequent calls to ldns_rr_set_ttl will segfault.

How to reproduce with python:
>>> from ldns import ldns_rr_compare_ds
>>> ldns_rr_compare_ds(None, None)

Please see the attached patch for a fix in rr.c

Cheers,
Max

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_check_return_value_in_compare_ds.patch
Type: text/x-patch
Size: 445 bytes
Desc: fix_check_return_value_in_compare_ds.patch
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140623/813f046a/attachment.bin>

From calle at init.se  Tue Jun 24 07:39:13 2014
From: calle at init.se (Calle Dybedahl)
Date: Tue, 24 Jun 2014 09:39:13 +0200
Subject: [ldns-users] Compression of outgoing packets?
Message-ID: <CAPnYScWEsmn70cLhBqwkwyto9c=b0j6Yc=s3RQCLZb7vQo6giQ@mail.gmail.com>

Hi.

Compression of outgoing packets seems to have been on the TODO list for
more than three years. Is anyone actively working on it, or should I have a
go myself? We kind of need it.

-- 
Calle Dybedahl -*- calle at init.se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20140624/c6d5595a/attachment.htm>

From willem at nlnetlabs.nl  Tue Jun 24 10:24:28 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 24 Jun 2014 12:24:28 +0200
Subject: [ldns-users] Compression of outgoing packets?
In-Reply-To: <CAPnYScWEsmn70cLhBqwkwyto9c=b0j6Yc=s3RQCLZb7vQo6giQ@mail.gmail.com>
References: <CAPnYScWEsmn70cLhBqwkwyto9c=b0j6Yc=s3RQCLZb7vQo6giQ@mail.gmail.com>
Message-ID: <53A951DC.8070707@nlnetlabs.nl>

Hi Calle,

Every contribution is welcomed :).
I'm glad to help out with this as well though...

You might want to have a look at ldns in the current unbound repository
too.  It is going to be the basis for the new core (for DNS elements
conversion).  I plan to incorporate it in the main ldns repo shortly.

Maybe a isolated compress packet function using the scanners...

My main development focus for ldns is focused towards incorporating
those new conversion functions;   But, you know, if it isn't too hard to
do in our current packet to wire conversion functions, maybe we should
do it that way as well, so we'll have it quickly.

We can take the Net::DNS code as an example... (see
Net::DNS::DomainName1035::encode).  Take a ldns_rbtree as the hash...

Or adapt unbound's util/data/msgencode.c


op 24-06-14 09:39, Calle Dybedahl schreef:
> Hi.
> 
> Compression of outgoing packets seems to have been on the TODO list for
> more than three years. Is anyone actively working on it, or should I
> have a go myself? We kind of need it.
> 
> -- 
> Calle Dybedahl -*- calle at init.se <mailto:calle at init.se>
> 
> 
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 



From klaus.mailinglists at pernau.at  Tue Jun 24 11:41:14 2014
From: klaus.mailinglists at pernau.at (Klaus Darilion)
Date: Tue, 24 Jun 2014 13:41:14 +0200
Subject: [ldns-users] drill validation issue
In-Reply-To: <53A81264.5020409@nlnetlabs.nl>
References: <53A7F127.1090207@pernau.at> <53A7F1BB.7030902@pernau.at>
 <53A81264.5020409@nlnetlabs.nl>
Message-ID: <53A963DA.4040503@pernau.at>

Hi Willem!

On 23.06.2014 13:41, Willem Toorop wrote:
> Thanks Klaus,
> 
> I'll see if I can reproduce (and capture the exact circumstances (packet
> capture etc.)).  Does it also happen tracing instead of chasing?

I do not know. I always use chasing. (IIRC there was a problem with
tracing with the xit codes to detect validation errors - but I'm not
sure, I testet it several months ago).

regards
Klaus