From matthijs at nlnetlabs.nl  Thu Jan  2 07:27:57 2014
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 02 Jan 2014 08:27:57 +0100
Subject: [ldns-users] Finding out which signatures belong to which RRs
In-Reply-To: <CAAn0BQYyoSQJ60zOen=GUqfEMjC27HKaDmmXVP5BgOGdYEFFWg@mail.gmail.com>
References: <CAAn0BQYyoSQJ60zOen=GUqfEMjC27HKaDmmXVP5BgOGdYEFFWg@mail.gmail.com>
Message-ID: <52C514FD.8080301@nlnetlabs.nl>

On 12/31/2013 03:50 PM, Vladimir Levijev wrote:
> 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?

Each NSEC3 record has a different owner name. The owner name of the
RRSIG record that belongs to an NSEC3 record matches the NSEC3 owner name.

In general: The RRSIG record is a signature over an RRset. An RRset is a
set of records with the same name, class and type. For example:

ns.example.nl IN A 1.2.3.4
ns.example.nl IN A 1.2.3.5

A signature for this RRset will have the owner name 'ns.example.nl'.
Also, in the RDATA of the RRSIG the type of the RRset it signs is
mentioned. In this case: 'A'. So the signature for this RRset starts with:

ns.example.nl IN RRSIG A ...

Best regards,
  Matthijs





Best regards,
  Matthijs

> 
> Cheers,
> 
> VL
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 



From vladimir.levijev at gmail.com  Thu Jan  2 08:46:38 2014
From: vladimir.levijev at gmail.com (Vladimir Levijev)
Date: Thu, 2 Jan 2014 10:46:38 +0200
Subject: [ldns-users] Finding out which signatures belong to which RRs
In-Reply-To: <52C514FD.8080301@nlnetlabs.nl>
References: <CAAn0BQYyoSQJ60zOen=GUqfEMjC27HKaDmmXVP5BgOGdYEFFWg@mail.gmail.com>
 <52C514FD.8080301@nlnetlabs.nl>
Message-ID: <CAAn0BQZ4VokhUHGQtHtp4WJcobWrJjqdKotNVQ+gjFjpWx5s8g@mail.gmail.com>

On 2 January 2014 09:27, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
> On 12/31/2013 03:50 PM, Vladimir Levijev wrote:

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?
>
> Each NSEC3 record has a different owner name. The owner name of the
> RRSIG record that belongs to an NSEC3 record matches the NSEC3 owner name.
>
> In general: The RRSIG record is a signature over an RRset. An RRset is a
> set of records with the same name, class and type. For example:
>
> ns.example.nl IN A 1.2.3.4
> ns.example.nl IN A 1.2.3.5
>
> A signature for this RRset will have the owner name 'ns.example.nl'.
> Also, in the RDATA of the RRSIG the type of the RRset it signs is
> mentioned. In this case: 'A'. So the signature for this RRset starts with:
>
> ns.example.nl IN RRSIG A ...

Ah, the owner name, of course. Thank you. :-)

Cheers,

VL


From willem at nlnetlabs.nl  Fri Jan  3 15:01:37 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Fri, 03 Jan 2014 16:01:37 +0100
Subject: [ldns-users] ldns 1.6.17 rc1
Message-ID: <52C6D0D1.3070408@nlnetlabs.nl>

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

Dear maintainers,

We have a release candidate for ldns 1.6.17

Besides many bug fixes the most prominent new features are:
- - A new option to drill (-I) to query from a specific source address
- - All RR types registered at IANA are now implemented: HIP, NINFO, RKEY,
  CDS, EUI48, EUI64, TKEY, URI, CAA and TA, but RR types which are
  still draft need to be explicitly enabled with configure options:
  --enable-rrtype-ninfo
  --enable-rrtype-rkey
  --enable-rrtype-cds
  --enable-rrtype-uri
  --enable-rrtype-ta
- - Much better performance of ldns-verify-zone with bigger NSEC3 zones
  from NIC MX.
- - Perl5 bindings from Erik Ostlyngen. Enable with --with-p5-dns-ldns

This version will continue using a SONAME version equal to the version
of the package: libldns.so.1.6.17.  This after careful consideration
and internal discussion.  If you feel this is wrong, please speak up.

Please review this release candidate carefully and let us know if
anything is wrong.  If all is well, the actual release will follow
Friday January the 10th 2014.

Best regards,

Willem

link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.17rc1.tar.gz
sha1: 49631ed2fb05d4c3379892a1f9c25520f72d38a0


Changelog:
==========
* Fix ldns_dnssec_zone_new_frm_fp_l to allow the last parsed line of a
  zone to be an NSEC3 (or its RRSIG) covering an empty non terminal.
* Add --disable-dane option to configure and check availability of the
  for dane needed X509_check_ca function in openssl.
* bugfix #490: Get rid of type-punned pointer warnings.
  Thanks Adam Tkac.
* Make sure executables are linked against libcrypto with the
  LIBSSL_LDFLAGS. Thanks Leo Baltus.
* Miscellaneous prototype fixes. Thanks Dag-Erling Sm?rgrav.
* README now shows preferred way to configure for examples and drill.
* Bind to source address for resolvers. drill binds to source with -I.
  Thanks Bryan Duff.
* -T option for ldns-dane that has specific exit status for PKIX
  validated connections without (secure) TLSA records.
* Fix b{32,64}_{ntop,pton} detection and handling.
* New RR type TKEY, but without operational practice.
* New RR types HIP, NINFO, RKEY, CDS, EUI48, EUI64, URI, CAA and TA.
* New output format flag (and accompanying functions) to print certain
  RR's as unknown type
* -u and -U parameter for ldns-read-zone to mark/unmark a RR type
  for printing as unknown type
* bugfix #504: GPOS RR has three rdata fields. Thanks Jelte Jansen.
* bugfix #497: Properly test for EOF when reading key files with drill.
* New functions: ldns_pkt_ixfr_request_new and
  ldns_pkt_ixfr_request_new_frm_str.
* Use SNI with ldns-dane
* bugfix #507: ldnsx Fix use of non-existent variables and not
  properly referring to instance variable.  Patch from shussain.
* bugfix #508: ldnsx Adding NSEC3PARAM to known/allowable RR type
  dictionary.  Patch from shussain.
* bugfix #517: ldns_resolver_new_frm_fp error when invoked using a NULL
  file pointer.
* Fix memory leak in contrib/python: ldns_pkt.new_query.
* Fix buffer overflow in fget_token and bget_token.
* ldns-verify-zone NSEC3 checking from quadratic to linear performance.
  Thanks NIC MX (nicmexico.mx)
* ldns-dane setup new ssl session for each new connect to prevent hangs
* bugfix #521: drill trace continue on empty non-terminals with NSEC3
* bugfix #525: Fix documentation of ldns_resolver_set_retry
* Remove unused LDNS_RDF_TYPE_TSIG and associated functions.
* Fix ldns_nsec_covers_name for zones with an apex only. Thanks Miek.
* Configure option to build perl bindings: --with-p5-dns-ldns
  (Net::LDNS is a contribution from Erik Ostlyngen)
* bugfix #527: Move -lssl before -lcrypto when linking
* Optimize TSIG digest function name comparison (Thanks Marc Buijsman)
* Compare names case insensitive with ldns_pkt_rr_list_by_name and
  ldns_pkt_rr_list_by_name_and_type (thanks Johannes Naab)
* A separate --enable for each draft RR type: --enable-rrtype-ninfo,
  --enable-rrtype-rkey, --enable-rrtype-cds, --enable-rrtype-uri and
  --enable-rrtype-ta
* bugfix #530: Don't sign and verify duplicate RRs (Thanks Jelte Jansen)
* bugfix #505: Manpage and usage output fixes (Thanks Tomas Hozza)
* Adjust ldns_sha1() so that the input data is not modified (Thanks
  Marc Buijsman)
* Messages to stderr are now off by default and can be reenabled with
  the --enable-stderr-msgs configure option.


pyldns Changelog:
=================
* Added ldns_rdf.data_as_bytearray(). The method returns a bytearray
  object containing rdf data.
* Changed the behaviour of ldns_resolver.trusted_key() in order to
  prevent memory corrupotion and leaks.
* Fixed memory leaks when destroying ldns_resolver.
* Removed ldns_pkt.section_count(), ldns_resolver.set_searchlist_count()
  because it is marked static in the library.
* Added ldns_pkt.new(), ldns_resolver.new().
* Marked as returning new object ldns_pkt.get_section_clone(),
  ldns_resolver.get_addr_by_name(), ldns_resolver.get_name_by_addr(),
  ldns_resolver.search().
* Added push cloning for ldns_pkt.safe_push_rr(),
  ldns_pkt.safe_push_rr_list(), ldns_pkt.set_additional(),
  ldns_pkt.set_answer(), ldns_pkt.set_answerfrom(),
  ldns_pkt.set_authority(), ldns_pkt.set_edns_data(),
  ldns_pkt.set_question(), ldns_pkt.set_tsig(),
  ldns_resolver.set_dnssec_anchors(), ldns_resolver.set_domain().
* Added pull cloning for ldns_pkt.answerfrom(), ldns_pkt.edns_data(),
  ldns_pkt.tsig(), ldns_resolver.axfr_last_pkt(),
  ldns_resolver.dnssec_anchors(), ldns_resolver.domain(),
  ldns_resolver.tsig_algorithm(), ldns_resolver.tsig_keydata(),
  ldns_resolver.tsig_keyname().
* Method ldns_rdf.reverse() now throws an exception when not applied
  on dname rdfs. This is to prevent assertion fails in ldns' C code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSxtDRAAoJEOX4+CEvd6SYhRkP/3E7hi6WoasUS4P1salU6Ech
8zm4I2T3su/3bDEL8yJsdXySqDamLxgXACUr34Dup1z8MWSMQw8A06cbVO+yzd8n
pot9W2rRXrjQjereJwhYDmv+MAyvYjFooFOYJ0B3gVlXqiJCE1m2+078z5TCjTaN
EQiBtHi2CxlWJvNeCyHDeHkNkHzeEHF2UF5fPH3HYE/hT1fDfaot/bh1ZCPOC3Pe
15xDqdB1Mb8cJuKAQDEti1vrNjlYV3N2Hs0CHPt66uN0qtH63WUN8nkjPNvma/k9
zpFYHMWajI7ahE2+R9mSfUXAfBjgutHyEJFZ5l6lQdHp6Ia8zyh/A8f0W3kOMd23
xK+9XwlD7+5RWBelR0z5k5wV4FaGM8dXX2wEXzqVIibVp8Q0f/4Ebop+VavHQ0Y8
Wu/OhSe8RXsTlZuGtOrwm0R0Nh4oi9y/Q8ALzMfK0jQmOJaO9MjcCF4AWcRjyriw
+ZGYwuniZYjrzJ+rWNGX8cJZR8QFvoxMfNhmEVffoMju7yMz3Kukh710oHdB4fqm
K+aKNOMP7h5w4FU6fvUVmmwRrnnmn9Nl0wou+SUBl0EK9gLK11PRDwTsn6b9T2BN
0HdujTEupJFb6YBFB+mdnNlmqDJNkkBcGGdH+BhahUQJDw5skijM48ck1rviDyG4
kI+DqAImtRNieC2VIbp1
=ZjyI
-----END PGP SIGNATURE-----


From sjcarr at gmail.com  Fri Jan  3 15:48:50 2014
From: sjcarr at gmail.com (Steven Carr)
Date: Fri, 3 Jan 2014 15:48:50 +0000
Subject: [ldns-users] drill Win32 Binary
Message-ID: <CALMep068-fbhA3VjbAEhSaLnb-=LMY+weH2q==XfY6Fme_n-dA@mail.gmail.com>

Hi list,

I tried to look back over the last 12 months and couldn't see any
posts regarding this, so apologies if I missed it...
Has anyone been able to compile the drill tool on Win32? or know of a
compiled version? (or an equivalent standalone tool?)

Thanks

Steve


From paul at nohats.ca  Fri Jan  3 19:55:02 2014
From: paul at nohats.ca (Paul Wouters)
Date: Fri, 3 Jan 2014 14:55:02 -0500 (EST)
Subject: [ldns-users] ldns 1.6.17 rc1
In-Reply-To: <52C6D0D1.3070408@nlnetlabs.nl>
References: <52C6D0D1.3070408@nlnetlabs.nl>
Message-ID: <alpine.LFD.2.10.1401031452260.3435@bofh.nohats.ca>

On Fri, 3 Jan 2014, Willem Toorop wrote:

> We have a release candidate for ldns 1.6.17

> This version will continue using a SONAME version equal to the version
> of the package: libldns.so.1.6.17.  This after careful consideration
> and internal discussion.  If you feel this is wrong, please speak up.
>
> Please review this release candidate carefully and let us know if
> anything is wrong.  If all is well, the actual release will follow
> Friday January the 10th 2014.

Something changed with the python files. These are not getting installed
for me in /usr/lib/python/ instead of /usr/lib64/python/
I confirmed my build environments. It happens on f19 and f20. Also, ldns
1.6.16 properly puts the files in the arch specific directory. It seems
to be an issue in "make install", but currently too sick look into this
further.

Paul


From willem at nlnetlabs.nl  Wed Jan  8 14:11:28 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 08 Jan 2014 15:11:28 +0100
Subject: [ldns-users] ldns 1.6.17 rc1
In-Reply-To: <alpine.LFD.2.10.1401031452260.3435@bofh.nohats.ca>
References: <52C6D0D1.3070408@nlnetlabs.nl>
 <alpine.LFD.2.10.1401031452260.3435@bofh.nohats.ca>
Message-ID: <52CD5C90.7030105@nlnetlabs.nl>

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

Thanks Paul,

This was due to an updated ax_python_devel.m4 which reset configure to
the default behavior of installing in the platform-independent directory.

I have created a new release candidate with only this fixed (and a
typo).  Because nothing else is touched, if this works for Paul, I'd
like to continue doing the actual release coming Friday the 10th.

link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.17rc2.tar.gz
sha1: aebf98218f90edadb1f09fe5aa0a9b8f38302896

Best regards,

Willem

op 03-01-14 20:55, Paul Wouters schreef:
> On Fri, 3 Jan 2014, Willem Toorop wrote:
> 
>> We have a release candidate for ldns 1.6.17
> 
>> This version will continue using a SONAME version equal to the
>> version of the package: libldns.so.1.6.17.  This after careful
>> consideration and internal discussion.  If you feel this is
>> wrong, please speak up.
>> 
>> Please review this release candidate carefully and let us know
>> if anything is wrong.  If all is well, the actual release will
>> follow Friday January the 10th 2014.
> 
> Something changed with the python files. These are not getting
> installed for me in /usr/lib/python/ instead of /usr/lib64/python/ 
> I confirmed my build environments. It happens on f19 and f20. Also,
> ldns 1.6.16 properly puts the files in the arch specific directory.
> It seems to be an issue in "make install", but currently too sick
> look into this further.
> 
> Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzVyQAAoJEOX4+CEvd6SYRqMP/jOvCWw4DMHxXJkPNtS+dx7i
J6y/FVf2yFJOw0qqRujBAdtB6oJ/eFSYoGNWv3niyCq3/yPw8DiOgmopqUVAQhv3
9DbNvQOw48++tbKhepGnlGYDmkJLVdalAolkgEUZJij3emtfVP3YbDprrmuZDPwT
vSJQxWJUGnwO+pm+QwJmDVUerO4TBn6XtRmpAYAgUDcOaKvfyv54jxvYdqGrCHb4
q8SzkebkoV+bPOoNyLiMKtf43n12XqoQAtB3dJO9XZ3WlmwR4ONLdjX3vhzdN2OO
FImtTSECeNo2OgGT8SUsqGMeXamqormgbh3gO+9Qeg/dDMFBlifbxyu3ozc9clho
soPOHXWJRY48K0HTM5iMBgqHqZmkvMzdJow5SHid+utmbJ8lM7D82SsY3omAWRGg
qLlDezEven3FHPIR/qGMOISi45RX9kR0qdwY7rmq0507b+jnRCLyfrGv43rciQxc
vYhLJ4uBU26ECughK8iZUmImQtJ9jeNBSxw99D2EG6/rPJ/8HqHxCRfEXQeuqmWU
9wDXrqt7MYTmS9Q0ZlZx9Px7IqHyYmc+2Re6RPj0sxb5xiWXxVGMHomw5ibxrSJV
yb/XHSsRDN4c7oYIZfwF+sb9JqtUJookamdxa0JVanZqgiBsPCFoizK1LkEv4gkO
kmIBLrWtw6wvnb7+BuLt
=rcPV
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Wed Jan  8 15:11:47 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 08 Jan 2014 16:11:47 +0100
Subject: [ldns-users] drill Win32 Binary
In-Reply-To: <CALMep068-fbhA3VjbAEhSaLnb-=LMY+weH2q==XfY6Fme_n-dA@mail.gmail.com>
References: <CALMep068-fbhA3VjbAEhSaLnb-=LMY+weH2q==XfY6Fme_n-dA@mail.gmail.com>
Message-ID: <52CD6AB3.7000806@nlnetlabs.nl>

Well... nothing official, but I managed to compile and run with mingw32
on Fedora 18.  You can download the executable from
www.nlnetlabs.nl/~willem/drill.exe

At least the paths were drill expect things are broken.  For example it
expects a file resolv.conf on c:\etc\resolv,conf.  But if you provide
one, it seems to be quiet functional:

mkdir \etc
echo nameserver 8.8.8.8 > \etc\resolv.conf
drill -b 4096 . DNSKEY > root.key
drill -k root.key -S nlnetlabs.nl



op 03-01-14 16:48, Steven Carr schreef:
> Hi list,
> 
> I tried to look back over the last 12 months and couldn't see any
> posts regarding this, so apologies if I missed it...
> Has anyone been able to compile the drill tool on Win32? or know of a
> compiled version? (or an equivalent standalone tool?)
> 
> Thanks
> 
> Steve
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 



From paul at nohats.ca  Wed Jan  8 15:32:34 2014
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 8 Jan 2014 10:32:34 -0500 (EST)
Subject: [ldns-users] ldns 1.6.17 rc1
In-Reply-To: <52CD5C90.7030105@nlnetlabs.nl>
References: <52C6D0D1.3070408@nlnetlabs.nl>
 <alpine.LFD.2.10.1401031452260.3435@bofh.nohats.ca>
 <52CD5C90.7030105@nlnetlabs.nl>
Message-ID: <alpine.LFD.2.10.1401081031260.22567@bofh.nohats.ca>

On Wed, 8 Jan 2014, Willem Toorop wrote:

> This was due to an updated ax_python_devel.m4 which reset configure to
> the default behavior of installing in the platform-independent directory.
>
> I have created a new release candidate with only this fixed (and a
> typo).  Because nothing else is touched, if this works for Paul, I'd
> like to continue doing the actual release coming Friday the 10th.
>
> link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.17rc2.tar.gz
> sha1: aebf98218f90edadb1f09fe5aa0a9b8f38302896

that worked for me. So packaging wise it seems fine. And running it on
my laptop work as well.

Paul


From willem at nlnetlabs.nl  Fri Jan 10 22:12:13 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Fri, 10 Jan 2014 23:12:13 +0100
Subject: [ldns-users] ldns 1.6.17 released
Message-ID: <52D0703D.2050203@nlnetlabs.nl>

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

Dear maintainers and users of ldns software,

I am pleased to announce that version 1.6.17 of ldns is now available.

Besides many bug fixes the most prominent new features are:
- - A new option to drill (-I) to query from a specific source address
- - All RR types registered at IANA are now implemented: HIP, NINFO, RKEY,
  CDS, EUI48, EUI64, TKEY, URI, CAA and TA, but RR types which are
  still draft need to be explicitly enabled with configure options:
  --enable-rrtype-ninfo
  --enable-rrtype-rkey
  --enable-rrtype-cds
  --enable-rrtype-uri
  --enable-rrtype-ta
- - Much better performance of ldns-verify-zone with bigger NSEC3 zones
  from NIC MX.
- - Perl5 bindings from Erik Ostlyngen. Enable with --with-p5-dns-ldns

I hope this release will be useful for you and that you will keep us
informed of your experiences.

Best regards,

Willem Toorop

link: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.17.tar.gz
sha1: 4218897b3c002aadfc7280b3f40cda829e05c9a4

Changelog:
==========
* Fix ldns_dnssec_zone_new_frm_fp_l to allow the last parsed line of a
  zone to be an NSEC3 (or its RRSIG) covering an empty non terminal.
* Add --disable-dane option to configure and check availability of the
  for dane needed X509_check_ca function in openssl.
* bugfix #490: Get rid of type-punned pointer warnings.
  Thanks Adam Tkac.
* Make sure executables are linked against libcrypto with the
  LIBSSL_LDFLAGS. Thanks Leo Baltus.
* Miscellaneous prototype fixes. Thanks Dag-Erling Sm?rgrav.
* README now shows preferred way to configure for examples and drill.
* Bind to source address for resolvers. drill binds to source with -I.
  Thanks Bryan Duff.
* -T option for ldns-dane that has specific exit status for PKIX
  validated connections without (secure) TLSA records.
* Fix b{32,64}_{ntop,pton} detection and handling.
* New RR type TKEY, but without operational practice.
* New RR types HIP, NINFO, RKEY, CDS, EUI48, EUI64, URI, CAA and TA.
* New output format flag (and accompanying functions) to print certain
  RR's as unknown type
* -u and -U parameter for ldns-read-zone to mark/unmark a RR type
  for printing as unknown type
* bugfix #504: GPOS RR has three rdata fields. Thanks Jelte Jansen.
* bugfix #497: Properly test for EOF when reading key files with drill.
* New functions: ldns_pkt_ixfr_request_new and
  ldns_pkt_ixfr_request_new_frm_str.
* Use SNI with ldns-dane
* bugfix #507: ldnsx Fix use of non-existent variables and not
  properly referring to instance variable.  Patch from shussain.
* bugfix #508: ldnsx Adding NSEC3PARAM to known/allowable RR type
  dictionary.  Patch from shussain.
* bugfix #517: ldns_resolver_new_frm_fp error when invoked using a NULL
  file pointer.
* Fix memory leak in contrib/python: ldns_pkt.new_query.
* Fix buffer overflow in fget_token and bget_token.
* ldns-verify-zone NSEC3 checking from quadratic to linear performance.
  Thanks NIC MX (nicmexico.mx)
* ldns-dane setup new ssl session for each new connect to prevent hangs
* bugfix #521: drill trace continue on empty non-terminals with NSEC3
* bugfix #525: Fix documentation of ldns_resolver_set_retry
* Remove unused LDNS_RDF_TYPE_TSIG and associated functions.
* Fix ldns_nsec_covers_name for zones with an apex only. Thanks Miek.
* Configure option to build perl bindings: --with-p5-dns-ldns
  (DNS::LDNS is a contribution from Erik Ostlyngen)
* bugfix #527: Move -lssl before -lcrypto when linking
* Optimize TSIG digest function name comparison (Thanks Marc Buijsman)
* Compare names case insensitive with ldns_pkt_rr_list_by_name and
  ldns_pkt_rr_list_by_name_and_type (thanks Johannes Naab)
* A separate --enable for each draft RR type: --enable-rrtype-ninfo,
  --enable-rrtype-rkey, --enable-rrtype-cds, --enable-rrtype-uri and
  --enable-rrtype-ta
* bugfix #530: Don't sign and verify duplicate RRs (Thanks Jelte Jansen)
* bugfix #505: Manpage and usage output fixes (Thanks Tomas Hozza)
* Adjust ldns_sha1() so that the input data is not modified (Thanks
  Marc Buijsman)
* Messages to stderr are now off by default and can be reenabled with
  the --enable-stderr-msgs configure option.


pyldns Changelog:
=================
* Added ldns_rdf.data_as_bytearray(). The method returns a bytearray
  object containing rdf data.
* Changed the behaviour of ldns_resolver.trusted_key() in order to
  prevent memory corrupotion and leaks.
* Fixed memory leaks when destroying ldns_resolver.
* Removed ldns_pkt.section_count(), ldns_resolver.set_searchlist_count()
  because it is marked static in the library.
* Added ldns_pkt.new(), ldns_resolver.new().
* Marked as returning new object ldns_pkt.get_section_clone(),
  ldns_resolver.get_addr_by_name(), ldns_resolver.get_name_by_addr(),
  ldns_resolver.search().
* Added push cloning for ldns_pkt.safe_push_rr(),
  ldns_pkt.safe_push_rr_list(), ldns_pkt.set_additional(),
  ldns_pkt.set_answer(), ldns_pkt.set_answerfrom(),
  ldns_pkt.set_authority(), ldns_pkt.set_edns_data(),
  ldns_pkt.set_question(), ldns_pkt.set_tsig(),
  ldns_resolver.set_dnssec_anchors(), ldns_resolver.set_domain().
* Added pull cloning for ldns_pkt.answerfrom(), ldns_pkt.edns_data(),
  ldns_pkt.tsig(), ldns_resolver.axfr_last_pkt(),
  ldns_resolver.dnssec_anchors(), ldns_resolver.domain(),
  ldns_resolver.tsig_algorithm(), ldns_resolver.tsig_keydata(),
  ldns_resolver.tsig_keyname().
* Method ldns_rdf.reverse() now throws an exception when not applied
  on dname rdfs. This is to prevent assertion fails in ldns' C code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS0HA3AAoJEOX4+CEvd6SYOE8P/3AHi/8WJ+XZB+Ow+na2gVEW
Cy6HI4yTnbbsHzlJgDtrGcU6eWqO0YNCVQcsWCI+1yWRNSMVpD3GtBn5edcQDkVg
ox3B4/guXYSmnKTonnbAS0sen3vLNNnc7Q5YMH2dIXO1brMaA1stLTGtOV4KsOMg
HOorYsVXq+Cp80uPjbelnpgzcoTp4s/J1fBIVm1npTZ6EVRDFkhmbw5K96vst7Li
ITVtsEkPNfV0qRDzHJWPAWz9a8yR6hJzsc2MQ3RjROWQK8UtXBQeOI7fSnMauytR
tFMgDyKpjj/u6lqM9dK2A+XBiTKL20X94VpFvI84rVtId6w5qjbtwrRcP11fRTut
uwpR2Fh3G2rD3lZR6DMNxfNFSt6uKuJVMHdV89IB2Qo1Nv69mIyBeJ8DuluZ0pak
kudWD3fmv9i3IGvmHXF3Q9TJFyg5ET+uxOqxdGhNPr4vRE41mTA3kPmgSlYr22ey
givftEDL8Fi/WqjyNGfF2BxmVocIPDbuTsgBH6jN6yns59RB+fP/aYFrKQrj15im
fXdW+Z7+GDwfO+sYdRiiBgeVH0N1qFexsbwD2yOGnPOHCkFbL1nRmc+hY5iDGqco
GoE8Cm0+4nzQWOycB/c01qc9NH6LPnIonJa+kgIDmzvJ3ruyrsVxFFaWzZBEnQJL
cjVU+2TUIVOQviSJSl61
=z93v
-----END PGP SIGNATURE-----


From paul at nohats.ca  Sat Jan 11 00:56:44 2014
From: paul at nohats.ca (Paul Wouters)
Date: Fri, 10 Jan 2014 19:56:44 -0500 (EST)
Subject: [ldns-users] ldns 1.6.17 released
In-Reply-To: <52D0703D.2050203@nlnetlabs.nl>
References: <52D0703D.2050203@nlnetlabs.nl>
Message-ID: <alpine.LFD.2.10.1401101954050.29331@bofh.nohats.ca>

On Fri, 10 Jan 2014, Willem Toorop wrote:

> Dear maintainers and users of ldns software,

For the perl bindings packaging, I could not use --with-p5-dns-ldns

Instead, the spec file manually runs now using:

(
    cd contrib/DNS-LDNS
    perl Makefile.PL INSTALLDIRS=vendor
    make
)

and

(
    cd contrib/DNS-LDNS
    make  DESTDIR=%{buildroot} pure_install
)

I'm not sure if you can improve the --with-p5-dns-ldns such that it
remains distro neutral.

Paul


From greg at gerg.ca  Mon Jan 27 23:51:49 2014
From: greg at gerg.ca (Greg Ward)
Date: Mon, 27 Jan 2014 18:51:49 -0500
Subject: [ldns-users] drill -T with CNAMEs
Message-ID: <20140127235149.GA18524@renesys.com>

Hi all --

I'm looking for a DNS tracing tool that starts at a root nameserver,
and follows CNAMEs all the way to a set of A (or AAAA) records. "drill
-T", like "dig +trace", stops when it gets to a CNAME, e.g.

  $ drill -T www.microsoft.com
  com.    172800  IN      NS      d.gtld-servers.net.
  [...]
  com.    172800  IN      NS      b.gtld-servers.net.
  microsoft.com.  172800  IN      NS      ns3.msft.net.
  microsoft.com.  172800  IN      NS      ns1.msft.net.
  microsoft.com.  172800  IN      NS      ns5.msft.net.
  microsoft.com.  172800  IN      NS      ns2.msft.net.
  microsoft.com.  172800  IN      NS      ns4.msft.net.
  www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

To get the answer I want -- a list of IP addressess -- I'd have to run
"drill -T" repeatedly until I stop getting CNAMEs. No thanks! I want
it done 1) automatically and 2) in a single process, so it doesn't
have to hit the root and TLD nameservers repeatedly.

I don't see any options to drill that would help me. Is anyone aware
of a drill-like tool that might help? Or a patch to drill to save me
the time of hacking it up myself?

Thanks!

Greg


From willem at nlnetlabs.nl  Tue Jan 28 13:38:32 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 28 Jan 2014 14:38:32 +0100
Subject: [ldns-users] drill -T with CNAMEs
In-Reply-To: <20140127235149.GA18524@renesys.com>
References: <20140127235149.GA18524@renesys.com>
Message-ID: <52E7B2D8.4000301@nlnetlabs.nl>

Hi Greg,

Interesting idea.  I'll give it a shot shortly...

-- Willem

op 28-01-14 00:51, Greg Ward schreef:
> Hi all --
> 
> I'm looking for a DNS tracing tool that starts at a root nameserver,
> and follows CNAMEs all the way to a set of A (or AAAA) records. "drill
> -T", like "dig +trace", stops when it gets to a CNAME, e.g.
> 
>   $ drill -T www.microsoft.com
>   com.    172800  IN      NS      d.gtld-servers.net.
>   [...]
>   com.    172800  IN      NS      b.gtld-servers.net.
>   microsoft.com.  172800  IN      NS      ns3.msft.net.
>   microsoft.com.  172800  IN      NS      ns1.msft.net.
>   microsoft.com.  172800  IN      NS      ns5.msft.net.
>   microsoft.com.  172800  IN      NS      ns2.msft.net.
>   microsoft.com.  172800  IN      NS      ns4.msft.net.
>   www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.
> 
> To get the answer I want -- a list of IP addressess -- I'd have to run
> "drill -T" repeatedly until I stop getting CNAMEs. No thanks! I want
> it done 1) automatically and 2) in a single process, so it doesn't
> have to hit the root and TLD nameservers repeatedly.
> 
> I don't see any options to drill that would help me. Is anyone aware
> of a drill-like tool that might help? Or a patch to drill to save me
> the time of hacking it up myself?
> 
> Thanks!
> 
> Greg
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 



From greg at lists.gerg.ca  Tue Jan 28 14:53:58 2014
From: greg at lists.gerg.ca (Greg Ward)
Date: Tue, 28 Jan 2014 09:53:58 -0500
Subject: [ldns-users] drill -T with CNAMEs
In-Reply-To: <52E7B2D8.4000301@nlnetlabs.nl>
References: <20140127235149.GA18524@renesys.com>
 <52E7B2D8.4000301@nlnetlabs.nl>
Message-ID: <20140128145358.GA13366@gerg.ca>

On 28 January 2014, Willem Toorop said:
> Hi Greg,
> 
> Interesting idea.  I'll give it a shot shortly...

Awesome, thank you!

Vaguely related: I have a patch to fix some typos and grammar in
README. Could not find instructions for contributing. Should I email
you the patch?

       Greg
-- 
Greg Ward                            http://www.gerg.ca
<greg at gerg.ca>                       @gergdotca


From willem at nlnetlabs.nl  Tue Jan 28 22:38:05 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 28 Jan 2014 23:38:05 +0100
Subject: [ldns-users] drill -T with CNAMEs
In-Reply-To: <20140128145358.GA13366@gerg.ca>
References: <20140127235149.GA18524@renesys.com>
 <52E7B2D8.4000301@nlnetlabs.nl> <20140128145358.GA13366@gerg.ca>
Message-ID: <52E8314D.6030602@nlnetlabs.nl>

Hi Greg,

There is a drill that follows CNAMEs in the develop branch of the git
repository:

~/repos/ldns$ drill/drill -T www.microsoft.com
.	518400	IN	NS	k.root-servers.net.
.	518400	IN	NS	g.root-servers.net.
.	518400	IN	NS	d.root-servers.net.
.	518400	IN	NS	f.root-servers.net.
.	518400	IN	NS	j.root-servers.net.
.	518400	IN	NS	m.root-servers.net.
.	518400	IN	NS	e.root-servers.net.
.	518400	IN	NS	b.root-servers.net.
.	518400	IN	NS	l.root-servers.net.
.	518400	IN	NS	i.root-servers.net.
.	518400	IN	NS	c.root-servers.net.
.	518400	IN	NS	a.root-servers.net.
.	518400	IN	NS	h.root-servers.net.
com.	172800	IN	NS	g.gtld-servers.net.
com.	172800	IN	NS	a.gtld-servers.net.
com.	172800	IN	NS	h.gtld-servers.net.
com.	172800	IN	NS	m.gtld-servers.net.
com.	172800	IN	NS	d.gtld-servers.net.
com.	172800	IN	NS	b.gtld-servers.net.
com.	172800	IN	NS	l.gtld-servers.net.
com.	172800	IN	NS	f.gtld-servers.net.
com.	172800	IN	NS	c.gtld-servers.net.
com.	172800	IN	NS	e.gtld-servers.net.
com.	172800	IN	NS	k.gtld-servers.net.
com.	172800	IN	NS	i.gtld-servers.net.
com.	172800	IN	NS	j.gtld-servers.net.
microsoft.com.	172800	IN	NS	ns3.msft.net.
microsoft.com.	172800	IN	NS	ns1.msft.net.
microsoft.com.	172800	IN	NS	ns5.msft.net.
microsoft.com.	172800	IN	NS	ns2.msft.net.
microsoft.com.	172800	IN	NS	ns4.msft.net.
www.microsoft.com.	3600	IN	CNAME	toggle.www.ms.akadns.net.
net.	172800	IN	NS	a.gtld-servers.net.
net.	172800	IN	NS	b.gtld-servers.net.
net.	172800	IN	NS	c.gtld-servers.net.
net.	172800	IN	NS	d.gtld-servers.net.
net.	172800	IN	NS	e.gtld-servers.net.
net.	172800	IN	NS	f.gtld-servers.net.
net.	172800	IN	NS	g.gtld-servers.net.
net.	172800	IN	NS	h.gtld-servers.net.
net.	172800	IN	NS	i.gtld-servers.net.
net.	172800	IN	NS	j.gtld-servers.net.
net.	172800	IN	NS	k.gtld-servers.net.
net.	172800	IN	NS	l.gtld-servers.net.
net.	172800	IN	NS	m.gtld-servers.net.
akadns.net.	172800	IN	NS	ns1-129.akadns.net.
akadns.net.	172800	IN	NS	ns2-129.akadns.net.
akadns.net.	172800	IN	NS	ns17-133.akadns.org.
akadns.net.	172800	IN	NS	a3-129.akadns.net.
akadns.net.	172800	IN	NS	a11-129.akadns.net.
akadns.net.	172800	IN	NS	a9-128.akadns.net.
akadns.net.	172800	IN	NS	a5-130.akadns.org.
akadns.net.	172800	IN	NS	a4-131.akadns.org.
akadns.net.	172800	IN	NS	a10-128.akadns.org.
akadns.net.	172800	IN	NS	a28-129.akadns.org.
toggle.www.ms.akadns.net.	300	IN	CNAME	g.www.ms.akadns.net.
g.www.ms.akadns.net.	300	IN	CNAME	lb1.www.ms.akadns.net.
lb1.www.ms.akadns.net.	300	IN	A	65.55.57.27

Does not work with DNSSEC Trace yet.

You can sent patches to me personally, or file a bug report (with the
patch as attachment) here: http://www.nlnetlabs.nl/ldns/bugs

-- Willem

op 28-01-14 15:53, Greg Ward schreef:
> On 28 January 2014, Willem Toorop said:
>> Hi Greg,
>>
>> Interesting idea.  I'll give it a shot shortly...
> 
> Awesome, thank you!
> 
> Vaguely related: I have a patch to fix some typos and grammar in
> README. Could not find instructions for contributing. Should I email
> you the patch?
> 
>        Greg
> 



From greg at gerg.ca  Wed Jan 29 14:48:08 2014
From: greg at gerg.ca (Greg Ward)
Date: Wed, 29 Jan 2014 09:48:08 -0500
Subject: [ldns-users] drill -T with CNAMEs
In-Reply-To: <52E8314D.6030602@nlnetlabs.nl>
References: <20140127235149.GA18524@renesys.com>
 <52E7B2D8.4000301@nlnetlabs.nl> <20140128145358.GA13366@gerg.ca>
 <52E8314D.6030602@nlnetlabs.nl>
Message-ID: <20140129144808.GA6353@renesys.com>

On 28 January 2014, Willem Toorop said:
> There is a drill that follows CNAMEs in the develop branch of the git
> repository:

Perfect, thank you! That's exactly what I was hoping for. You've saved
me many hours.

> You can sent patches to me personally, or file a bug report (with the
> patch as attachment) here: http://www.nlnetlabs.nl/ldns/bugs

They're pretty minor changes, so I just emailed them to you privately.

       Greg


From greg at gerg.ca  Wed Jan 29 23:39:47 2014
From: greg at gerg.ca (Greg Ward)
Date: Wed, 29 Jan 2014 18:39:47 -0500
Subject: [ldns-users] More info from drill -T
Message-ID: <20140129233946.GA15101@renesys.com>

Hi again --

drill -T is working great with the new "follow CNAMEs" feature --
thanks, Willem!

But I find myself wanting more info for two distinct reasons.

1) "nxdomain" errors are not obvious in trace mode. E.g.

   $ drill -T this-is-a-bogus-domain.net
   .       518400  IN      NS      c.root-servers.net.
   .       518400  IN      NS      h.root-servers.net.
   [...]
   net.    172800  IN      NS      j.gtld-servers.net.
   net.    172800  IN      NS      i.gtld-servers.net.
   [...]
   net.    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1391037622 1800 900 604800 86400

   There's no explicit "NXDOMAIN" indicator, like you get from "drill" without -T.
   Increasing the verbosity doesn't help:

   $ drill -T -V5 this-is-a-bogus-domain.net | grep rcode:
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0

2) It's hard (impossible?) to tell how lines of output correspond to
   DNS query/response packets without using -V5, and that gives a
   flood of uninteresting additional data. (Including reverse lookups
   of some of the nameservers that we hit along the way!)

It appears that the ";; " lines that are useful with normal drill (and
dig) output are, ummm, not so useful in trace mode. Is this a known
bug? Or am I missing something (like, that's a feature)?

Thanks --

       Greg


From jn at stusta.de  Thu Jan 30 00:11:49 2014
From: jn at stusta.de (Johannes Naab)
Date: Thu, 30 Jan 2014 01:11:49 +0100
Subject: [ldns-users] More info from drill -T
In-Reply-To: <20140129233946.GA15101@renesys.com>
References: <20140129233946.GA15101@renesys.com>
Message-ID: <52E998C5.4070208@stusta.de>

On 2014-01-30 00:39, Greg Ward wrote:
> Hi again --
> 
> drill -T is working great with the new "follow CNAMEs" feature --
> thanks, Willem!
> 
> But I find myself wanting more info for two distinct reasons.
> 
> 1) "nxdomain" errors are not obvious in trace mode. E.g.
> 
>    $ drill -T this-is-a-bogus-domain.net
>    .       518400  IN      NS      c.root-servers.net.
>    .       518400  IN      NS      h.root-servers.net.
>    [...]
>    net.    172800  IN      NS      j.gtld-servers.net.
>    net.    172800  IN      NS      i.gtld-servers.net.
>    [...]
>    net.    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1391037622 1800 900 604800 86400
> 
>    There's no explicit "NXDOMAIN" indicator, like you get from "drill" without -T.
>    Increasing the verbosity doesn't help:
> 
>    $ drill -T -V5 this-is-a-bogus-domain.net | grep rcode:
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
> 
> 2) It's hard (impossible?) to tell how lines of output correspond to
>    DNS query/response packets without using -V5, and that gives a
>    flood of uninteresting additional data. (Including reverse lookups
>    of some of the nameservers that we hit along the way!)
> 
> It appears that the ";; " lines that are useful with normal drill (and
> dig) output are, ummm, not so useful in trace mode. Is this a known
> bug? Or am I missing something (like, that's a feature)?
> 
> Thanks --
> 
>        Greg


Hi,

While we are a drill -T, the output for reverse lookups seems a bit off:

Some queries are repeated, and some names are prefixed with the
authoritive name server name.

(And the man is wrong, the type argument is used)

% drill -v; drill -T 8.8.8.8.in-addr.arpa. ptr
drill version 1.6.12 (ldns version 1.6.16)
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.


in-addr.arpa.	172800	IN	NS	d.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	b.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	e.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	c.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	f.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	a.in-addr-servers.arpa.
8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
ns1.level3.net.8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
ns2.level3.net.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
ns1.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
ns2.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
ns4.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
ns3.google.com.8.8.8.8.in-addr.arpa.	86400	IN	PTR
google-public-dns-a.google.com.


Best regards,
Johannes

-- 


From willem at nlnetlabs.nl  Thu Jan 30 08:41:42 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 30 Jan 2014 09:41:42 +0100
Subject: [ldns-users] More info from drill -T
In-Reply-To: <20140129233946.GA15101@renesys.com>
References: <20140129233946.GA15101@renesys.com>
Message-ID: <52EA1046.6080406@nlnetlabs.nl>

Yes, I've noticed this myself before.  I'll have a look.  It would also
be interesting to see the outgoing queries (to see which NS path has
been followed) in some sort of short form; maybe with verbosity set to 4
or so.
-- Willem

op 30-01-14 00:39, Greg Ward schreef:
> Hi again --
> 
> drill -T is working great with the new "follow CNAMEs" feature --
> thanks, Willem!
> 
> But I find myself wanting more info for two distinct reasons.
> 
> 1) "nxdomain" errors are not obvious in trace mode. E.g.
> 
>    $ drill -T this-is-a-bogus-domain.net
>    .       518400  IN      NS      c.root-servers.net.
>    .       518400  IN      NS      h.root-servers.net.
>    [...]
>    net.    172800  IN      NS      j.gtld-servers.net.
>    net.    172800  IN      NS      i.gtld-servers.net.
>    [...]
>    net.    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1391037622 1800 900 604800 86400
> 
>    There's no explicit "NXDOMAIN" indicator, like you get from "drill" without -T.
>    Increasing the verbosity doesn't help:
> 
>    $ drill -T -V5 this-is-a-bogus-domain.net | grep rcode:
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
>    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
> 
> 2) It's hard (impossible?) to tell how lines of output correspond to
>    DNS query/response packets without using -V5, and that gives a
>    flood of uninteresting additional data. (Including reverse lookups
>    of some of the nameservers that we hit along the way!)
> 
> It appears that the ";; " lines that are useful with normal drill (and
> dig) output are, ummm, not so useful in trace mode. Is this a known
> bug? Or am I missing something (like, that's a feature)?
> 
> Thanks --
> 
>        Greg
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users
> 



From willem at nlnetlabs.nl  Thu Jan 30 08:50:05 2014
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 30 Jan 2014 09:50:05 +0100
Subject: [ldns-users] More info from drill -T
In-Reply-To: <52E998C5.4070208@stusta.de>
References: <20140129233946.GA15101@renesys.com> <52E998C5.4070208@stusta.de>
Message-ID: <52EA123D.5020408@nlnetlabs.nl>

Hi Johannes,

Indeed very peculiar behaviour! Though it looks that I do not have to
look into this, as it appears to be fixed as a side-effect of
implementing the follow CNAME feature :)

$ drill/drill -T 8.8.8.8.in-addr.arpa. ptr
.	518400	IN	NS	a.root-servers.net.
.	518400	IN	NS	b.root-servers.net.
.	518400	IN	NS	c.root-servers.net.
.	518400	IN	NS	d.root-servers.net.
.	518400	IN	NS	e.root-servers.net.
.	518400	IN	NS	f.root-servers.net.
.	518400	IN	NS	g.root-servers.net.
.	518400	IN	NS	h.root-servers.net.
.	518400	IN	NS	i.root-servers.net.
.	518400	IN	NS	j.root-servers.net.
.	518400	IN	NS	k.root-servers.net.
.	518400	IN	NS	l.root-servers.net.
.	518400	IN	NS	m.root-servers.net.
in-addr.arpa.	172800	IN	NS	a.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	b.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	c.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	d.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	e.in-addr-servers.arpa.
in-addr.arpa.	172800	IN	NS	f.in-addr-servers.arpa.
8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.8.in-addr.arpa.	86400	IN	PTR	google-public-dns-a.google.com.

I have fixed the manpage.  Thanks!

Regards,

-- Willem

PS. I also noticed that the -d option does not work.

op 30-01-14 01:11, Johannes Naab schreef:
> Hi,
> 
> While we are a drill -T, the output for reverse lookups seems a bit off:
> 
> Some queries are repeated, and some names are prefixed with the
> authoritive name server name.
> 
> (And the man is wrong, the type argument is used)
> 
> % drill -v; drill -T 8.8.8.8.in-addr.arpa. ptr
> drill version 1.6.12 (ldns version 1.6.16)
> 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.
> 
> 
> in-addr.arpa.	172800	IN	NS	d.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	b.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	e.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	c.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	f.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	a.in-addr-servers.arpa.
> 8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
> 8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
> ns1.level3.net.8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
> ns2.level3.net.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
> ns1.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
> ns2.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
> ns4.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
> ns3.google.com.8.8.8.8.in-addr.arpa.	86400	IN	PTR
> google-public-dns-a.google.com.
> 
> 
> Best regards,
> Johannes



From jn at stusta.de  Thu Jan 30 13:48:19 2014
From: jn at stusta.de (Johannes Naab)
Date: Thu, 30 Jan 2014 14:48:19 +0100
Subject: [ldns-users] More info from drill -T
In-Reply-To: <52EA123D.5020408@nlnetlabs.nl>
References: <20140129233946.GA15101@renesys.com> <52E998C5.4070208@stusta.de>
 <52EA123D.5020408@nlnetlabs.nl>
Message-ID: <52EA5823.2000607@stusta.de>

Hi,

Indeed the CNAME branch fixes it.
Thanks for your work!

Best regards,
Johannes

On 2014-01-30 09:50, Willem Toorop wrote:
> Hi Johannes,
> 
> Indeed very peculiar behaviour! Though it looks that I do not have to
> look into this, as it appears to be fixed as a side-effect of
> implementing the follow CNAME feature :)
> 
> $ drill/drill -T 8.8.8.8.in-addr.arpa. ptr
> .	518400	IN	NS	a.root-servers.net.
> .	518400	IN	NS	b.root-servers.net.
> .	518400	IN	NS	c.root-servers.net.
> .	518400	IN	NS	d.root-servers.net.
> .	518400	IN	NS	e.root-servers.net.
> .	518400	IN	NS	f.root-servers.net.
> .	518400	IN	NS	g.root-servers.net.
> .	518400	IN	NS	h.root-servers.net.
> .	518400	IN	NS	i.root-servers.net.
> .	518400	IN	NS	j.root-servers.net.
> .	518400	IN	NS	k.root-servers.net.
> .	518400	IN	NS	l.root-servers.net.
> .	518400	IN	NS	m.root-servers.net.
> in-addr.arpa.	172800	IN	NS	a.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	b.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	c.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	d.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	e.in-addr-servers.arpa.
> in-addr.arpa.	172800	IN	NS	f.in-addr-servers.arpa.
> 8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
> 8.8.8.8.in-addr.arpa.	86400	IN	PTR	google-public-dns-a.google.com.
> 
> I have fixed the manpage.  Thanks!
> 
> Regards,
> 
> -- Willem
> 
> PS. I also noticed that the -d option does not work.
> 
> op 30-01-14 01:11, Johannes Naab schreef:
>> Hi,
>>
>> While we are a drill -T, the output for reverse lookups seems a bit off:
>>
>> Some queries are repeated, and some names are prefixed with the
>> authoritive name server name.
>>
>> (And the man is wrong, the type argument is used)
>>
>> % drill -v; drill -T 8.8.8.8.in-addr.arpa. ptr
>> drill version 1.6.12 (ldns version 1.6.16)
>> 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.
>>
>>
>> in-addr.arpa.	172800	IN	NS	d.in-addr-servers.arpa.
>> in-addr.arpa.	172800	IN	NS	b.in-addr-servers.arpa.
>> in-addr.arpa.	172800	IN	NS	e.in-addr-servers.arpa.
>> in-addr.arpa.	172800	IN	NS	c.in-addr-servers.arpa.
>> in-addr.arpa.	172800	IN	NS	f.in-addr-servers.arpa.
>> in-addr.arpa.	172800	IN	NS	a.in-addr-servers.arpa.
>> 8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
>> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
>> 8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
>> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
>> ns1.level3.net.8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
>> 8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
>> ns2.level3.net.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
>> ns1.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
>> ns2.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
>> ns4.google.com.8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
>> 8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
>> ns3.google.com.8.8.8.8.in-addr.arpa.	86400	IN	PTR
>> google-public-dns-a.google.com.
>>
>>
>> Best regards,
>> Johannes
> 


--