From gilles.massen at restena.lu  Mon Mar  7 09:26:26 2011
From: gilles.massen at restena.lu (Gilles Massen)
Date: Mon, 07 Mar 2011 10:26:26 +0100
Subject: [ldns-users] drill -k <DS> ?
Message-ID: <4D74A4C2.4000206@restena.lu>

Hello,

I'm scripting a sanity check for signed zones, and would like to check
is the DNSKEY RR validates based on the DS I received (as a
pre-delegation check).

drill -k <keyfile> seem to be an excellent candidate to do that, but I
cannot get it to work if keyfile contains the DS record (as the manpage
suggests that it can). The only answer I get are these:

./drill -k temp.ds -D dnssec.lu @ns1.restena.lu DNSKEY
[...]
; No keys with the keytag and algorithm from the RRSIG found for id = 0,
owner = dnssec.lu.

or

./drill -k temp.ds -D dnssec.lu @ns1.restena.lu SOA
; The signature does not cover this RRset for id = 0, owner = dnssec.lu.

temp.ds contains records in the form:
dnssec.lu.    IN      DS      21851 8 2
4cdbd90d2c6656427cb5e8e87571c704d8672a56a023df5e8a8111410a4e9176

<keyfile> with DNSKEYs works perfectly btw.

Any suggestions what I'm doing wrong?

Best,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473


From wouter at NLnetLabs.nl  Mon Mar  7 12:18:27 2011
From: wouter at NLnetLabs.nl (W.C.A. Wijngaards)
Date: Mon, 07 Mar 2011 13:18:27 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D74A4C2.4000206@restena.lu>
References: <4D74A4C2.4000206@restena.lu>
Message-ID: <4D74CD13.8080205@nlnetlabs.nl>

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

On 03/07/2011 10:26 AM, Gilles Massen wrote:
> Hello,
> 
> I'm scripting a sanity check for signed zones, and would like to check
> is the DNSKEY RR validates based on the DS I received (as a
> pre-delegation check).

> temp.ds contains records in the form:
> dnssec.lu.    IN      DS      21851 8 2
> 4cdbd90d2c6656427cb5e8e87571c704d8672a56a023df5e8a8111410a4e9176
> 
> <keyfile> with DNSKEYs works perfectly btw.
> 
> Any suggestions what I'm doing wrong?

This feature has not been implemented in drill.

unbound-host can verify with -f temp.ds.  It requires you give all the
DS records at the same time when an algorithm rollover happens.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk10zRMACgkQkDLqNwOhpPhh9QCfYBUgldX6tmLHocbh0zYA4d5w
WfEAn0Bgs4uuGJUbLgY/wXkf2elWhi49
=a4Yj
-----END PGP SIGNATURE-----


From matthijs at NLnetLabs.nl  Mon Mar  7 12:59:28 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Mon, 07 Mar 2011 13:59:28 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D74CD13.8080205@nlnetlabs.nl>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
Message-ID: <4D74D6B0.9050808@nlnetlabs.nl>

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

Hi Gilles,

Wouter stands corrected: the -k *is* implemented in and it *does* accept
DS records.

My guess is that you want to chase the signatures: add -S on the command
line.

Best regards,

Matthijs

On 03/07/2011 01:18 PM, W.C.A. Wijngaards wrote:
> On 03/07/2011 10:26 AM, Gilles Massen wrote:
>> Hello,
> 
>> I'm scripting a sanity check for signed zones, and would like to check
>> is the DNSKEY RR validates based on the DS I received (as a
>> pre-delegation check).
> 
>> temp.ds contains records in the form:
>> dnssec.lu.    IN      DS      21851 8 2
>> 4cdbd90d2c6656427cb5e8e87571c704d8672a56a023df5e8a8111410a4e9176
> 
>> <keyfile> with DNSKEYs works perfectly btw.
> 
>> Any suggestions what I'm doing wrong?
> 
> This feature has not been implemented in drill.
> 
> unbound-host can verify with -f temp.ds.  It requires you give all the
> DS records at the same time when an algorithm rollover happens.
> 
> Best regards,
>    Wouter
_______________________________________________
ldns-users mailing list
ldns-users at open.nlnetlabs.nl
http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNdNavAAoJEA8yVCPsQCW5tf4IAM6RMd8H5/pqhVkU8tDCwfK2
mPDdPScFnAZYaIfRCQ+ItMngCAzaZjn1MXBYXaiy5guH4LAI7+o8Qd3Y9ygJIIKM
rUD6ndrfGoNaIjlSGg6gjmhTDmUfPkgLS+U7UdWMRyL9EiVYVmA7ZIPDuxdf40GM
uw4P9W7zBzg2x9KpkaQmr4cgKi3N+JYrTKpqgLoepb/Jl2qDBiX6j9Uh+evg9hSk
6/JmcQpe2Mr6uPWgoh2Nt3tQo7xMnp9xWm+MLbv86zYXEw77nsW8eTXIa5UZ+Q0/
AtFxDr5tm1d6AKmH+LHYxyGBfOMTsUG3ZJCd/RgkJ/n9fpQuEj/z9ck04mp9wxI=
=pH5j
-----END PGP SIGNATURE-----


From gilles.massen at restena.lu  Mon Mar  7 13:53:30 2011
From: gilles.massen at restena.lu (Gilles Massen)
Date: Mon, 07 Mar 2011 14:53:30 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D74D6B0.9050808@nlnetlabs.nl>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl>
Message-ID: <4D74E35A.8060001@restena.lu>

Hello Matthijs,

> Wouter stands corrected: the -k *is* implemented in and it *does* accept
> DS records.

Glad to hear that :)

> My guess is that you want to chase the signatures: add -S on the command
> line.

Not really. It might be possible, but chasing is too clever for my
purpose. I don't want to leave the realm of the zone/server to be
checked...climbing the DNS tree up does not fit.

Actually I want to answer a single question: "can I validate this
zone/record with the DS I have" (and the DS is for the zone, not for
anywhere up the tree).

drill -k <keyfile> with DNSKEY does exactly that, so I'm a bit back to
square one: if it does indeed accept DS records, what could I be doing
wrong? Or is the use case ( -k <ds> -D ) not supported ?

Best,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473


From matthijs at NLnetLabs.nl  Mon Mar  7 14:37:10 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Mon, 07 Mar 2011 15:37:10 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D74E35A.8060001@restena.lu>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
Message-ID: <4D74ED96.2010802@nlnetlabs.nl>

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

Hi Gilles,

On 03/07/2011 02:53 PM, Gilles Massen wrote:
> Hello Matthijs,
> 
>> Wouter stands corrected: the -k *is* implemented in and it *does* accept
>> DS records.
> 
> Glad to hear that :)
> 
>> My guess is that you want to chase the signatures: add -S on the command
>> line.
> 
> Not really. It might be possible, but chasing is too clever for my
> purpose. I don't want to leave the realm of the zone/server to be
> checked...climbing the DNS tree up does not fit.

Sorry, providing DS records in the keyfile only makes sense when chasing
signatures or doing a secure trace. Otherwise, drill tries to validate
the answer with the keys in the keyfile (without chasing). Just like the
manpage says:)

> Actually I want to answer a single question: "can I validate this
> zone/record with the DS I have" (and the DS is for the zone, not for
> anywhere up the tree).
> 
> drill -k <keyfile> with DNSKEY does exactly that, so I'm a bit back to
> square one: if it does indeed accept DS records, what could I be doing
> wrong? Or is the use case ( -k <ds> -D ) not supported ?

Technically, you can't validate the answer with DS records, you'll need
to find the correct DNSKEY RRset. So you need to make a secure trace
between the DS RRs and the DNSKEY RRset.

So:
drill <name> -k <ds> -D is not supported (or at least not like you
expect to).
drill <name> -k <ds> -D [-S|-T] is supported.

Best regards,

Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNdO2WAAoJEA8yVCPsQCW5EaMH+wRh1m208boIn9dwVESA9e00
j0mfUNb/kEyTKerjGFwWUZBhyww3L+dci/KgP00vbD6Bq5GxaDavPw+/8Iiz9qv8
mWaMoafNTA9on9OnS0r0l7WSshr1EGmxnLwkE5j2yVBqopI68sZG5KpAfSrfZHRf
jwnT+iZa0JW1yZgtO3O4Q1GaJWOmD8X3XZmRsVUKmEZiLRv8N+uoihhDX+9EMQ6K
9xkdMI16VtzEhNC5QsWPS1NL57gdr/7QyS36M2pXkArb02mGbrDfS6YZg1r6wuef
TpHqlTeMqgLDDuQF6P/JBG8SgyJ4TFuZ2+ugRatDJ1vU+NSs93YmmIo/TicL2Zs=
=Cx1/
-----END PGP SIGNATURE-----


From miek at miek.nl  Mon Mar  7 17:17:46 2011
From: miek at miek.nl (Miek Gieben)
Date: Mon, 7 Mar 2011 18:17:46 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D74ED96.2010802@nlnetlabs.nl>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl>
Message-ID: <20110307171746.GA23063@miek.nl>

[ Quoting Matthijs Mekking in "Re: [ldns-users] drill -k <DS> ?"... ]
> > drill -k <keyfile> with DNSKEY does exactly that, so I'm a bit back to
> > square one: if it does indeed accept DS records, what could I be doing
> > wrong? Or is the use case ( -k <ds> -D ) not supported ?
> 
> So:
> drill <name> -k <ds> -D is not supported (or at least not like you
> expect to).
> drill <name> -k <ds> -D [-S|-T] is supported.

It look like this is a request for ldns-verify-zone, but then for
a zone loaded in a nameserver?

grtz Miek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110307/c202dc0b/attachment.bin>

From matthijs at NLnetLabs.nl  Tue Mar  8 09:31:03 2011
From: matthijs at NLnetLabs.nl (Matthijs Mekking)
Date: Tue, 08 Mar 2011 10:31:03 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <20110307171746.GA23063@miek.nl>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl> <20110307171746.GA23063@miek.nl>
Message-ID: <4D75F757.7050704@nlnetlabs.nl>

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

On 03/07/2011 06:17 PM, Miek Gieben wrote:
> [ Quoting Matthijs Mekking in "Re: [ldns-users] drill -k <DS> ?"... ]
>>> drill -k <keyfile> with DNSKEY does exactly that, so I'm a bit back to
>>> square one: if it does indeed accept DS records, what could I be doing
>>> wrong? Or is the use case ( -k <ds> -D ) not supported ?
>>
>> So:
>> drill <name> -k <ds> -D is not supported (or at least not like you
>> expect to).
>> drill <name> -k <ds> -D [-S|-T] is supported.
> 
> It look like this is a request for ldns-verify-zone, but then for
> a zone loaded in a nameserver?

Now it does go towards the direction of unbound-host.

Best regards,

Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNdfdXAAoJEA8yVCPsQCW5dk4IAKd2iKv3sltdMgatxALuBzFs
ILE/rjnb94dT/Sft8TlCzopKN67+o00bgLyeRCrVJQXYP+Xy5clYuNBqRJXt6lcG
YYpkbREn/O7iP1+r7Gx8OvpQgZgtzV4CO2kkgmUuLykA0JbBmMtz+Xy/u2Hz7Dc1
j9ZJXPXIzJItVT009MIAC5sgLGho5yJQ3hm/8Q4hKZ879vLbbkkR2vKsAn6XSm7c
69ziTeRjVz+zEsTGBzvM/lGUwR+LccIdMAbFhBiZoh8849cCwD6RLoLl6cpP4dUH
MCFlk1ecMbTKDWOmLxbcWXqXR8eNwFqotul8ZDrHAhU+dk2uccgmAcPwYIYdpzw=
=p3St
-----END PGP SIGNATURE-----


From gilles.massen at restena.lu  Tue Mar  8 09:37:45 2011
From: gilles.massen at restena.lu (Gilles Massen)
Date: Tue, 08 Mar 2011 10:37:45 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D75F757.7050704@nlnetlabs.nl>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl> <20110307171746.GA23063@miek.nl>
 <4D75F757.7050704@nlnetlabs.nl>
Message-ID: <4D75F8E9.2010804@restena.lu>


>>> So:
>>> drill <name> -k <ds> -D is not supported (or at least not like you
>>> expect to).
>>> drill <name> -k <ds> -D [-S|-T] is supported.
> 
>> It look like this is a request for ldns-verify-zone, but then for
>> a zone loaded in a nameserver?
> 
> Now it does go towards the direction of unbound-host.

>From a semantic point of view "ldns-verify-zone" sound more appropriate,
but from a code point of view unbound-host does the job but is only
missing the option to direct the query to a specific nameserver. Which,
IMHO, would be useful for any unbound-host user.

Best,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473


From wouter at NLnetLabs.nl  Tue Mar  8 09:53:59 2011
From: wouter at NLnetLabs.nl (W.C.A. Wijngaards)
Date: Tue, 08 Mar 2011 10:53:59 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D75F8E9.2010804@restena.lu>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl> <20110307171746.GA23063@miek.nl>
 <4D75F757.7050704@nlnetlabs.nl> <4D75F8E9.2010804@restena.lu>
Message-ID: <4D75FCB7.6090205@nlnetlabs.nl>

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

Hi Gilles,

On 03/08/2011 10:37 AM, Gilles Massen wrote:
> 
>>>> So:
>>>> drill <name> -k <ds> -D is not supported (or at least not like you
>>>> expect to).
>>>> drill <name> -k <ds> -D [-S|-T] is supported.
>>
>>> It look like this is a request for ldns-verify-zone, but then for
>>> a zone loaded in a nameserver?
>>
>> Now it does go towards the direction of unbound-host.
> 
>>From a semantic point of view "ldns-verify-zone" sound more appropriate,
> but from a code point of view unbound-host does the job but is only
> missing the option to direct the query to a specific nameserver. Which,
> IMHO, would be useful for any unbound-host user.

But you can do this via the config file option:

unbound-host -C unbound.conf  and put a stub-zone: "example.com"
stub-addr: 127.0.0.1 at 53  or something in there.

Most other unbound.conf features work as well (validation options,
zones, python module, ...), but some are not appropriate (i.e. daemon
pidfile location).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk11/LcACgkQkDLqNwOhpPjzbwCfa6extYjZ9+iFD1SfUKQyaFgJ
B6kAn3McdjYeOk5rVf8SfsbfHGtMhupv
=MAaD
-----END PGP SIGNATURE-----


From gilles.massen at restena.lu  Tue Mar  8 10:11:11 2011
From: gilles.massen at restena.lu (Gilles Massen)
Date: Tue, 08 Mar 2011 11:11:11 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D75FCB7.6090205@nlnetlabs.nl>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl> <20110307171746.GA23063@miek.nl>
 <4D75F757.7050704@nlnetlabs.nl> <4D75F8E9.2010804@restena.lu>
 <4D75FCB7.6090205@nlnetlabs.nl>
Message-ID: <4D7600BF.3060409@restena.lu>

Hi Wouter,

>> >From a semantic point of view "ldns-verify-zone" sound more appropriate,
>> but from a code point of view unbound-host does the job but is only
>> missing the option to direct the query to a specific nameserver. Which,
>> IMHO, would be useful for any unbound-host user.
> 
> But you can do this via the config file option:
> 
> unbound-host -C unbound.conf  and put a stub-zone: "example.com"
> stub-addr: 127.0.0.1 at 53  or something in there.

Sure, but as my validation is on a different server for each check, that
would imply building a custom unbound.conf on the fly. Certainly doable,
and certainly ugly.

You just cannot beat command-line options :)

(this said, a command-line option to which you could feed any of the
allowed conf-file statements would be a very nice thing, and solve all
command-line shortcomings in one go)

Best,
Gilles


-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473


From miek at miek.nl  Tue Mar  8 10:16:43 2011
From: miek at miek.nl (Miek Gieben)
Date: Tue, 8 Mar 2011 11:16:43 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <4D7600BF.3060409@restena.lu>
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl> <20110307171746.GA23063@miek.nl>
 <4D75F757.7050704@nlnetlabs.nl> <4D75F8E9.2010804@restena.lu>
 <4D75FCB7.6090205@nlnetlabs.nl> <4D7600BF.3060409@restena.lu>
Message-ID: <20110308101643.GA4827@miek.nl>

[ Quoting Gilles Massen in "Re: [ldns-users] drill -k <DS> ?"... ]
> > unbound-host -C unbound.conf  and put a stub-zone: "example.com"
> > stub-addr: 127.0.0.1 at 53  or something in there.
> 
> Sure, but as my validation is on a different server for each check, that
> would imply building a custom unbound.conf on the fly. Certainly doable,
> and certainly ugly.

or (also ugly)

unbound-host -C <(echo -e stubzone: example.com\\nstub-addr: 127.0.0.1 at 53)

> (this said, a command-line option to which you could feed any of the
> allowed conf-file statements would be a very nice thing, and solve all
> command-line shortcomings in one go)

That's a nice idea.

grtz Miek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110308/36e7f572/attachment.bin>

From jaap at NLnetLabs.nl  Tue Mar  8 19:44:45 2011
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Tue, 08 Mar 2011 20:44:45 +0100
Subject: [ldns-users] drill -k <DS> ?
In-Reply-To: <20110308101643.GA4827@miek.nl> 
References: <4D74A4C2.4000206@restena.lu> <4D74CD13.8080205@nlnetlabs.nl>
 <4D74D6B0.9050808@nlnetlabs.nl> <4D74E35A.8060001@restena.lu>
 <4D74ED96.2010802@nlnetlabs.nl> <20110307171746.GA23063@miek.nl>
 <4D75F757.7050704@nlnetlabs.nl> <4D75F8E9.2010804@restena.lu>
 <4D75FCB7.6090205@nlnetlabs.nl> <4D7600BF.3060409@restena.lu>
 <20110308101643.GA4827@miek.nl>
Message-ID: <201103081944.p28JijLZ014990@bartok.nlnetlabs.nl>


    
    or (also ugly)
    
    unbound-host -C <(echo -e stubzone: example.com\\nstub-addr: 127.0.0.1 at 53)

In that case, a here-document document is more useful as in

unbound-host -C <<-!EOF-Config

# config stuff, shell variables possible as in

stubzone:	$STUB_ZONE

!EOF-Config

	jaap


From msheldon at godaddy.com  Fri Mar 11 21:49:17 2011
From: msheldon at godaddy.com (Michael Sheldon)
Date: Fri, 11 Mar 2011 14:49:17 -0700
Subject: [ldns-users] =?utf-8?q?No_compression_in_ldns=5Fpkt2wire=3F?=
Message-ID: <20110311144917.205a61dff9fc1684c258b274662bb912.62afee2a57.wbe@email00.secureserver.net>

>From looking at wire-format data produced by ldns_pkt2wire, it appears
that it does not compress the owners of the records?

Michael Sheldon
Dev-DNS Services
GoDaddy.com





From willem at NLnetLabs.nl  Mon Mar 14 10:21:27 2011
From: willem at NLnetLabs.nl (Willem Toorop)
Date: Mon, 14 Mar 2011 11:21:27 +0100
Subject: [ldns-users] No compression in ldns_pkt2wire?
In-Reply-To: <20110311144917.205a61dff9fc1684c258b274662bb912.62afee2a57.wbe@email00.secureserver.net>
References: <20110311144917.205a61dff9fc1684c258b274662bb912.62afee2a57.wbe@email00.secureserver.net>
Message-ID: <4D7DEC27.3090503@nlnetlabs.nl>

X-TagToolbar-Keys: D20110314112127683
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


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

Hi Michael,

Compression is indeed not implemented yet in ldns.
I shall append a request for the feature to the TODO list.

Best regards, Willem

On 03/11/11 22:49, Michael Sheldon wrote:
> >From looking at wire-format data produced by ldns_pkt2wire, it appears
> that it does not compress the owners of the records?
>
> Michael Sheldon
> Dev-DNS Services
> GoDaddy.com
>
>
>
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNfewnAAoJEOX4+CEvd6SY9VsP/2b/zrc4uKMjJmOQa9F7x7uM
v2fObqUVXzYasEzFGpW0OGBK6q6E+5hKTmGQVapbGl3nttEvuCnc+WSXetyv12eo
nafJYrc3kv2195LWcpST3QIKe3kETC73ZHaz5683y8+uc/n3vd0JO8vCvAXEGJkH
wQgeAwpoTggHQuQVl/CEvGHn2Kr8h2oO119Qoq9EHk0P6MhpPbJophWB8wnc0t0u
WwXh8zKmITl2AUpCBVnw59cNmf4jYng+UpS1E1t8MBsjpRnl7ARuvAgedIUZWYYI
cKD4vcS9hK0wjz/K1wbCxyr4fy9Nxonau5cUOkgSk4CRPQ5YjB2dO2iHMl7lQsb/
1wWwrDEz3fb2x5LeLkiOhPFulnCO5hzdLDoPkYvuqGKmyAhUJJ35rdGg2xOi/2Sa
LHvv+daUmcDgmOgjsXr+VTJwZIlY/FlsIJvZ3467HbrzsNb6qTb+XvHU5kNVzOnH
EhnA2GpVMOY99SA/VCHXqu5kKv9X8URbAPO1crBICX01W3kpGI6KfcOEkTz5EWke
1FJE6Qu1MCSUomyHY6SV8U8vE/WhvKe8FOD08D63jJmow6vmbqqi5jPFek7j30cH
ZUlVMJGdBVPdVnUwKvtO7BluOuDGgy/ZYSjigVI1x3sqLWmDpNP8I6lVnCZL7W1t
3+FI3PdwimRfP1aEbvhK
=Ql7f
-----END PGP SIGNATURE-----



From miek at miek.nl  Mon Mar 14 11:26:46 2011
From: miek at miek.nl (Miek Gieben)
Date: Mon, 14 Mar 2011 12:26:46 +0100
Subject: [ldns-users] ldns + axfr + tsig
Message-ID: <20110314112646.GA6817@miek.nl>

Hello,

Does anybody has some ldns code laying around which implements
axfr and tsig validation?

AFAICT the resolver impl. in ldns itself can only sign outgoing
requests. Drill also only impl. the signing, not the validating.

Kind regards,

--
 Miek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110314/69ef8247/attachment.bin>

From darryl at rodden.us  Mon Mar 14 14:07:18 2011
From: darryl at rodden.us (Darryl Rodden)
Date: Mon, 14 Mar 2011 07:07:18 -0700
Subject: [ldns-users] No compression in ldns_pkt2wire?
References: <20110311144917.205a61dff9fc1684c258b274662bb912.62afee2a57.wbe@email00.secureserver.net>
 <4D7DEC27.3090503@nlnetlabs.nl>
Message-ID: <003501cbe251$21af5c40$6210a8c0@cis.neustar.com>

FWIW, we asked for that 2 years ago.  Doesn't seem to be a priority
for them.  Before I got pulled out of DNSAdv, I wanted to just add
that to library myself (as a new function).

-dr


----- Original Message ----- 
From: "Willem Toorop" <willem at NLnetLabs.nl>
To: "Michael Sheldon" <msheldon at godaddy.com>
Cc: <ldns-users at open.nlnetlabs.nl>
Sent: Monday, March 14, 2011 3:21 AM
Subject: Re: [ldns-users] No compression in ldns_pkt2wire?


> X-TagToolbar-Keys: D20110314112127683
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Michael,
> 
> Compression is indeed not implemented yet in ldns.
> I shall append a request for the feature to the TODO list.
> 
> Best regards, Willem
> 
> On 03/11/11 22:49, Michael Sheldon wrote:
>> >From looking at wire-format data produced by ldns_pkt2wire, it appears
>> that it does not compress the owners of the records?
>>
>> Michael Sheldon
>> Dev-DNS Services
>> GoDaddy.com
>>
>>
>>
>> _______________________________________________
>> ldns-users mailing list
>> ldns-users at open.nlnetlabs.nl
>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQIcBAEBAgAGBQJNfewnAAoJEOX4+CEvd6SY9VsP/2b/zrc4uKMjJmOQa9F7x7uM
> v2fObqUVXzYasEzFGpW0OGBK6q6E+5hKTmGQVapbGl3nttEvuCnc+WSXetyv12eo
> nafJYrc3kv2195LWcpST3QIKe3kETC73ZHaz5683y8+uc/n3vd0JO8vCvAXEGJkH
> wQgeAwpoTggHQuQVl/CEvGHn2Kr8h2oO119Qoq9EHk0P6MhpPbJophWB8wnc0t0u
> WwXh8zKmITl2AUpCBVnw59cNmf4jYng+UpS1E1t8MBsjpRnl7ARuvAgedIUZWYYI
> cKD4vcS9hK0wjz/K1wbCxyr4fy9Nxonau5cUOkgSk4CRPQ5YjB2dO2iHMl7lQsb/
> 1wWwrDEz3fb2x5LeLkiOhPFulnCO5hzdLDoPkYvuqGKmyAhUJJ35rdGg2xOi/2Sa
> LHvv+daUmcDgmOgjsXr+VTJwZIlY/FlsIJvZ3467HbrzsNb6qTb+XvHU5kNVzOnH
> EhnA2GpVMOY99SA/VCHXqu5kKv9X8URbAPO1crBICX01W3kpGI6KfcOEkTz5EWke
> 1FJE6Qu1MCSUomyHY6SV8U8vE/WhvKe8FOD08D63jJmow6vmbqqi5jPFek7j30cH
> ZUlVMJGdBVPdVnUwKvtO7BluOuDGgy/ZYSjigVI1x3sqLWmDpNP8I6lVnCZL7W1t
> 3+FI3PdwimRfP1aEbvhK
> =Ql7f
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
>


From gilles.massen at restena.lu  Wed Mar 16 10:01:00 2011
From: gilles.massen at restena.lu (Gilles Massen)
Date: Wed, 16 Mar 2011 11:01:00 +0100
Subject: [ldns-users] bug in drill?
Message-ID: <4D808A5C.7070208@restena.lu>

Hello,

When running a drill on ns1.dns.lu (or any other existing name in
dns.lu), I get an error, but still a correct result. It looks like a
bug, but so far I have been unable to tie it to something specific,
although I would suspect that it is somehow NSEC3/OptOut related. (an
NSEC zone, from the same signer, is working fine).

The command:

./drill -k root.key -DT ns1.dns.lu a

Last lines of the output:

;; Domain: dns.lu.
[T] dns.lu. 7200 IN DNSKEY 256 3 8 ;{id = 41485 (zsk), size = 1024b}
dns.lu. 7200 IN DNSKEY 256 3 8 ;{id = 16129 (zsk), size = 1024b}
dns.lu. 7200 IN DNSKEY 257 3 8 ;{id = 13736 (ksk), size = 2048b}
[B] Error verifying denial of existence for ns1.dns.lu. DS: General LDNS
error
;; No ds record for delegation
;; Domain: ns1.dns.lu.
;; No DNSKEY record found for ns1.dns.lu.
[T] ns1.dns.lu. 86400   IN      A       158.64.229.2

This is ldns 1.6.8.

Best,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473


From willem at NLnetLabs.nl  Wed Mar 16 14:39:12 2011
From: willem at NLnetLabs.nl (Willem Toorop)
Date: Wed, 16 Mar 2011 15:39:12 +0100
Subject: [ldns-users] ldns 1.6.9 released
Message-ID: <4D80CB90.3030601@nlnetlabs.nl>

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

Hi,

Version 1.6.9 of ldns is now available.

Best regards,

Willem Toorop

link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.9.tar.gz
sha1: 30d136792433bef44454dc1c70bf55449160c3ad

Changelog:
  * Fix creating NSEC(3) bitmaps: make array size 65536,
    don't add doubles.
  * Fix printout of escaped binary in TXT records.
  * Parsing TXT records: don't skip starting whitespace that is quoted.
  * bugfix #358: Check if memory was successfully allocated in
    ldns_rdf2str().
  * Added more memory allocation checks in host2str.c
  * python wrapper for ldns_fetch_valid_domain_keys by Bedrich Kosata.
  * fix to compile python wrapper with swig 2.0.2.
  * Don't fallback to SHA-1 when creating NSEC3 hash with another
    algorithm identifier, fail instead (no other algorithm identifiers
    are assigned yet).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNgMuQAAoJEOX4+CEvd6SYlRUP/0G0VxFkrPq5wIOO/CY1jd72
81L93SX7ECu3FWzVCfruhgYumDVtC/l8c59TCABIENrQl2eM0KVpv3/TJCKy++VD
/dIEcZMKB2N3f9ded62/WSMlgIdwE7SbgSsqsjdlabNheK3VMlePaDWvEkzW5lTw
kVmvu7q+zH5geDSYBq33GN605vksorsB1IJ6Azqhr0oexFcLdf8gXmZUCHoXq8/8
WlhxDkHppx42C2KO9ipll/pSuEAV4N0gAPf+/NY+dHtFsJsBG9DPmstCGX6ACAjm
3Xbf3ued4+73Aln6Lj/NVywsSP9G6Y/l1QTVNzNFBzZ3jj6wKBvNrcMuLi0KXqGc
zpJmfLvVZIuef62wTHYDNqsUfbKhMjsnceVXLr4WAxnILymU+Wd8DIrosuJda7t8
15lsgrwbG2X2nFncjruPJLPaa+O0AAIMAXeYnhipCybSeRqak+mrx3gi9K6b0VYG
reLvz5anMNtEbk2hbvmrhQiLKxNZKj66cytkdgJkdYM8quHy6Nf6TAAqRTHA7h+G
PtbOoTxdTmhsYr8qdNyW+HNNY26AVvoeMwZSs5f/sQXmZ6lXzXRf9W9Hx2Jss7ej
0tCKdf5z+e2mGLqJGYbv0RctoWJBq9u7IZIkx0ZNTEUWcuvRXUjEgRuTAGiuda/9
lOXCmmQbbS6rTSIIJn2Z
=VzVK
-----END PGP SIGNATURE-----


From bedrich.kosata at nic.cz  Wed Mar 16 19:21:52 2011
From: bedrich.kosata at nic.cz (Bedrich Kosata)
Date: Wed, 16 Mar 2011 20:21:52 +0100
Subject: [ldns-users] a bug in pyldns
Message-ID: <4D810DD0.2040306@nic.cz>

Hi everybody,

two of my students found another problem with the pyldns bindings. The 
function ldns.ldns_rr.new_frm_fp (ldns_rr_new_frm_fp_l_ in the raw 
wrapper) does not properly increment reference count on Py_None. This 
results in erroneous deallocation and after this function is used 
repeatedly for some time, the program crashes with "Fatal Python error: 
deallocating None" (the refcount for None reaches 0).
This problem is remedied by the attached patch against ldns-1.6.9 (I am 
sorry I did not make it before the release :)). For good measure, I 
applied the same treatment to two other functions (ldns_rr_new_frm_str_, 
ldns_rr_new_question_frm_str_) where the same problem appeared.

With best regards

Beda


p.s.- here is a simple test program to reproduce the crash in 
ldns_rr_new_frm_str_

-------------
import ldns
import sys

while True:
   print sys.getrefcount(None)
   ldns.ldns_rr.new_frm_str("www.nic.cz. IN A 192.168.1.1",300)
-------------

In the fixed state, it should run indefinitely.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldns.i.patch
Type: text/x-patch
Size: 956 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110316/21d72b53/attachment.bin>

From willem at NLnetLabs.nl  Fri Mar 18 08:36:40 2011
From: willem at NLnetLabs.nl (Willem Toorop)
Date: Fri, 18 Mar 2011 09:36:40 +0100
Subject: [ldns-users] a bug in pyldns
In-Reply-To: <4D810DD0.2040306@nic.cz>
References: <4D810DD0.2040306@nic.cz>
Message-ID: <4D831998.1030301@nlnetlabs.nl>

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

Hi Bedrich,

Thank you for your patch.
I applied it to trunk.

Best regards,

Willem

On 03/16/11 20:21, Bedrich Kosata wrote:
> Hi everybody,
> 
> two of my students found another problem with the pyldns bindings. The
> function ldns.ldns_rr.new_frm_fp (ldns_rr_new_frm_fp_l_ in the raw
> wrapper) does not properly increment reference count on Py_None. This
> results in erroneous deallocation and after this function is used
> repeatedly for some time, the program crashes with "Fatal Python error:
> deallocating None" (the refcount for None reaches 0).
> This problem is remedied by the attached patch against ldns-1.6.9 (I am
> sorry I did not make it before the release :)). For good measure, I
> applied the same treatment to two other functions (ldns_rr_new_frm_str_,
> ldns_rr_new_question_frm_str_) where the same problem appeared.
> 
> With best regards
> 
> Beda
> 
> 
> p.s.- here is a simple test program to reproduce the crash in
> ldns_rr_new_frm_str_
> 
> -------------
> import ldns
> import sys
> 
> while True:
>   print sys.getrefcount(None)
>   ldns.ldns_rr.new_frm_str("www.nic.cz. IN A 192.168.1.1",300)
> -------------
> 
> In the fixed state, it should run indefinitely.
> 
> 
> 
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNgxmYAAoJEOX4+CEvd6SY8I4P/Arl8kx2subSQ6G4BJAfekmO
yD0ofsyE5C2cJItN03GmHl56SouiGqARMWvzXHo4THfZhJ8Kyfj2EDqRas64x08B
w9me0XpRJXAO0/k9o8bbNyUijZv+D/dTPo7xeBWYRtb+F6mp9OzBN7PzAXAA7EwI
PRCGyIRQAzG6qP1qake00C+kcAYLndoG7h2azxBUT3fJ0VsaAinw0CNfoBG3lcdP
P917TgO1AjBc0TSxRHaqTJSAiewlSIZS16dowJylU3SAsCdg6LYPuONeFKuRuCkv
7GCqjoCW5pAGcBUkpCqN/hhbrAn00dt0nlKlVRPAc0gERwEEZfv/fzdaxA+P0HGc
bG1l/Mj+GUUMMelkt5yBm4u4StY1Jajb9Z6jNhG2eqMQ7Hz9Dvo+kqsR9t2I7pez
L6feuAJsFf2ht9Wq+vzQdTOn9OtTC2iD3auccZPpNYAjdKeaqaVk4K3nF7wZvD9C
8aso6kmRddN2oaM4geDJmjdiOmMRE0en8lLRRR0AySXIgNv4xal+jnNYyx0zkMG4
hx+Xjne/zruzDYO1vGwdK1w548yHsXPvTznXe3GJeUhPpBCYjUo4mODGdieqJq2U
MMl3rPMgz3alBH2FqBpl82PmAr3QPbWQ3QCIN+H+/EAkAx81FJ4rozX7if9GeFJW
DwJC5tRlKxWwiwDfqkGI
=K8Gt
-----END PGP SIGNATURE-----


From willem at NLnetLabs.nl  Fri Mar 18 10:54:04 2011
From: willem at NLnetLabs.nl (Willem Toorop)
Date: Fri, 18 Mar 2011 11:54:04 +0100
Subject: [ldns-users] bug in drill?
In-Reply-To: <4D808A5C.7070208@restena.lu>
References: <4D808A5C.7070208@restena.lu>
Message-ID: <4D8339CC.1070701@nlnetlabs.nl>

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

Hi Gilles,

For your interest, I have created a Bug in our Bugzilla system regarding
the issue which can be viewed here:

http://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=372

Best regards,

Willem

On 03/16/11 11:01, Gilles Massen wrote:
> Hello,
> 
> When running a drill on ns1.dns.lu (or any other existing name in
> dns.lu), I get an error, but still a correct result. It looks like a
> bug, but so far I have been unable to tie it to something specific,
> although I would suspect that it is somehow NSEC3/OptOut related. (an
> NSEC zone, from the same signer, is working fine).
> 
> The command:
> 
> ./drill -k root.key -DT ns1.dns.lu a
> 
> Last lines of the output:
> 
> ;; Domain: dns.lu.
> [T] dns.lu. 7200 IN DNSKEY 256 3 8 ;{id = 41485 (zsk), size = 1024b}
> dns.lu. 7200 IN DNSKEY 256 3 8 ;{id = 16129 (zsk), size = 1024b}
> dns.lu. 7200 IN DNSKEY 257 3 8 ;{id = 13736 (ksk), size = 2048b}
> [B] Error verifying denial of existence for ns1.dns.lu. DS: General LDNS
> error
> ;; No ds record for delegation
> ;; Domain: ns1.dns.lu.
> ;; No DNSKEY record found for ns1.dns.lu.
> [T] ns1.dns.lu. 86400   IN      A       158.64.229.2
> 
> This is ldns 1.6.8.
> 
> Best,
> Gilles
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNgznMAAoJEOX4+CEvd6SYWaYP/j3uJGuQaaDqnc47StzxXKpo
M9HVS1Kp5rwWvHECM3Uz0W0o9/q2u/cKtxpu+sFCTaOaHEKR9fvy62Q4QppeLUws
oxvt+vMIwxL10sF1NYyLimNQxW7KaIqGxvDv+PfYYdCE7W86I/GvhNmGgYBenuK/
GN6jPyNIk6tQqr0VwQy4lT9U612pp7cDdtHzfkwCt+42rtX5FTFXkOFAi0jmiteq
5kKXOOulPSe1Nj+UzEiwedF1qcPWx+ROLGhTNMPRibW1UaQRsH4oZV0n8t9ATxT0
MyuF0sF7ttn3t79JPAqley8Jbd+kjke3+DeKWpKa1Ot79Vtpgk0y0SrJvbSQbRLR
ngUkaOKddpyEJ5ytjuef56ygGv24YtjWNlakGjOekcFkGyncImW/8lAkSYhmV/F5
p6HZ6GjnJW70ngXEnVxJ9L+fbkmEuZseBWinEHDhVwRfKWqNg3ZD8IdeIUOEUpN1
a6LKRU8inGrHoi+fBdM7U7LgUfhrWvxf6OEM0iIJpwbqo1s2nAl4Ger3H00/2j13
vgZPqJIeCpsfCLpnTDMe5eBDt1n3cj+FzksJ5voOHl0D3SAeUXjX64V2DXCMiAIE
NyX6ild80eeTKv4+YbxwbPxbXWU/9XfaQ/Ix3tEBXtVU+it+MINzkhh4nsNXg6yI
uIoWa73BCgw7R5ZSq1/2
=3SM8
-----END PGP SIGNATURE-----


From bedrich.kosata at nic.cz  Fri Mar 25 08:48:33 2011
From: bedrich.kosata at nic.cz (Bedrich Kosata)
Date: Fri, 25 Mar 2011 09:48:33 +0100
Subject: [ldns-users] pyldns - memory leaks and double freeing
Message-ID: <4D8C56E1.7040301@nic.cz>

Hi everybody,

while trying to find a cause of a memory leak in a simple script, I 
found a nest of memory related issues in the python bindings.
The problems are all related to one common problem - who takes care of 
memory of composite objects, such as ldns_rr_lists or ldns_pkt.
For example, in the current version, ldns_pkt bindings use ldns_pkt_free 
to free a packet structure, however, when a rr_list is taken from the 
packet and returned from a function, the packet gets out of scope, is 
freed and the rr_list refers to already freed memory.
On the other hand, a rr_list only frees its own memory, not memory of 
the stored rrs. This can lead to memory leaks.
I am attaching two scripts that demonstrate these problems (it might be 
necessary to have the sources patched with the "freeing None" patch I 
sent last week).
I would be willing to have a stab at the problems (provided I get 
clearance from my boss :)), but the only solution I think would be clean 
enough, is to clone the necessary bits where needed. This might lead to 
some inefficiency and slowdowns (probably not big), so I would like to 
ask if this is ok.
If there is anyone else willing to fix this, I would be happy to act as 
a tester.

Cheers

Beda

p.s.- test-pkt-free.py crashes with a segmentation fault, 
test-rr-list.py ends up eating about 130 MB of memory and more than 
400000 python objects which python cannot free.

-- 
Bedrich Kosata
CZ.NIC Labs <http://labs.nic.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-pkt-free.py
Type: text/x-python
Size: 276 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110325/ef6798d6/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-rr-list.py
Type: text/x-python
Size: 467 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110325/ef6798d6/attachment-0001.py>

From bedrich.kosata at nic.cz  Fri Mar 25 08:56:25 2011
From: bedrich.kosata at nic.cz (Bedrich Kosata)
Date: Fri, 25 Mar 2011 09:56:25 +0100
Subject: [ldns-users] pyldns - wire2pkt
Message-ID: <4D8C58B9.90708@nic.cz>

Hi again,

I attach a patch which makes wire2pkt usable from python. The previous 
version always complained about wrong type of arguments.
A test code is attached as well.

Cheers

Beda

-- 
Bedrich Kosata
CZ.NIC Labs <http://labs.nic.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldns.i-wire2pkt.patch
Type: text/x-patch
Size: 890 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110325/c40e392a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-wire2pkt.py
Type: text/x-python
Size: 774 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20110325/c40e392a/attachment.py>