From willem at nlnetlabs.nl Fri Jan 3 14:42:34 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 03 Jan 2014 15:42:34 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 0.74 Message-ID: <52C6CC5A.8000806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS. We have a Net::DNS 0.73_2 developers release which is a release candidate for Net::DNS 0.74. In this release a pressing bug introduced in the 0.73 release is resolved. This bug caused the algorithm name of TSIG RR?s to be non-standard rendering TSIG support dysfunctional. Besides bugfixes, this release also includes the CAA, EUI48 and EUI64 RR types. For a complete list of bugfixes see Changes below. Please let us know if anything is wrong. If all is well, the actual release will follow the 10th of January 2014. Best regards, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-0.73_2.tar.gz sha1: b968393b433a74b420954530b2146cfb0cee7a16 Changes ======= Fix rt.cpan.org #91306 Nameserver crashes on malformed UDP query. Fix rt.cpan.org #91241 TSIG: Fix incorrectly generated %algbyval table. Feature Add CAA, EUI48 and EUI64 RR implementation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxsxWAAoJEOX4+CEvd6SYEikQAIIC7AnjoklWBHikAMQb2ipz 8GUM4Jto9sGrBm0UURrjKHnmvRo85umgSHK42JqJw+3sbrG64RbgDKkZ7t/y9KiN hfPt3s7OijMqr3zy04z3IuIkKQvdCwJcoJIV9hL3XysPnyO9aaAu3vuf6kKlnur9 1rP0qmReCnpdE5fVN6iFAQr+dMMIVNxcVotvKs5NMT0F8DSJSL9bXnSg0dCt5JL9 Yc3iisZMV552BT+bpI5w+B14Czug2VtGVdIY9xVSTEM9vIiW4lTP4esBnt2l7o+w RiM8HnA+MmbGjYxnvd0IiNTa87QhxD1mbb1wnLjrQxMpUu2pblQrYJsQJta4pXBw i4NCfZPcWnjZKMDBHu5mrCOIC8wTveC4sAKOWQEJxtoPr+cEO0slZ58AI7CUZo/r xImVDK0ojON3FS+w/ZTbqPHDWcfqO8roEf5o8zmwtQO5yt5WgZSLjLrLXDtqdnux 79ypb/wX/yW21Zv1dLxsfq5f33gA2JpRvJq++/A6vU5sOqNJkE5ncUrgsV410amF w8JnEyzpUviEAtsLZdX3visU+6nDj7m5SG9qFveaRuHSRxVCD1FPWiP+yP/sBMkO ooxGmsp1z7EWzZ36O8bmNMUnObsORmS2ROKeCFgPcauvVIzzCHJfWQf7nudXXIGA HIx4uEEuvvQIxWC94/7u =gve2 -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Tue Jan 14 11:19:07 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 14 Jan 2014 12:19:07 +0100 Subject: [net-dns-users] Another release candidate for Net::DNS 0.74 Message-ID: <52D51D2B.5060003@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS. It has come to our attention that the previous release candidate was not working at all on older versions of perl < 5.6. Also a, taint preservation issue with perl versions 5.8.x was noticed. To resolve, minor modifications to the previous release candidate have been made. We believe those modifications are safe and don't change any behaviour on the unaffected perl versions. However, I do not want to release without opportunity for review from the community. Please review this update carefully. Because of the little changes and the pressing TSIG issue, the actual release will now follow Thursday the 16th of January 2014. Best regards, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-0.73_5.tar.gz sha1: 9b8dd3fe2adc5ceb806f08ec6ea94a7f4bd44397 Changes ======= Fix rt.cpan.org #91306 Nameserver crashes on malformed UDP query. Fix rt.cpan.org #91241 TSIG: Fix incorrectly generated %algbyval table. Feature Add CAA, EUI48 and EUI64 RR implementation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS1R0iAAoJEOX4+CEvd6SYSggQAILSf06EWRMEuPfWtvS9ey/d 0EsPtqbPbd/e9TjwtNZev8pfTedyL1ST14AdhMDVW+giFOVbHIRtjXgORA73+uin wrsXqVVPMC96cIyD0j6piSWeTZqeCo6rqNlpyIQ8dzK0Kk6TFD9QJ2y4vV2aPo7x HWpiDJZEwtLooYBbudc3933UwfPmss74x0PXhGonms9Wt4KkULRZWZFbFrhclVBO xuY/C/2kSlKi1yCMDhkdOy/Q++VMtQquKxaNOu86zPUmrRiiHg2m/o/kH+VO5m40 4MZqpeKIkGm98BXz5sGpdQkCVZzSq57xx+hs3r32/0pFLpyWtW5TDHXTM9YYZv9q faeJYWGg849VPfWceJuWvGFUvB6Lp1H76ixGGNu2b2GWfpFHF4yUY922v+jqil1i wSF/Rq6tsoLIqLS2e2Aa3HLCmZOWlxZf9DuQhQKZY1L/87gkcWgppwH9Whq+umze fnvZk/ciTSnInAn5tsl7xVwN0TTwK06rCEtFQh/4J3n0tV3F+7Y+fuD4y8A3AZAo Rbjg8ClhM0vKqwG/a5w5RaN3YgOdIt/zWS5461bY//Yl83F6DN847rlFoQ9uCflT VcNckkVlfIqpp4ONVnwT1oxX/jnG0QweNjaZSiV7EJWg1OcLD8T1b9BG2LHzn+wH TEvTmcyYkCL9mL2gP9oZ =BWs4 -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu Jan 16 10:27:59 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 16 Jan 2014 11:27:59 +0100 Subject: [net-dns-users] Net::DNS 0.74 released Message-ID: <52D7B42F.2080303@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS and Net::DNS::SEC, I am pleased to announce the release of Net::DNS 0.74. In this release a pressing bug introduced in the 0.73 release is resolved. This bug caused the algorithm name of TSIG RR?s to be non-standard rendering TSIG support dysfunctional. Besides bugfixes, this release also includes the CAA, EUI48 and EUI64 RR types. Also operation with older versions of perl has been improved. For a complete list of changes see the Changes section below. Best regards, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-0.74.tar.gz sha1: 1b183448d22ea49bca0c4b85c365af527101a2ae Changes ======= Fix rt.cpan.org #91306 Nameserver crashes on malformed UDP query. Fix rt.cpan.org #91241 TSIG: Fix incorrectly generated %algbyval table. Feature Add CAA, EUI48 and EUI64 RR implementation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS17QrAAoJEOX4+CEvd6SY6WEP/ji9+H3J4zXx6BwykVX1ls1j nv7L2NHzEoc03J8EaWz0cAcTuLnZ41IZRzOeqyuHK8v/gLOcX/rsB6P0f9VlVcqm lKqrN1JMuTv3dr3+2jiLnMWszVjnnUwR3hQKJR/O6IVDcllWtI6MhT0dcW20ZdU6 R+/1yMj4RHTO6kKEeZ0FniYLgUAGm+Rs8MCXyNvJACXe0JDEpVmF2lYFQX5/OCXZ AZssh5T1l1dh8lfIgt5yMbDEV5tGC34QeKsLcTirghtG/ZsFoBQYT1cgxWbA5s8j Wn47+ZTbhJaZ2p43YNRuc71Uwx0Db//x56TxrBG1eLDWeNfFihZAoaSyKLB/Fh76 e0TLGA6nrfGqSTnvVZvRtrmZuYDa+xDzBiXAsEGGWyztS6Mzao6SPicBh9sPrI2a 9wAFu+WHChMyZHExPu4pxB8Wf9tbFLE1q0RxaaH9q3ldyMdNo1voJIZl4GCyK1cK K/W/WU6lZZOovTmq6CAF4aE4hBS+Drd8HJ2rVjDtQUQ11FgK3rSdaUcOlQieeTVD r38jFrzAkOuZmrR4VUZusks9BuPD2d/cKQnkZjlLVFxmK5Ne1WPAxX7xR28uXetp EyCR4IiOAqKbCK5ACx8DGZlZ0dYdeUtiJShhfTgPW8FR2t7QtfoEiXorEUKe6k+/ q37GhsUI2MJoMdE1OAAR =QJLq -----END PGP SIGNATURE----- From filip at hajny.net Mon Feb 10 10:43:50 2014 From: filip at hajny.net (=?utf-8?Q?Filip_Hajn=C3=BD?=) Date: Mon, 10 Feb 2014 11:43:50 +0100 Subject: [net-dns-users] bug in rr_add or breaking change in 0.69? Message-ID: Hi guys, a customer reported a breaking change in how Net::DNS behaves, as we updated our packages past 0.68. I?ve isolated the change to r1025 (and 0.69). Given the following script: use Net::DNS; use Data::Dumper; $Data::Dumper::Indent = 1; $Data::Dumper::Sortkeys = 1; $update = Net::DNS::Update->new('example.com'); $update->push(update => rr_add('host.example.com. A 10.5.5.5')); print Dumper($update->authority); In 0.68, it used to yield: $VAR1 = bless( { 'address' => '10.5.5.5', 'class' => 'IN', 'name' => 'host.example.com', 'rdata' => '', 'rdlength' => 0, 'ttl' => 86400, 'type' => 'A' }, 'Net::DNS::RR::A' ); Whereas since r1025, the output is: $VAR1 = bless( { 'address' => ' ', 'class' => 'IN', 'name' => 'host.example.com', 'owner' => bless( { 'label' => [ 'host', 'example', 'com' ], 'name' => 'host.example.com' }, 'Net::DNS::DomainName1035' ), 'ttl' => 86400, 'type' => 'A' }, 'Net::DNS::RR::A' ); The customer expects the address returned to contain the IP address, but seems it hold a linebreak in 0.69 (I?ve also seen a gibberish character there in an odd case, which suggests there might be problem with coding/decoding). This happens both on SmartOS (an Illumos/SunOS fork) and OS X. Is there a problem to look into? -F From Ray.Walker at nau.edu Thu Mar 6 21:18:13 2014 From: Ray.Walker at nau.edu (Raymond Drew Walker) Date: Thu, 6 Mar 2014 21:18:13 +0000 Subject: [net-dns-users] NS & DS record issues Message-ID: I?ve been trying to perform some zone record cleanup after it?s deletion and ran into two interesting issues. (Using BIND9 for DNS) One: Though not queryable, a parent zone still contain NS records for a child zone even after the removal of the zone? which is seemingly not able to be queried. $name = ?child.zone?; $type = ?NS?; my $res = Net::DNS::Resolver->new; $res->nameservers($server); $res->port($port); $res->recurse(1); $res->debug(1); my $packet = $res->send($name, $type); Is there a method to retrieve this record information? Also, how to delete these? One: For removal of DS records, I receive a FORMERR for this type of resource record delete: $update->push("update", rr_del("child.zone DS 56419 5 2 d36a214f569acb874fe5911f91ed82a90c59c056c2c62e356d621bd064c3a8ad?); I can delete all DS records by omitting the record data just fine, but what it the appropriate method to delete a particular DS record? ? Raymond Walker Software Systems Engineer StSp. ITS - Northern Arizona University -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Sun Mar 23 18:05:29 2014 From: rwfranks at acm.org (Dick Franks) Date: Sun, 23 Mar 2014 18:05:29 +0000 Subject: [net-dns-users] NS & DS record issues In-Reply-To: References: Message-ID: On 6 March 2014 21:18, Raymond Drew Walker wrote: [snip] > > For removal of DS records, I receive a FORMERR for this type of resource > record delete: > > $update->push("update", rr_del("child.zone DS 56419 5 2 > d36a214f569acb874fe5911f91ed82a90c59c056c2c62e356d621bd064c3a8ad?); > > Can't find string terminator '"' anywhere before EOF at /tmp/delete_DS.pl line 7. > I can delete all DS records by omitting the record data just fine, but > what it the appropriate method to delete a particular DS record? > > As documented http://search.cpan.org/~nlnetlabs/Net-DNS-0.74/lib/Net/DNS.pm#rr_del -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Wed Apr 30 14:14:15 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 30 Apr 2014 16:14:15 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 0.75 Message-ID: <53610537.8000804@nlnetlabs.nl> Dear all, We have a Net::DNS 0.74_4 developers release which is a release candidate for Net::DNS 0.75. This is mostly a bugfix release. Besides bug fixes, this release also enables TSIG verified zone transfers. For details see Changes below. Please let us know if anything is wrong. If all is well the actual 0.75 release will follow the 7th of May 2014. Best regards, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-0.74_4.tar.gz sha1: 8f91738b510df47f59aece207ea0903ae0c4c2ce Changes ======= Fix rt.cpan.org #94069 Compile-time constant in Domain.pm/Text.pm cannot be used to store pointer to encoding object when using perlcc compiler. Thanks are due to Reini Urban for testing the revised code. Fix rt.cpan.org #93764 Resolver gives unhelpful errorstring when attempting to use IPv6-only nameserver without INET6 and Socket6 installed. Fix rt.cpan.org #92626 Clarify documentation surrounding SRV RR sorting Feature Implement TSIG verified zone transfer. Fix rt.cpan.org #92433 & #91241 TSIG: implement sign/verify for multi-packet message. Fix rt.cpan.org #79569 Iterate nameservers in AXFR From willem at nlnetlabs.nl Thu May 1 07:56:54 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 01 May 2014 09:56:54 +0200 Subject: [net-dns-users] Net::DNS::SEC release candidate for 0.18 - REVIEW THOROUGHLY Message-ID: <5361FE46.5050709@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS and Net::DNS::SEC, We have a candidate for the upcoming 0.18 release of Net::DNS::SEC. Besides bug fixes all Net::DNS::SEC RR types now fully exploit the new Net::DNS architecture that has been introduced since version 0.69 of Net::DNS. Because of this significant internal change, we urge you to *REVIEW THIS VERSION THOROUGHLY*. Software using the documented API and not accessing objects internal data structures should not be affected by this change. Please inform us of any problems your software has with this version so we can address it before release. If possible, please provide a *small* example illustrating different behavior on 0.17_5. For a complete list of changes and bugfixes see the Changes below. If no issues arise, the actual release will follow the 8th of May 2014. Best regards, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-SEC-0.17_5.tar.gz sha1: 6960d3fd2d9390a7a1b3bec5a83cc67f9288c038 Changes ======= Recode RR implementations to provide Net::DNS 0.69+ interface. Fix: rt.cpan.org #95034 Failure to parse NSEC3PARAM record with null salt Fix: rt.cpan.org #81289 Failure to handle GOST DS records -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTYf5BAAoJEOX4+CEvd6SY3DwQAItnlH2H+ipfadZqpvaErsNP vHGIir+vRG9bKGu9v9HCVG6IBPMl5qIW2pgCkiSRJQXsYc887G4U0XFJ/HtVKlNu 6woaBjU6GHLmHa6uMCBwjFe0lYpK4aO+tupCXXRdTI6HwIhjpsgrd2aDlnF6yPRV kHzLGUQ+JvCDsi/06kDXnfLem/dIE4YTqBuzKyU840AnpTEIAZCkPZvIniphKFTd bzJaylNlvtyEYDpQ4w2JyEqo66qW2DJ4WfDVTq4qjCjFBTBzi+DP8eik734srTOP qNAy2m7tz71dOIRYC+aAvBpIVIFh7GznCpk+VtQJo+CXZ0m2CDVJ7Z0HmrRlsS1v qRLhqewkXbz+tG3YuOb8TBWXOUtxSdTaIjY7ejdmlEPAVLEHMP++UjQy51xzt0TN LPs7jSLNhATutaLoRofrSNCzbCG0akCRfEBYuwis/NznWN2OdWVTHqjvnGndpiZG SLW2TUYa+5qLH/UldLzMdjjML5AF1WWYhVvJE/U+RvoSIeFPQCq8ZtpQSBvcrqM4 PR3Q1+m34iLWdfUpxNXooxuS/awrmvf7SdlPlQL3Nn83h5PvOvCZMNXWCEMtgQEh Vc++GQLc6dQwRy+U+aWXxbnWqTWWX5CwNyZqF6T7TUdFtzBKluYLh2l5u8JZMcPw ORzM1J+otsfrj1qX8L9h =gEHV -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu May 8 10:02:41 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 08 May 2014 12:02:41 +0200 Subject: [net-dns-users] Net::DNS 0.75 and Net::DNS::SEC 0.18 released Message-ID: <536B5641.1080109@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS and Net::DNS::SEC, I am pleased to announce the release of Net::DNS 0.75 and Net::DNS::SEC 0.18. The Net::DNS release is primarily concerned with bug fixes. Besides bugfixes Net::DNS 0.75 enables TSIG verified zone transfers. With the Net::DNS::SEC 0.18 release, all RR types now fully exploit the new Net::DNS architecture that has been introduced since version 0.69 of Net::DNS. Because of this change object internal data structures have changed. Software using the documented API and not accessing objects internal data structures should not be affected by this change. For a complete list of changes see the Changes sections below. link http://www.net-dns.org/download/Net-DNS-0.75.tar.gz sha1 e57d08cfe61962d9de3cd78ec705a954e05f36bd link http://www.net-dns.org/download/Net-DNS-SEC-0.18.tar.gz sha1 962938f05194cf6a90cef93ef3a587a7d0c8b87f Changes for Net::DNS 0.75 ========================= Fix rt.cpan.org #94069 Compile-time constant in Domain.pm/Text.pm cannot be used to store pointer to encoding object when using perlcc compiler. Thanks are due to Reini Urban for testing the revised code. Fix rt.cpan.org #93764 Resolver gives unhelpful errorstring when attempting to use IPv6-only nameserver without INET6 and Socket6 installed. Fix rt.cpan.org #92626 Clarify documentation surrounding SRV RR sorting Feature Implement TSIG verified zone transfer. Fix rt.cpan.org #92433 & #91241 TSIG: implement sign/verify for multi-packet message. Fix rt.cpan.org #79569 Iterate nameservers in AXFR Changes for Net::DNS::SEC 0.18 ============================== Recode RR implementations to provide Net::DNS 0.69+ interface. Fix: rt.cpan.org #95034 Failure to parse NSEC3PARAM record with null salt Fix: rt.cpan.org #81289 Failure to handle GOST DS records -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTa1Y9AAoJEOX4+CEvd6SYbWcP/iRfUUXjmImVwrnk+mcYabm2 ykbBufU/n1H8P3sbhnd5zPVo26Q57Cx/nErvg5pxDQM/zN7lUUIFUAnKJIbITg/F KWuRvmIGL3OYIXF5twBZWj3IkoUGzmNukDobL3JzHl28H0gMGTy4c+IFu24gE38l JQdyoR5sfgal1D9qqrXOrlqx4SOV0VXnNw0mn9omXlzETveQVWCrrQbZMrQ6ZirU 0534HgSklRxE6KfmRVfu7RJdmdE9BvZZUWDFTJV5Nv2t6LSwiF3X+K215N/lr1Ig AMNOA+I7nOWeKhjTP865KwTpVa32NGjjPww3wTg73zsmXsCS49dD3644ETcTfe96 4iTL0tfTeA2hmNZ72Cb7ZIFXkikE/rMbHT8Ivpa2fuH+CwPA3poc7rF0n8IgF0NT GA/AiqQT9pG0uV0ZzvHP9sLhYMh/wl2kXifwpSFM9YQ8Rw40W9h3OFrrdLW+MCIF v5p/4VMMti9Vxz/cPAO1TiLKhUaeDEwHG4uAXQBc/lxPDPdDKWCb6bnvGLkL3fsZ cN90Cqbvy/x4C/aLYAFtXU7J6uhK8YKF+3e64xSbCUYXqwEhzUHE3kU9/JgtjMg2 AYHMmhyfYyZUFkZevcyQZUXTX9QBrnwHAr6YpGQQEwJrzDBQv30+Ee7ccMsBN5I/ 3DX382m9v1t/JaWGnPeH =1xFk -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri May 23 22:48:08 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Sat, 24 May 2014 00:48:08 +0200 Subject: [net-dns-users] Net::DNS 0.76 Emergency Release Message-ID: <537FD028.3090509@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, We have an emergency release of Net::DNS version 0.76. Version 0.75 contained a bug in the parsing of /etc/resolv.conf by Net::DNS::Resolver objects. With this bug only the last ?nameserver? line in /etc/resolv.conf is evaluated and name servers specified on earlier ?nameserver? lines are discarded (See https://rt.cpan.org/Ticket/Display.html?id=95596 ). This could result in decreased availability of resolving capabilities on systems with multiple ?nameserver? lines in /etc/resolv.conf since only the name servers given on the last "nameserver" line will be targeted. Besides the aforementioned bug a few others have been resolved. For a complete list see the Changes sections below. link http://www.net-dns.org/download/Net-DNS-0.76.tar.gz sha1 b4cb71eee79b1fc4946fa089741d5992e1a4f122 Changes for Net::DNS 0.76 ========================= Fix rt.cpan.org #95738 Test failure with IPv6 address in resolver.conf but without prerequisite IO::Socket::INET6 package installed. Fix rt.cpan.org #95596 Incorrect parsing of nameserver lines in resolv.conf Feature rt.cpan.org #79568 Implement prefer_v6 resolver configuration attribute. Fix rt.cpan.org #67602 Set resolver configuration defaults at first instantiation instead of module load time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTf9AoAAoJEOX4+CEvd6SYAgsP/i1sIUEypvX5uqBQtxPWXBNl J+eKmdU9a4IrzwTmMpCgoWbRlOk0xlPNQ+1HuO6OnyJr9C6m6sFA37loGeTt9Zhe WSmpgGx9bdb+D/jKIxq/MR+vrGKoyfSJJPox4LWDC7t0IZ3c+kYWtr3C5lc1vQW7 afcUK7juN0v1HUNq+qR/TkBT4YQjxX7qee68nQmM81Qy6BifWhUmFkdYI6YOOSby uWaV77bAFjKFmXrGxaS3yL7Tk3YepVJ0aMwIcbDte5xFvZpDSTjERZIxq1PyDEX9 k+NpROXSjIrQs1LW57fs9PhHciIjHYhwoUMqnUrs9btW3ARBLrdN7oiCKPvjVaaR ki9lMXfsF4qVK+A0ZRjf9PFI1OpDdKUygZxv+ZcXxUnoHZ+yxTyLEAiZsXLngvkP opEVdwfJsS6Z6AQrhhzEY+NB1ryIqcSgc24HP5ZuyKBIXM1ZLpkcHtG+GewFwwC7 kAWWoj8Bgdl8+8DtdPS1l9WsXaEig/KqfwJTIwv9VaR9aurNO4vdMIbwDSpswxRK WqUYYZmpAiILMvW9o964gmSdjJkdVG8PfdhL3XvvKPOUAA0fGRSxV4Zw8aBOtfOm ViOF/a5zEThK516eXrhj2M3BaJJUaCaCtvoz/ylQ0piXbDlKU2uO3Rgy5Q7vhBtr GDstEjJFE4FOtlyIT7Mu =KWBC -----END PGP SIGNATURE----- From calle at init.se Tue May 27 12:42:04 2014 From: calle at init.se (Calle Dybedahl) Date: Tue, 27 May 2014 14:42:04 +0200 Subject: [net-dns-users] sep() and is_sep() Message-ID: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> Hello. Net::DNS::SEC v0.18 deprecates the is_sep() method in Net::DNS::RR::DNSKEY, and emits a warning if it is used. This is easily fixed, of course, but if one does the resulting code no longer works at all with Net::DNS::SEC 0.17 and older. This change was not mentioned in the release announcement for Net::DNS 0.75 and Net::DNS::SEC 0.18. The most recent mention of the is_sep() method in Net::DNS::SEC?s Changes file is from 2005. Given the extraordinary weight that Net::DNS usually places on backwards compatibility, I find this change quite surprising. I cannot quite figure out what is the intended course of action for users of Net::DNS::SEC here. Are we supposed to force our own users to upgrade to 0.18? Not change our code, and let those who do upgrade Net::DNS::SEC simply put up with the deprecation warnings? Fix our code to check which version is installed and use the proper method, depending? -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 From willem at nlnetlabs.nl Wed May 28 11:49:02 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 28 May 2014 13:49:02 +0200 Subject: [net-dns-users] sep() and is_sep() In-Reply-To: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> Message-ID: <5385CD2E.1080204@nlnetlabs.nl> Calle, Acknowledged. I think the best course of action for us would have been to: 1. Introduce the new functions that will replace old ones. The old functions should keep working the same as before (without printing warnings) 2. Release with a notification about the new function, and the fact that it will replace an old function. 3. Give users opportunity to switch to usage of the new function and adapt their dependency on the new module version. 4. Adapt the old function to print the deprecated warning and release again giving a warning about the function to be deprecated. We'll make sure to use this procedure with similar cases in the future. What would you like us to do now? Re-release with the warning removed? Now the damage has been done already, it might be just as easy for modules using Net::DNS::SEC to adapt and re-release with an updated dependency. What do you think? -- Willem op 27-05-14 14:42, Calle Dybedahl schreef: > Hello. > > Net::DNS::SEC v0.18 deprecates the is_sep() method in Net::DNS::RR::DNSKEY, and emits a warning if it is used. This is easily fixed, of course, but if one does the resulting code no longer works at all with Net::DNS::SEC 0.17 and older. > > This change was not mentioned in the release announcement for Net::DNS 0.75 and Net::DNS::SEC 0.18. The most recent mention of the is_sep() method in Net::DNS::SEC?s Changes file is from 2005. Given the extraordinary weight that Net::DNS usually places on backwards compatibility, I find this change quite surprising. > > I cannot quite figure out what is the intended course of action for users of Net::DNS::SEC here. Are we supposed to force our own users to upgrade to 0.18? Not change our code, and let those who do upgrade Net::DNS::SEC simply put up with the deprecation warnings? Fix our code to check which version is installed and use the proper method, depending? > From calle at init.se Wed May 28 12:16:19 2014 From: calle at init.se (Calle Dybedahl) Date: Wed, 28 May 2014 14:16:19 +0200 Subject: [net-dns-users] sep() and is_sep() In-Reply-To: <5385CD2E.1080204@nlnetlabs.nl> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> Message-ID: <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> On 28 maj 2014, at 13:49, Willem Toorop wrote: > What would you like us to do now? Re-release with the warning removed? > Now the damage has been done already, it might be just as easy for > modules using Net::DNS::SEC to adapt and re-release with an updated > dependency. What do you think? Given that it?s not that serious a problem (I?m guessing that not many people are interested in the is_sep() method, and of those who are even fewer are writing libraries for third-party use), I can?t think of a course of action that?s not more bother than it?s worth. So I?m fine with just leaving it at ?Oops, let?s try not to do that again?. At a practical level, what I?ve done in DNSCheck is to change the code to use sep() instead of is_sep(), and monkey-patch a sep() method into Net::DNS::RR::DNSKEY if the Net::DNS::SEC version is 0.17 or lower. It?s not a pretty solution, but it works, so I thought I?d mention it here in case someone else is in a similar situation. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 From job at abc.se Wed May 28 12:28:34 2014 From: job at abc.se (=?UTF-8?Q?Jonas_Bofj=C3=A4ll?=) Date: Wed, 28 May 2014 14:28:34 +0200 (CEST) Subject: [net-dns-users] Can not build 0.76 on Linux Message-ID: Net::DNS 0.76 from CPAN refuses to install using vanilla Perl 5.18.2 on Linux: [...] t/01-resolver-file.t ....... skipped: Could not read configuration file [...] t/10-recurse.t ............. 7/? # Tests were run but no plan was declared and done_testing() was not seen. t/10-recurse.t ............. Dubious, test returned 254 (wstat 65024, 0xfe00) More verbose testing gives: t/10-recurse.t ............. ok 1 - use Net::DNS::Resolver::Recurse; ok 2 - An object of class 'Net::DNS::Resolver::Recurse' isa 'Net::DNS::Resolver::Recurse' ok 3 - hints() set ok 4 - sanity check worked ok 5 - got a packet ok 6 - answer section has RRs ok 7 - got a packet ok 8 - answer section has RRs ok 9 - 'callback argument' isa 'Net::DNS::Packet' ok 10 - 'callback argument' isa 'Net::DNS::Packet' ok 11 - 'callback argument' isa 'Net::DNS::Packet' ok 12 - 'callback argument' isa 'Net::DNS::Packet' ok 13 - 'callback argument' isa 'Net::DNS::Packet' ok 14 - Lookup took 5 queries which is at least 3. # Tests were run but no plan was declared and done_testing() was not seen. Dubious, test returned 254 (wstat 65024, 0xfe00) All 14 subtests passed Version 0.75 installs without errors under the same circumstances (both tests return "ok"). // Jonas From rwfranks at acm.org Wed May 28 14:28:20 2014 From: rwfranks at acm.org (Dick Franks) Date: Wed, 28 May 2014 15:28:20 +0100 Subject: [net-dns-users] sep() and is_sep() In-Reply-To: <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> Message-ID: Calle makes a good point; and it was my fault entirely. The 3rd party back-compatibility issue did not cross my mind when I did that. Cleanest solution would be to reissue with warning removed. We can put it back when 0.17 get consigned to oblivion in BACKPAN. Messy workarounds always seem to find a way to bite someone, somewhere, eventually. Dick ________________________ On 28 May 2014 13:16, Calle Dybedahl wrote: > > On 28 maj 2014, at 13:49, Willem Toorop wrote: > > > What would you like us to do now? Re-release with the warning removed? > > Now the damage has been done already, it might be just as easy for > > modules using Net::DNS::SEC to adapt and re-release with an updated > > dependency. What do you think? > > Given that it?s not that serious a problem (I?m guessing that not many > people are interested in the is_sep() method, and of those who are even > fewer are writing libraries for third-party use), I can?t think of a course > of action that?s not more bother than it?s worth. So I?m fine with just > leaving it at ?Oops, let?s try not to do that again?. > > At a practical level, what I?ve done in DNSCheck is to change the code to > use sep() instead of is_sep(), and monkey-patch a sep() method into > Net::DNS::RR::DNSKEY if the Net::DNS::SEC version is 0.17 or lower. It?s > not a pretty solution, but it works, so I thought I?d mention it here in > case someone else is in a similar situation. > > -- > Calle Dybedahl > calle at init.se -*- +46 703 - 970 612 > > > > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From calle at init.se Mon Jun 2 07:31:47 2014 From: calle at init.se (Calle Dybedahl) Date: Mon, 2 Jun 2014 09:31:47 +0200 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> Message-ID: <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> On 28 maj 2014, at 16:28, Dick Franks wrote: > The 3rd party back-compatibility issue did not cross my mind when I did that. I just found that the interface to AXFR has also changed completely. Apart from the backwards compatibility issue, which is more difficult to patch around here than for sep/is_sep), I have two questions: 1) Without the concluding SOA record, how do I tell if the server sent me the whole zone or stopped in the middle? 2) Returning all RRs in a single list rather than giving me one at a time increases memory usage *a lot* for large zones. We have at least one application that does work on all 1.3 million records of .se, and while I have not yet done any measurements, it?s memory-constrained on its machine today and I?m pretty sure this change will make it unable to run at all. Suggestions? -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Mon Jun 2 10:52:01 2014 From: rwfranks at acm.org (Dick Franks) Date: Mon, 2 Jun 2014 11:52:01 +0100 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> Message-ID: On 2 June 2014 08:31, Calle Dybedahl wrote: > > I just found that the interface to AXFR has also changed completely. > Wild exaggeration. TSIG verification has been added. In all other respects, the API is unchanged. > 1) Without the concluding SOA record, how do I tell if the server sent me > the whole zone or stopped in the middle? > Returns a list of "Net::DNS::RR" objects, or empty list if the zone transfer failed. The redundant SOA record that terminates the zone transfer is not returned to the caller. [perldoc Net::DNS::Resolver] Although the perldoc for 0.68 says it returns undef if zone transfer failed, the code never actually did so. Neither statement is entirely accurate. If the axfr() fails to get started, an empty list is returned. If something went wrong in the middle, axfr() croaks. Arguably, an exception should be raised for both. Returning an empty list in both cases is unsatisfactory for the reasons you identified. 2) Returning all RRs in a single list rather than giving me one at a time > $res->axfr() has always returned a single list. The internal axfr_start() and axfr_next() return a packet. This is necessary to perform TSIG verification. > Suggestions? > Steal 25 lines from sub axfr and bend them to suit your application. You will then be living outside the API tent; but there is little risk that axfr_start() and axfr_next() will ever change, because the current behaviour is essential to perform TSIG verification. -------------- next part -------------- An HTML attachment was scrubbed... URL: From calle at init.se Mon Jun 2 12:34:43 2014 From: calle at init.se (Calle Dybedahl) Date: Mon, 2 Jun 2014 14:34:43 +0200 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> Message-ID: <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> On 2 jun 2014, at 12:52, Dick Franks wrote: > On 2 June 2014 08:31, Calle Dybedahl wrote: > > I just found that the interface to AXFR has also changed completely. > > Wild exaggeration. TSIG verification has been added. In all other respects, the API is unchanged. > In Net::DNS 0.74 there were methods in Net::DNS::Resolver called axfr_start and axfr_next. In 0.76 there no longer is. I do not agree that that counts as ?unchanged?. > The redundant SOA record that terminates the zone transfer is not returned > to the caller. > [perldoc Net::DNS::Resolver] > I?ve been working with another module for some time, and forgot about that. My apologies. > > 2) Returning all RRs in a single list rather than giving me one at a time > > $res->axfr() has always returned a single list. > > The internal axfr_start() and axfr_next() return a packet. This is necessary to perform TSIG verification. > Maybe so, but the external axfr_next() returned Net::DNS::RR objects. From the Net::DNS::Resolver documentation for 0.74: axfr_next $res->axfr_start('example.com'); while (my $rr = $res->axfr_next) { $rr->print; } Reads records from a zone transfer one at a time. We?ve been using code very close to that example to process the .SE zone with negligible memory usage. I have not tried to measure how much memory a list of 6.6 million RR objects would use, but I feel confident that it would not be negligible. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Mon Jun 2 19:05:09 2014 From: rwfranks at acm.org (Dick Franks) Date: Mon, 2 Jun 2014 20:05:09 +0100 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> Message-ID: On 2 June 2014 13:34, Calle Dybedahl wrote: > > In Net::DNS 0.74 there were methods in Net::DNS::Resolver called > axfr_start and axfr_next. In 0.76 there no longer is. I do not agree that > that counts as ?unchanged?. > > Your claim was that axfr() API had changed, which it has not. The primary purpose of both axfr_start() and axfr_next() is to support axfr(). If the requirements change inside there, inevitably they need to change. They have no independent life of their own. Change was clearly anticipated by somebody because the perldoc for 0.74 also contains a warning: IMPORTANT: This method currently returns the "IO::Socket::INET" object that will be used for reading, or "undef" on error. DO NOT DEPEND ON "axfr_start()" returning a socket object. THIS MIGHT CHANGE in future releases. And it just did. It is still there, but now it returns a packet, which contains the TSIG record, which cannot be verified without access to the original request packet. The logic is further complicated by the fact that the second and subsequent TSIG records cannot be verified unless its predecessor is also available. The only practical way to achieve this is for both axfr_start() and axfr_next() to return a packet which can be verified and then the RRs unpacked. Itteration over the RRs themselves is unnecessary for axfr() itself. If memory usage is your main objection, it would be sensible to know how big a problem that poses. As .SE is a TLD, about 50% of your 6.6M will be RRSIGs, almost everything else slightly smaller. Most of the space is occupied by the RR object hash, the RDATA is almost irrelevant. Upper bound memory useage estimate: 1350 . 6M6 = 8.9G bytes. Discouraging, but feasible on big hardware. Using axfr_start() and axfr_next() to get the packets and iterating over the RRs inside would seem to be the better option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From calle at init.se Tue Jun 3 06:41:50 2014 From: calle at init.se (Calle Dybedahl) Date: Tue, 3 Jun 2014 08:41:50 +0200 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> Message-ID: On 2 jun 2014, at 21:05, Dick Franks wrote: > Your claim was that axfr() API had changed, which it has not. > I meant the AXFR operation, not the exact axfr() method. > Change was clearly anticipated by somebody because the perldoc for 0.74 also contains a warning: > > IMPORTANT: > > This method currently returns the "IO::Socket::INET" object that will be > used for reading, or "undef" on error. DO NOT DEPEND ON "axfr_start()" > returning a socket object. THIS MIGHT CHANGE in future releases. > > And it just did. > That warning has been there for a very long time. Because of it I have always made sure not to use the return value from axfr_start() for anything other than true/false determination. Changing what axfr_start() returns is perfectly in accordance with long-standing documentation, and I have no issue with doing so. I do have an issue with removing the method from the documented public API. The warning does _not_ say that axfr_next() is similarly afflicted. The warning is specifically about what axfr_start() returns. Changing what axfr_next() returns is a change in the documented public API (as is removing it, obviously). > > If memory usage is your main objection, it would be sensible to know how big a problem that poses. > Well, the memory use is what makes Net::DNS versions 0.75 and 0.76 completely unusable for one of .SE?s current applications. It could in theory still work if moved to a server with much more RAM, but I hope you can understand that the argument ?We need to buy a new big server because Net::DNS changed their API? is not going to work very well. > Upper bound memory useage estimate: 1350 . 6M6 = 8.9G bytes. Devel::Size gives me about 3200 bytes for a Net::DNS::RR::RRSIG, so I think you estimate is low by at least half. Perl was not designed to be memory-efficient... > Using axfr_start() and axfr_next() to get the packets and iterating over the RRs inside would seem to be the better option. In Net::LDNS, we have a method that takes a code reference as its argument and runs that code once for every RR in the AXFR, with the RR object as its only argument. That way the method can keep as much state as it likes, and the amount of memory needed is unaffected by the number of records received. I find the interface clean and convenient to work with, but then I came up with it so I?m obviously biased in its favor. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Tue Jun 3 13:46:51 2014 From: rwfranks at acm.org (Dick Franks) Date: Tue, 3 Jun 2014 14:46:51 +0100 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> Message-ID: On 3 June 2014 07:41, Calle Dybedahl wrote: > > > The warning does _not_ say that axfr_next() is similarly afflicted. The > warning is specifically about what axfr_start() returns. Changing what > axfr_next() returns is a change in the documented public API (as is > removing it, obviously). > Internal method (and it *is* very obviously that) should never have had POD documentation in the first place. > Devel::Size gives me about 3200 bytes for a Net::DNS::RR::RRSIG, so I > think you estimate is low by at least half. Perl was not designed to be > memory-efficient... > > Unfortunately. My figure came from seeing how much free memory I had and running a ZoneFile $GENERATE until it fell over and counting the records as they were DESTROYed in RR.pm I cannot see why they were counted twice, assuming that is what happened. Whatever the actual figure, it is unworkable. > In Net::LDNS, we have a method that takes a code reference as its argument > and runs that code once for every RR in the AXFR, with the RR object as its > only argument. That way the method can keep as much state as it likes, and > the amount of memory needed is unaffected by the number of records > received. I find the interface clean and convenient to work with, but then > I came up with it so I?m obviously biased in its favor. > > Are you arguing for a per-RR call-back as an optional argument to axfr()? That way, you get your iteration done for free, we get the mechanics we need for TSIG. $resolver->axfr( 'example.com', 'IN', sub { my $rr = shift; ... } ); Q: Does the call-back function return anything? If so what do we do with it? <%2B46%20703%20-%20970%20612> -------------- next part -------------- An HTML attachment was scrubbed... URL: From calle at init.se Tue Jun 3 14:18:02 2014 From: calle at init.se (Calle Dybedahl) Date: Tue, 3 Jun 2014 16:18:02 +0200 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> Message-ID: <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> On 3 jun 2014, at 15:46, Dick Franks wrote: > > Internal method (and it *is* very obviously that) should never have had POD documentation in the first place. > I disagree. It was certainly not obvious to me. There was example code on how to use it, and it filled a need that the axfr() method does not. > Are you arguing for a per-RR call-back as an optional argument to axfr()? > Just mentioning that the current way is not the only possible way. What I wish right now is that the same dedication to backwards compatibility that is shown towards supporting ancient versions of Perl would be shown towards the API of Net::DNS itself. > That way, you get your iteration done for free, we get the mechanics we need for TSIG. > > $resolver->axfr( 'example.com', 'IN', sub { my $rr = shift; ... } ); > I put the class argument last, so I only have to spell it out in the very rare cases where it?s not IN. Other than that minor detail, that?s it exactly. > Q: Does the call-back function return anything? If so what do we do with it? Since one of the things we want to be able to do is to terminate a transfer before it?s complete (which can also not be done with the axfr() in Net::DNS::Resolver), I made that contingent on the return value from the callback. As long as it returns a true value, the process will continue (until it finishes naturally). If it returns false, the transfer will be stopped. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 -------------- next part -------------- An HTML attachment was scrubbed... URL: From olaf at NLnetLabs.nl Tue Jun 3 14:55:42 2014 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 3 Jun 2014 16:55:42 +0200 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> Message-ID: <9E4FC5CE-6C6F-4338-9730-467F2FA60E8C@NLnetLabs.nl> On 2 jun. 2014, at 21:05, Dick Franks wrote: > Change was clearly anticipated by somebody because the perldoc for 0.74 also contains a warning: > > IMPORTANT: > > This method currently returns the "IO::Socket::INET" object that will be > used for reading, or "undef" on error. DO NOT DEPEND ON "axfr_start()" > returning a socket object. THIS MIGHT CHANGE in future releases. > > And it just did. May 2002 this axfr_start feature was introduced. With the above warning. I cannot remember why and how that came in (whether it was a patch that was submitted at the time). Even though I have more or less zoomed out of Net::DNS maintenance I have to agree with Calle, this is a change. I see axfr_start/axfr_next as useful utility methods, not as internal methods. ?Olaf PS. Today I confessed to myself that I will have even less time for coding in the future than I have currently. I will withdraw myself as co-maintainer from the Net::DNS suite and unsubscribe myself from the list. Note that Net::DNS has institutional commitment by NLnet Labs. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 846 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dwessels at verisign.com Tue Jun 3 15:17:15 2014 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 3 Jun 2014 15:17:15 +0000 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> , <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> Message-ID: <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> > On Jun 3, 2014, at 7:19 AM, "Calle Dybedahl" wrote: > > I disagree. It was certainly not obvious to me. There was example code on how to use it, and it filled a need that the axfr() method does not. For whatever it's worth, my opinion matches Calle's. I've used axfr_start() and _next() and certainly didn't think they were internal methods. DW From rwfranks at acm.org Tue Jun 3 18:10:21 2014 From: rwfranks at acm.org (Dick Franks) Date: Tue, 3 Jun 2014 19:10:21 +0100 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> Message-ID: Unfortunately, we are in the tricky position where either a) we go back, and are unable to do TSIG zone transfers, or b) invent a better way of doing things that does TSIG and provides step-wise progression through a zone. The candidates so far are: 1) $res->axfr( 'example.com', sub { my $rr = shift; ... } ); # call-back 2) my @zone = $res->axfr( 'example.com' ); # whole zone as now my $iterator = $res->axfr( 'example.com' ); # interative solution while ( my $rr = $iterator->( ) ) { ... } Thoughts? Dick -------------- next part -------------- An HTML attachment was scrubbed... URL: From clists at buxtonfamily.us Tue Jun 3 18:49:44 2014 From: clists at buxtonfamily.us (Chris Buxton) Date: Tue, 3 Jun 2014 11:49:44 -0700 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> Message-ID: On Jun 3, 2014, at 11:10 AM, Dick Franks wrote: > Unfortunately, we are in the tricky position where either a) we go back, and are unable to do TSIG zone transfers, I'm curious, what was wrong with the implementation in 0.72? I've had to freeze my installations at that version, because later versions break my scripts. (Which is frustrating.) My scripts make heavy use of TSIG-signed zone transfers. Were the signatures not being validated before? On Jun 3, 2014, at 7:13 AM, Calle Dybedahi wrote: > What I wish right now is that the same dedication to backwards compatibility that is shown towards supporting ancient versions of Perl would be shown towards the API of Net::DNS itself. I agree. I couldn't care less about Perl 5.8. But breaking my script by releasing a new version of Net::DNS is a big problem for me. When you find a subroutine not working as intended, try to fix it without breaking the observed/documented behavior in other ways. Sometimes this is non-trivial to do, but it's important. If it cannot be done, don't fix the existing subroutine ? introduce a new method, deprecate the old method, and document the whole thing. We saw this before when the format used for printing SOA records was changed. I have to hack in a replacement subroutine for Net::DNS::RR::SOA::format_rdata that reinstates the old behavior. Regards, Chris Buxton From rwfranks at acm.org Tue Jun 3 20:32:23 2014 From: rwfranks at acm.org (Dick Franks) Date: Tue, 3 Jun 2014 21:32:23 +0100 Subject: [net-dns-users] AXFR (was: Re: sep() and is_sep()) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> Message-ID: On 3 June 2014 19:49, Chris Buxton wrote: [snip] > I'm curious, what was wrong with the implementation in 0.72? I've had to > freeze my installations at that version, because later versions break my > scripts. (Which is frustrating.) My scripts make heavy use of TSIG-signed > zone transfers. Were the signatures not being validated before? > No. The present difficulty arises from making that wish come true. I couldn't care less about Perl 5.8. But breaking my script by releasing a > new version of Net::DNS is a big problem for me. > Some do care > When you find a subroutine not working as intended, try to fix it without > breaking the observed/documented behavior in other ways. Sometimes this is > non-trivial to do, but it's important. If it cannot be done, don't fix the > existing subroutine ? introduce a new method, deprecate the old method, and > document the whole thing. > That is guaranteed to upset almost every user. > We saw this before when the format used for printing SOA records was > changed. I have to hack in a replacement subroutine for > Net::DNS::RR::SOA::format_rdata that reinstates the old behavior. > > The *only* requirement for printed RR formats is that they conform to RFC1035 master file syntax. Layout is unspecified and in some cases can change depending on the size of the fields. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Wed Jun 4 12:49:39 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 04 Jun 2014 14:49:39 +0200 Subject: [net-dns-users] API regressions and coming shortened release cycle (was: Re: AXFR) In-Reply-To: References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> Message-ID: <538F15E3.1020205@nlnetlabs.nl> op 03-06-14 20:49, Chris Buxton schreef: > When you find a subroutine not working as intended, try to fix it without breaking the observed/documented behavior in other ways. Sometimes this is non-trivial to do, but it's important. If it cannot be done, don't fix the existing subroutine ? introduce a new method, deprecate the old method, and document the whole thing. Absolutely. This is also in line with the procedure I laid out earlier. I repeat: op 28-05-14 13:49, Willem Toorop schreef: > I think the best course of action for us would have been to: > > 1. Introduce the new functions that will replace old ones. > The old functions should keep working the same as before > (without printing warnings) > 2. Release with a notification about the new function, and the fact > that it will replace an old function. > 3. Give users opportunity to switch to usage of the new function and > adapt their dependency on the new module version. > 4. Adapt the old function to print the deprecated warning and > release again giving a warning about the function to be deprecated. > > We'll make sure to use this procedure with similar cases in the future. I will start a shortened release cycle for both Net::DNS and Net::DNS::SEC to return former API functions and also fix some other annoying regressions shortly. There are some more reports on regressions on RT I wish to walk through first. Again my apologies; We'll make sure to better follow the procedure laid out above in the future. Thanks for giving all this feedback. This is most helpful in determining our cause of action, so please keep doing so. Best regards, -- Willem PS. Any objections to not return a socket with axfr_start anymore? The warning was in the documentation and the socket wasn't really suitable for async processing, because From rwfranks at acm.org Wed Jun 4 15:02:34 2014 From: rwfranks at acm.org (Dick Franks) Date: Wed, 4 Jun 2014 16:02:34 +0100 Subject: [net-dns-users] API regressions and coming shortened release cycle (was: Re: AXFR) In-Reply-To: <538F15E3.1020205@nlnetlabs.nl> References: <5F267BC0-BD61-4550-9186-CE6149B6C219@init.se> <5385CD2E.1080204@nlnetlabs.nl> <5D906313-372B-4D54-BA73-2473BA0A0223@init.se> <3333E11D-60F9-4AD0-AA7A-F413F3BDDA00@init.se> <77E4F78F-17E4-421C-A1B0-B24859A47732@init.se> <7FF10085-C325-43FF-9C60-DA830C6939E8@init.se> <756A1382-190D-4D94-B3C4-BE4007E1771A@verisign.com> <538F15E3.1020205@nlnetlabs.nl> Message-ID: On 4 June 2014 13:49, Willem Toorop wrote: [snip] > > PS. Any objections to not return a socket with axfr_start anymore? The > warning was in the documentation and the socket wasn't really suitable > for async processing, because ... > It is now impossible to return a socket from axfr_start(), the returned Boolean value indicates if the underlying iterator object was successfully created. The iterator object is destroyed automatically when the final RR is read. The implementation now looks something like this: sub axfr_start { ## historical my $self = shift; my $iter = $self->{axfr_iter} = $self->axfr(@_); return defined $iter; } sub axfr_next { ## historical my $self = shift; my $iter = $self->{axfr_iter} || return undef; $iter->() || return $self->{axfr_iter} = undef; } Willem deserves the lion's share of the credit for this brainwave. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Fri Jun 6 20:51:32 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 06 Jun 2014 22:51:32 +0200 Subject: [net-dns-users] Net::DNS::SEC 0.19 Quickfix release Message-ID: <539229D4.3040702@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, We have a quick-fix release of Net::DNS::SEC. In the previous release, the previously documented API function Net::DNS::RR::DNSKEY::is_sep printed a message stating the function to be deprecated. This release has printing of this warning removed, re-establishing the old behaviour of the is_sep function. Also classes for the CDS and CDNSKEY are introduced to facilitate experimentation with automated DNSSEC delegation trust maintenance (see draft-ietf-dnsop-delegation-trust-maintainance). link: http://www.net-dns.org/download/Net-DNS-SEC-0.19.tar.gz sha1: 594215fa9a8bf4adc5d06a9f69f86d354b347b71 Changes for Net::DNS::SEC 0.19 ============================== ***0.19 Jun 6, 2014 Remove inappropriate deprecation warning in DNSKEY.pm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTkinMAAoJEOX4+CEvd6SYEdMP/3X6sbXSpc7Sk8fbVw3BddLL YcYxwiMqsYxjsEFXlmGlxq7A4iasvb/cHuXpbOa4pMct47XnFtdg0avQ4XXlV7lv u+z4qbn66TC6wPKUZSpYEPJAd4+ylbdyyai1X3aduENfJBA0354XTSZBOREcZ+jP DbBgplPgdieoUyib5413pgV2gcGZeOXwtFLjSJ9rUfFl+vhDHBE2xxOWI69OOQFT zkXBjmdMwwMMVZj739rz5Q3U0yaJjbvUUKU5OD35m8Rza9IlyvSs5EiO9Fq8UveG BD+rIErpV1K798LItH89fonDXVPeVmR+y4JXTLd5ac9ayWlAWSnfoSeBQiCXltbm ZaOLGwy7BArzpJr0WfMj0p7FHaHvxP/s/KN9bkiXU/BpLScP4pQtgKhZj/h58nHU MroAwmtRW3ZpmMPJ6weeOAWhbJNMvuB/ivwPuH+3HWjgNsmr9138z4YibOHPO5qP P8kV/arTFCWjLzp29fnw9eqTmRMp++7/4ogEOiGzu1oSjYepxa28q326jHHtVE99 OIbKFfv1MeIi/RYTzzsgEeVAo867L/mjWUHw05Az1+hzFzdvEZt1UfRGv1xRhfkn evvPoAD0Wk6yUQSnXT5Y5Oc+7J/tvjft3lR8E5lZx3Nj3kTrGSHvA1giubZz6oax 0gfDkjtIR1dXL/1T1Xqj =F074 -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Jun 6 20:56:35 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 06 Jun 2014 22:56:35 +0200 Subject: [net-dns-users] Quickfix release candidate for Net::DNS 0.77 Message-ID: <53922B03.5090901@nlnetlabs.nl> Dear maintainers and users of Net::DNS, We have a candidate for the upcoming quick-fix release 0.77 of Net::DNS. In the upcoming release the former Net::DNS::Resolver documented API functions axfr_start and axfr_next, that had been removed, are recovered. As an alternative to those functions the axfr function now also offers an iterator interface to provide gradual reception with zone transfers. Also some regressions that have arisen after the 0.75 and 0.76 release are fixed. For a complete list see the Changes sections below. If no issues arise, the actual release will follow coming Wednesday, the 11th of June 2014. link: http://www.net-dns.org/download/Net-DNS-0.76_2.tar.gz sha1: 93a79f281c2a731020959cc28630fa20128b18d0 Changes ======= Fix rt.cpan.org #96151 Unlocalised $_ modified when reading config file Fix rt.cpan.org #96135 Deep recursion problem on Cygwin Fix rt.cpan.org #96119 "Too late to run INIT block" warning for require Net::DNS Fix rt.cpan.org #96035 Insert missing plan 'no-plan' in 10-recurse.t Fix inefficient Net::DNS::SEC compatibility code From rwfranks at acm.org Fri Jun 6 22:20:20 2014 From: rwfranks at acm.org (Dick Franks) Date: Fri, 6 Jun 2014 23:20:20 +0100 Subject: [net-dns-users] Net::DNS::SEC 0.19 Quickfix release In-Reply-To: <539229D4.3040702@nlnetlabs.nl> References: <539229D4.3040702@nlnetlabs.nl> Message-ID: All, Please note that CDNSKEY will not work until the assignment appears in Net::DNS::Parameters. This is generated from the IANA registry xml file which does not yet have this entry. For test purposes, you could add CDNSKEY => 60, to your local copy, accepting a small risk that it may change. Dick -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Wed Jun 11 19:07:35 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 11 Jun 2014 21:07:35 +0200 Subject: [net-dns-users] [NLnet Labs Maintainers] Quickfix release candidate for Net::DNS 0.77 In-Reply-To: <53922B03.5090901@nlnetlabs.nl> References: <53922B03.5090901@nlnetlabs.nl> Message-ID: <5398A8F7.1080808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, We are still considering some issues with this release. The actual release is thereby delayed by one or two days. op 06-06-14 22:56, Willem Toorop schreef: > Dear maintainers and users of Net::DNS, > > We have a candidate for the upcoming quick-fix release 0.77 of > Net::DNS. > > In the upcoming release the former Net::DNS::Resolver documented > API functions axfr_start and axfr_next, that had been removed, are > recovered. As an alternative to those functions the axfr function > now also offers an iterator interface to provide gradual reception > with zone transfers. > > Also some regressions that have arisen after the 0.75 and 0.76 > release are fixed. For a complete list see the Changes sections > below. > > If no issues arise, the actual release will follow coming > Wednesday, the 11th of June 2014. > > link: http://www.net-dns.org/download/Net-DNS-0.76_2.tar.gz sha1: > 93a79f281c2a731020959cc28630fa20128b18d0 > > > > Changes ======= Fix rt.cpan.org #96151 > > Unlocalised $_ modified when reading config file > > Fix rt.cpan.org #96135 > > Deep recursion problem on Cygwin > > Fix rt.cpan.org #96119 > > "Too late to run INIT block" warning for require Net::DNS > > Fix rt.cpan.org #96035 > > Insert missing plan 'no-plan' in 10-recurse.t > > Fix inefficient Net::DNS::SEC compatibility code > _______________________________________________ maintainers mailing > list maintainers at nlnetlabs.nl > http://nlnetlabs.nl/mailman/listinfo/maintainers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTmKjzAAoJEOX4+CEvd6SYow8P/0zE0zVVLJB6O8yktoRvxzmE 5b/EJI6u8k5EXrEr9E22Eml/dABFRUEdqK8sEfp1zvaO2Vqv/Ngqzov9XJMYlq5J kRldsrMP5bSmofwXoiwMZ27DDYs2ym0twEFq8FwGr7OhJ6zPm7bRyDbVuSjPTsrU cKVIOZvz7D43i+8mzbjzK4W/g5nlW+16fDKRm4oXJOYpvgD5whugcLswxZybR/NA UO/mFAlaKHMUrXcF66L2TpO25mG+IEovvKi0hqncKNzzZe/2XEennUKnvU2n+U8u VOlOu6hac5uJ1SmpGRydzv0ltYzDU5jkVE54iuH8SiYYquqkz/BSV+fjiFt+GJMq 9AXwbGI2qWtsu6QMkr3P+x1AOFTjD4jKSuhGBaNzmJxds5rcSh7eDbjAfnULzaqq obeWKC3QZ6r0j+4v2vDf0S08oFpGfTugqSDyFRFPn4C6/IdE7nzSkG81IZDNGpVc 6gVGV+1R1etgLRGcmoa4vMnsMc0xVCgxArc9wdNrREe8LoaxlzCLQMJET0BtrIKH PY8AOQZBEXhaGVwfbqjLrMK6UczGQxaBEHMS3VoJYoscdZWcgEkgE1esdEV9V1it PWr3yq5ztBIoLqo6kpHMdjgzwYt77P9coztVsgfRfBAGhW6Pf2GcoGXZY1DhsRj4 ZzlWcS0fAJso+s2t+9RW =XwNk -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Jun 13 21:56:39 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 13 Jun 2014 23:56:39 +0200 Subject: [net-dns-users] Net::DNS 0.77 released Message-ID: <539B7397.40608@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, I am pleased to announce version 0.77 of Net::DNS. This release is primarily concerned with fixing regressions that have arisen since the 0.75 and 0.76 releases. It has the axfr_start and axfr_next functions of Net::DNS::Resolver restored. Net::DNS::Resolver::axfr in scalar context now returns an iterator interface to provide gradual reception with zone transfers. Also processing of resolver configuration directives has been improved to be more robust, sensible and secure. An initial instantiation will set the class defaults always, so that subsequent instantiations ? without explicit config_file argument or other overrides ? will use those defaults and will not start processing environment variables or insecure locations for config files. For a complete list of changes see the Changes sections below. link http://www.net-dns.org/download/Net-DNS-0.77.tar.gz sha1 e2264580ba9fa1d13104d41239c317570de9807e Changes ======= Fix rt.cpan.org #96151 Unlocalised $_ modified when reading config file Fix rt.cpan.org #96135 Deep recursion problem on Cygwin Fix rt.cpan.org #96119 "Too late to run INIT block" warning for require Net::DNS Fix rt.cpan.org #96035 Insert missing plan 'no-plan' in 10-recurse.t Fix inefficient Net::DNS::SEC compatibility code -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTm3OTAAoJEOX4+CEvd6SYCqUP/1zRHgmeLRz7koEfW3ebSekb HPxDtaUYZTqbKCKQTz5Y4mc5GoOD0N3DgbeH4WnOdXlQTp446mKnaraa8+ASxii7 BFNBq6sc3AZX1hcAVzNUjpXaHYjGS9S7CG1/De6aOQp9Sp8AohGC5a8+mi6EfSAa oNrGZVj5DSZE0rBpM6CTpBHTLeQK60QiArtJjy48hd4KH2neafM1aD6wZgFzExXB l7nMzlfTgSRMQ9fVM6wg7a2itWtVSHZNJnZZfuaSeqByFH5BwGQqnCMLvs0bDcom VJLHt0J0QRTewscoq6mT1YIAVxmgt8STWKt3QUBFLYyYhEeLNiWN76Zlkw6fFp8Z Picd7ZVy271HLPL2fJY8qfJWy5AbrP6jocR2T3WYh9kKNhXNm8fso9Ma4Mul4SBI Cpw73S42MelUbdZ+B2BUNriKbmCYAqB4QS9mAylbpHJmp+FgxUx3B6WpZ6Yhw4TZ ZErurgVUwH0pBLHlu3wkVlbBrLhA+Nm44lOpfK3KMku2hfgRZku8PhyBowLCchbk mIyhzPg18PIuXePqY7wrquH2PUD8DrOJulRPqQ8CJis+JNAavo55rdKyY8J1cym/ JnDAOe6F20o2KOFA81nvFSARX3bRac/YuyyJ1L6Vco5EkNDvkgyv58YH7Qsalatv qPwRplLGeAcjZvsYc4pA =or7n -----END PGP SIGNATURE----- From clists at buxtonfamily.us Wed Jun 25 00:10:07 2014 From: clists at buxtonfamily.us (Chris Buxton) Date: Tue, 24 Jun 2014 17:10:07 -0700 Subject: [net-dns-users] rrsort exported by default Message-ID: <6952BB55-A55B-4202-AC63-3D7F44CB57A2@buxtonfamily.us> At what version did it become default behavior to export &rrsort? This broke my DNS utilities module when I upgraded from 0.72 to 0.77, because my own &rrsort subroutine (which does something totally different) has a proper prototype. Simple enough to fix, but ? Regards, Chris From willem at nlnetlabs.nl Thu Jul 3 09:53:25 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 03 Jul 2014 11:53:25 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 0.78 Message-ID: <53B52815.4040303@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, We have a candidate for the upcoming release 0.78 of Net::DNS. This is almost completely a bugfix release. Besides bug fixes this release has multi line printing of TXT rdata. For a complete list see the Changes sections below. If no issues arise, the actual release will follow coming Thursday, the 10th of July 2014. link http://www.net-dns.org/download/Net-DNS-0.77_1.tar.gz sha1 38f52e54582d3c7f1e8463f7f29ed793af1c1b8b Changes ======== Fix rt.cpan.org #96814 Trailing comments not stripped in /etc/resolv.conf Fix rt.cpan.org #96812 Net::DNS::Resolver->new() hangs if nameserver :: exists Fix rt.cpan.org #96755 RFC 3597 (hex) parsing mistake Fix rt.cpan.org #96708 String treated as boolean in TXT Fix rt.cpan.org #96608 "Insecure dependency in connect" with Net::DNS::Resolver over TCP Fix rt.cpan.org #96535 Net::DNS::Resolver warns "Use of uninitialized value in length" Fix rt.cpan.org #96531 Calling $resolver->nameservers multiple times returns an increasingly-long list (on some perl installations) Fix rt.cpan.org #96439 Uninitialised decoding object when printing packet -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTtSgQAAoJEOX4+CEvd6SYLSkP/R6DYiEPepGmYxAYJ9MhyVoB LlxuQ8pWC3jSUirxAPqHadL7rHtqoCHF71SNxBNjjpagXIjjVK9bF7RrrKLvq+2s u482XAFKyyceuAq5UedhM1JqmfmDSJXWo6kkWWe6h9rzhIDbBq3mU7XKTWdQNEHD 1ZYpw4M6Hq0d2euH74dI3SzSNJPQnKjXhNrXbgQDdBlOgbUdI5UWAqLncMz1vUJA pv8sTEjdsEvhYPnJEQes/aqqVgMfq1ag49V9O5NKFjNVgLeUf8W9QPSv8RtO3BXJ h58pBQCwhOhz3DAYki33bN6fMA5lC9oxSdoaFa4yqm7PMANFGWk9xCMlGQrnCM1f YQ7MBj5bU8Kq39j6Ki3aaZHzGjU3N0iJrISOAVSQg8XdmptZVKeG71dRrWyYszs+ grLS9xpf+LjbZIDqJeWzvBZxIDKv+Oyv4cqvniWOmP32PgRlACvqO4GoIn5cE3qT ap0Pfm88QNInP6kZNt/uFIQuuwDoI+JXD5bfrHQB9JKB2hXgVw3PoCfx/EdwruWd XRbj84GunwRIcxndyE5dXPNb8LrJufcTOSR134wwlYkntcPkuVxIa1cv2oGN6Az/ ZWxNPPjG4HHqPy0nkHXKVOWM2yviYmO0zkooZ4EqhUArwOheCeNpRJNBIeh4asbb RCegSEsgvJ6jfoeulIuE =p8tK -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Thu Jul 10 14:15:24 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 10 Jul 2014 16:15:24 +0200 Subject: [net-dns-users] Net::DNS 0.78 released Message-ID: <53BE9FFC.5010902@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, I am pleased to announce version 0.78 of Net::DNS. This is primarily a bugfix release. Besides bug fixes this release has multi line printing of TXT rdata. For a complete list see the Changes section below. link http://www.net-dns.org/download/Net-DNS-0.78.tar.gz sha1 a50fdf4786fadd7ece6958393f9b81e1eae749ac Changes ======= Fix rt.cpan.org #97036 Nameserver identification on Cygwin Fix rt.cpan.org #96814 Trailing comments not stripped in /etc/resolv.conf Fix rt.cpan.org #96812 Net::DNS::Resolver->new() hangs if nameserver :: exists Fix rt.cpan.org #96755 RFC 3597 (hex) parsing mistake Fix rt.cpan.org #96708 String treated as boolean in TXT Fix rt.cpan.org #96608 "Insecure dependency in connect" with Net::DNS::Resolver over TCP Fix rt.cpan.org #96535 Net::DNS::Resolver warns "Use of uninitialized value in length" Fix rt.cpan.org #96531 Calling $resolver->nameservers multiple times returns an increasingly-long list (on some perl installations) Fix rt.cpan.org #96439 Uninitialised decoding object when printing packet -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTvp/3AAoJEOX4+CEvd6SYyaMP/1b0SvmtMPijgu1nG+u7dbfK Y/S1sVUYEMEwij8y72CWT6qNBV2J1rhrqyuLR0LIiAefu9rhtLWc3vGM64sB+BQu IEbpdrsjd3ZzZwyQLn9s4Yo88JP317SYex5mCJP1IcTppYj9zrXvUiP3aTQZ7chy rvclr+aTGV4M3tjvaoCXT1ZCBcrfzCJFnC1AEgZsr/QE9YQ4BP49xSpZDEr+9nqF jFdgt4z+u+EcEhgOwnXhErIsJQYB21jI97N3DqApcC2wpz6GkGV3aOBVMPq43kqi sKjNfg+RKudBBTI74APkuSO3wrXZ/klHf5jkh1PqLgmwlbAzjov/bsVT9ZD4Eo1E +ssUcVMOoBA3NdhTxAIjblcyotOuomsJhnfQla50TOJaJzjwPmGGsxg4Xbh+OdNr t0OS2r6NhsFDPCLnY1PBjxOdEYdj/YUhy3Fdzoyr+z+TPwlb/HI+TkC5du4QN4w1 50LhnphVlp2OgEMErwV0g2QFZVy9sjku598CiEqPtkvuUaPBq0RZA1VjnAM0rLLJ 4rw37FkbVGD91QTGthUpTNIOsA1BxJKeZe8Z6x2325r2PSBQuHBwpSzeFS+9nhWg aUlPDKbFWBfXYsRWKpDr6NEwtrWAOLNmOxQan4v5Qo7qxp+t9fy8A1cW1tmJXCzj fnuVcbQ7iIsq8vFcIImb =sENR -----END PGP SIGNATURE----- From jim.barber at primaryhealthcare.com.au Thu Aug 7 03:25:47 2014 From: jim.barber at primaryhealthcare.com.au (Jim Barber) Date: Thu, 7 Aug 2014 03:25:47 +0000 Subject: [net-dns-users] TSIG error when upgrading Debian Linux libnet-dns-perl package. Message-ID: <3D9448F22FC9AE4A9F8BD2088693D8AB05099590@DC1NS-MBX01.hc.int> Hi. Hopefully this is the correct mailing list to report an issue I've encountered. I have a perl program that is called from a Linux DHCP server to provide secure updates to a MS Windows DNS server. It uses the GSS-TSIG algorithm for signing the DNS requests. In order to do this, the script authenticates to the Windows DNS server via kerberos. This was working fine until I upgraded the libnet-dns-perl package in Debian that contains the Net::DNS perl modules. When I backed the package out to the older version the script started working again. The version of the Debian package that works is 0.68-1.2 and the version that doesn't is 0.78-1. The version of Perl running on the system is 5.18.2 (Debian's 5.18.2-7 package) When the program runs with the new version, the following error is produced: *** FATAL PROGRAM ERROR!! Unknown method 'mode' *** which the program has attempted to call for the object: *** *** 6801348012840. 0 ANY TSIG ; algorithm: HMAC-MD5.SIG-ALG.REG.INT ; time signed: 1407323356 fudge: 36000 ; signature: ; original id: 0 ; NOERROR *** *** This object does not have a method 'mode'. THIS IS A BUG *** IN THE CALLING SOFTWARE, which incorrectly assumes that the *** object would be of a particular type. The type of an object *** should be checked before calling any of its methods. at /usr/lib/perl5/Net/DNS/RR.pm line 213. Net::DNS::RR::_new_hash called at /usr/lib/perl5/Net/DNS/RR.pm line 65 eval {...} called at /usr/lib/perl5/Net/DNS/RR.pm line 66 Net::DNS::RR::new('Net::DNS::RR', 'name', 6801348012840, 'type', 'TSIG', 'ttl', 0, 'class', 'ANY', ...) called at ./update_ms_secure_dns.pl line 657 in new Net::DNS::RR( name 6801348012840 type TSIG ttl 0 class ANY mode ... ) at ./update_ms_secure_dns.pl line 657. The line in the perl program that triggered the error is: my $sig = Net::DNS::RR->new( name => $key_name, type => "TSIG", ttl => 0, class => "ANY", mode => 3, algorithm => $algorithm, time_signed => time, fudge => 36000, mac_size => 0, mac => "", error => 0, other_len => 0, other_data => "", sign_func => \&gss_sign, key => $gss_context, ); The $key_name variable above is just a long random number. The $algorithm variable is a string set to "gss.microsoft.com" The &gss_sign function is a signing callback for TSIG. The $gss_context variable is the result of calling a function that negotiates a TKEY with the DNS server. If I chop the 'mode => 3,' part out from the code above and run it again I get the following error: *** FATAL PROGRAM ERROR!! Unknown method 'mac_size' *** which the program has attempted to call for the object: *** *** 6190724876677. 0 ANY TSIG ; algorithm: gss.microsoft.com ; time signed: 1407324278 fudge: 300 ; signature: ; original id: 0 ; NOERROR *** *** This object does not have a method 'mac_size'. THIS IS A BUG *** IN THE CALLING SOFTWARE, which incorrectly assumes that the *** object would be of a particular type. The type of an object *** should be checked before calling any of its methods. at /usr/lib/perl5/Net/DNS/RR.pm line 213. Net::DNS::RR::_new_hash called at /usr/lib/perl5/Net/DNS/RR.pm line 65 eval {...} called at /usr/lib/perl5/Net/DNS/RR.pm line 66 Net::DNS::RR::new('Net::DNS::RR', 'name', 6190724876677, 'type', 'TSIG', 'ttl', 0, 'class', 'ANY', ...) called at ./update_ms_secure_dns.pl line 657 in new Net::DNS::RR( name 6190724876677 type TSIG ttl 0 class ANY mode ... ) at ./update_ms_secure_dns.pl line 657. If I then chop the mac_size part out of the code I get the error: *** FATAL PROGRAM ERROR!! Unknown method 'other_len' *** which the program has attempted to call for the object: *** *** 159686746509. 0 ANY TSIG ; algorithm: gss.microsoft.com ; time signed: 1407324076 fudge: 300 ; signature: ; original id: 0 ; NOERROR *** *** This object does not have a method 'other_len'. THIS IS A BUG *** IN THE CALLING SOFTWARE, which incorrectly assumes that the *** object would be of a particular type. The type of an object *** should be checked before calling any of its methods. at /usr/lib/perl5/Net/DNS/RR.pm line 213. Net::DNS::RR::_new_hash called at /usr/lib/perl5/Net/DNS/RR.pm line 65 eval {...} called at /usr/lib/perl5/Net/DNS/RR.pm line 66 Net::DNS::RR::new('Net::DNS::RR', 'name', 159686746509, 'type', 'TSIG', 'ttl', 0, 'class', 'ANY', ...) called at ./update_ms_secure_dns.pl line 657 in new Net::DNS::RR( name 159686746509 type TSIG ttl 0 class ANY algori ... ) at ./update_ms_secure_dns.pl line 657. If I then chop out the other_len part then the errors go away but also the program no longer works. >From version 0.68 to 0.78 of the Net::DNS perl module it looks like there were quite a lot of changes to the Net::DNS::RR::TSIG module. Am I now (or always was) incorrectly using 'Net::DNS::RR->new' in that line of code shown above? Or have I uncovered a bug? Here is some more information about the system: # perl -V Summary of my perl5 (revision 5 version 18 subversion 2) configuration: Platform: osname=linux, osvers=3.14-1-amd64, archname=x86_64-linux-gnu-thread-multi uname='linux estella 3.14-1-amd64 #1 smp debian 3.14.10-1 (2014-07-07) x86_64 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -fwrapv -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.18 -Darchlib=/usr/lib/perl/5.18 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.18.2 -Dsitearch=/usr/local/lib/perl/5.18.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -Uversiononly -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.18.2 -des' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.9.0', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=, so=so, useshrplib=true, libperl=libperl.so.5.18.2 gnulibc_version='2.19' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Locally applied patches: DEBPKG:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS default for modules installed from CPAN. DEBPKG:debian/db_file_ver - http://bugs.debian.org/340047 Remove overly restrictive DB_File version check. DEBPKG:debian/doc_info - Replace generic man(1) instructions with Debian-specific information. DEBPKG:debian/enc2xs_inc - http://bugs.debian.org/290336 Tweak enc2xs to follow symlinks and ignore missing @INC directories. DEBPKG:debian/errno_ver - http://bugs.debian.org/343351 Remove Errno version check due to upgrade problems with long-running processes. DEBPKG:debian/libperl_embed_doc - http://bugs.debian.org/186778 Note that libperl-dev package is required for embedded linking DEBPKG:fixes/respect_umask - Respect umask during installation DEBPKG:debian/writable_site_dirs - Set umask approproately for site install directories DEBPKG:debian/extutils_set_libperl_path - EU:MM: Set location of libperl.a to /usr/lib DEBPKG:debian/no_packlist_perllocal - Don't install .packlist or perllocal.pod for perl or vendor DEBPKG:debian/prefix_changes - Fiddle with *PREFIX and variables written to the makefile DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to the binary targets. DEBPKG:debian/instmodsh_doc - Debian policy doesn't install .packlist files for core or vendor. DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as per Debian policy. DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable. DEBPKG:debian/mod_paths - Tweak @INC ordering for Debian DEBPKG:debian/module_build_man_extensions - http://bugs.debian.org/479460 Adjust Module::Build manual page extensions for the Debian Perl policy DEBPKG:debian/prune_libs - http://bugs.debian.org/128355 Prune the list of libraries wanted to what we actually need. DEBPKG:fixes/net_smtp_docs - [rt.cpan.org #36038] http://bugs.debian.org/100195 Document the Net::SMTP 'Port' option DEBPKG:debian/perlivp - http://bugs.debian.org/510895 Make perlivp skip include directories in /usr/local DEBPKG:debian/cpanplus_definstalldirs - http://bugs.debian.org/533707 Configure CPANPLUS to use the site directories by default. DEBPKG:debian/cpanplus_config_path - Save local versions of CPANPLUS::Config::System into /etc/perl. DEBPKG:debian/deprecate-with-apt - http://bugs.debian.org/702096 Point users to Debian packages of deprecated core modules DEBPKG:debian/squelch-locale-warnings - http://bugs.debian.org/508764 Squelch locale warnings in Debian package maintainer scripts DEBPKG:debian/skip-upstream-git-tests - Skip tests specific to the upstream Git repository DEBPKG:debian/patchlevel - http://bugs.debian.org/567489 List packaged patches for 5.18.2-7 in patchlevel.h DEBPKG:debian/skip-kfreebsd-crash - http://bugs.debian.org/628493 [perl #96272] Skip a crashing test case in t/op/threads.t on GNU/kFreeBSD DEBPKG:fixes/document_makemaker_ccflags - http://bugs.debian.org/628522 [rt.cpan.org #68613] Document that CCFLAGS should include $Config{ccflags} DEBPKG:debian/find_html2text - http://bugs.debian.org/640479 Configure CPAN::Distribution with correct name of html2text DEBPKG:debian/hurd_test_skip_stack - http://bugs.debian.org/650175 Disable failing GNU/Hurd tests dist/threads/t/stack.t DEBPKG:fixes/manpage_name_Test-Harness - http://bugs.debian.org/650451 [rt.cpan.org #73399] cpan/Test-Harness: add NAME headings in modules with POD DEBPKG:debian/makemaker-pasthru - http://bugs.debian.org/660195 [rt.cpan.org #28632] Make EU::MM pass LD through to recursive Makefile.PL invocations DEBPKG:debian/perl5db-x-terminal-emulator.patch - http://bugs.debian.org/668490 Invoke x-terminal-emulator rather than xterm in perl5db.pl DEBPKG:debian/cpan-missing-site-dirs - http://bugs.debian.org/688842 Fix CPAN::FirstTime defaults with nonexisting site dirs if a parent is writable DEBPKG:fixes/memoize_storable_nstore - [rt.cpan.org #77790] http://bugs.debian.org/587650 Memoize::Storable: respect 'nstore' option not respected DEBPKG:fixes/net_ftp_failed_command - [rt.cpan.org #37700] http://bugs.debian.org/491062 Net::FTP: cope gracefully with a failed command DEBPKG:fixes/perlbug-patchlist - [3541c11] http://bugs.debian.org/710842 [perl #118433] Make perlbug look up the list of local patches at run time DEBPKG:fixes/module_metadata_security_doc - [68cdd4b] CVE-2013-1437 documentation fix DEBPKG:fixes/module_metadata_taint_fix - [bff978f] http://bugs.debian.org/722210 [rt.cpan.org #88576] untaint version, if needed, in Module::Metadata DEBPKG:fixes/IPC-SysV-spelling - http://bugs.debian.org/730558 [rt.cpan.org #86736] Fix spelling of IPC_CREAT in IPC-SysV documentation DEBPKG:fixes/goto-sub-crash - [bfa371b] http://bugs.debian.org/736187 [perl #119949] Stop undef *_, goto &sub from crashing DEBPKG:debian/regcomp-mips-optim - http://bugs.debian.org/754054 Downgrade the optimization of regcomp.c on mips due to a gcc-4.9 bug Built under linux Compiled at Jul 14 2014 20:40:45 @INC: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . The Operating system is the current Debian Testing distribution with all current updates applied. The name server is a Windows Server 2012 domain controller with an Active Directory integrated DNS zone that accepts secure updates only. Regards, Jim From rwfranks at acm.org Thu Aug 14 11:12:43 2014 From: rwfranks at acm.org (Dick Franks) Date: Thu, 14 Aug 2014 12:12:43 +0100 Subject: [net-dns-users] TSIG error when upgrading Debian Linux libnet-dns-perl package. In-Reply-To: <3D9448F22FC9AE4A9F8BD2088693D8AB05099590@DC1NS-MBX01.hc.int> References: <3D9448F22FC9AE4A9F8BD2088693D8AB05099590@DC1NS-MBX01.hc.int> Message-ID: On 7 August 2014 04:25, Jim Barber wrote: > > Hopefully this is the correct mailing list to report an issue I've > encountered. > No it is not. Bugs are reported using the CPAN RT system. But as this is probably not a bug, here is ok. I suggest you start by reading the documentation for Net::DNS::RR::TSIG and Net::DNS::Packet (sign_tsig) and adjust your example to match. use Carp; use Net::DNS; my $resolver = new Net::DNS::Resolver(); my $key_name = 'key_name'; my $algorithm = 'gss.microsoft.com'; my $gss_context = 'gss_context'; sub gss_sign { carp sprintf( "gss_sign( %s, %s )\tcalled", map unpack('H*',$_), @_ ); scalar reverse shift; # fake sig } my $tsig = Net::DNS::RR->new( name => $key_name, type => "TSIG", algorithm => $algorithm, sign_func => \&gss_sign, keybin => $gss_context, # key => $gss_context, ); my $query = Net::DNS::Packet->new('x'); $query->sign_tsig($tsig); my $reply = $resolver->send($query); Note that the "key" is binary, not Base64 encoded. I guess this may be a large part of your problem. The version shipped with 0.68 had the conversions is the wrong places, which made it impossible to build an internal key management scheme which could handle both predefined HMAC-SHA functions and the external function needed for GSS. In the key table, the algorithm name indicates the signing function to be used, and the key name indicates which key to use. This association can not be changed. The TSIG that is presented to packet->sign_tsig() is never modified and can be reused; the TSIG added to the packet is a copy with the MAC and other info added automatically. > From version 0.68 to 0.78 of the Net::DNS perl module it looks like there > were quite a lot of changes to the Net::DNS::RR::TSIG module. > This was a complete rewrite, for two separate reasons: 1) The internal architecture of Net::DNS::RR changed significantly between 0.68 and 0.69. 2) There was no support for TSIG verification or for signing multi-message transactions like zone transfers (added in 0.75). It would be interesting to see if you can make a TSIG verified zone transfer work using your GSS setup. This is the code I used for HMAC-SHA256 with BIND. my $resolver = new Net::DNS::Resolver( nameservers => [@ip] ); $resolver->tsig( $tsig ); my @zone = $resolver->axfr( 'example.com', 'IN' ); warn "Zone transfer failed: ", $resolver->errorstring, "\n" unless @zone; $_->print foreach @zone; -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Fri Aug 15 14:17:23 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 15 Aug 2014 16:17:23 +0200 Subject: [net-dns-users] Net::DNS::SEC 0.20 released Message-ID: <53EE1673.9050507@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS::SEC, I am pleased to announce version 0.20 of Net::DNS::SEC. This release has only a single bugfix, rt.cpan.org #97457, which re-established parsing of ?-? (zero) salt fields in NSEC3 presentation format. Because of the smallness of the change (only one and a half lines of code) we consider it safe and acceptable shorten the release cycle and do a full release immediately. For a complete list of changes see the Changes sections below. link http://www.net-dns.org/download/Net-DNS-SEC-0.20.tar.gz sha1 96a097a1d2dbd1f466156bab3da70022263a539d Changes ======= Fix: rt.cpan.org #97457 !hex! error when parsing NSEC3 with empty salt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT7hZuAAoJEOX4+CEvd6SYM88QAJtk2V1UW+bHn2WwJzU7J3sj BpFrJIc86ANnuuR09Y/l8JV8vk0QghgmqzQ4BtYoTo3S3HOqKkOZMsPE8T5p/67G WZ50BtAuyHt4U+DyDlmfI7GG3n97JCgjESN8xl2fWAZaGXPT/ex3Zm4t9FD+d8JL yTXDwdLbOxvNfGNVfR6Y9uV10PFOzTH50LMNgekUBHbvLvOFf2v7svyBzO8m/wwM x62AWtXkzJyIxCcN3pcBkVoJUpDkkd2CNe2JpP7f10oWK3ssBDGZgNY+GIdPJebG 49rM6G4wt3w4UXRKE7I/zvc7YcIJKimdndVG+fVM4A54f90A4MY8+QY6GlTKBjoH IBYhG1DiEw1BmZYSYKpdzMdaBbGQDcji4JWipKbP3NEz1n8JQQbY3lOe21z/VBgy /6DYqMinKWUP/5RPUjE2s7jHhSfKuUwTYSAqINOOvbN2bmVb7S7F9L42PHRmHJLY kwTTwDSJiBDVaUiudHAutqTq/laxhHBidH69d7hJQI6Q0ihY3NvnFMnZCTDWoowW XH9pHO99H+/fuPA0d+oyO8lMkAyFbc1tD8UC5Cor1fDo4LD0j/eZWepA9rYLpJOH O8dp1w750AQraHxxTW/t4Qo+5mCaI8DjG6GJ8S6Piia+gANnEXK9ARRDfDIw9S2Y iNf/yrYMqL0CpqVmwQ45 =Zf4I -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Aug 15 14:38:57 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 15 Aug 2014 16:38:57 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 0.79 Message-ID: <53EE1B81.2090805@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, We have a candidate for the upcoming bugfix release 0.79 of Net::DNS. Besides bug fixes this release introduces the OPENPGPKEY RR. Also, the recursive resolver Net::DNS::Resolver::Recurse has received a complete rework to make it a) always terminate, b) work properly and c) not make too many unnecessary requests. It now also provides recursive resolving through the conventional query, search and send methods, enabling drop in replacement of Net::DNS::Resolver objects. For a complete list of changes see the Changes section below. If no issues arise, the actual release will follow Friday the 22th of August 2014. link http://www.net-dns.org/download/Net-DNS-0.78_3.tar.gz sha1 75fd73f0ee55200f19919fbb43d80ae07a339456 Changes ======= Fix rt.cpan.org #97736 Net::DNS::Resolver->new mistakenly copies supplied arguments into default configuration on first instantiation. Fix rt.cpan.org #97502 Net::DNS::Resolver->retrans does not accept a value of 1 (uses 2 instead) Fix rt.cpan.org #81760 Reverted workaround for TXT issue preventing propagation of rule updates for SpamAssassin versions earlier than 3.4.0 Fix rt.cpan.org #16630 Net::DNS::Resolver::Recurse issues lots of IMHO unnecessary DNS requests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT7huBAAoJEOX4+CEvd6SY6NoP/1+R8KwUFDvJtRTOw0K9Cm9K ZPnMztaOVY60H3rBo5EtwjUh04kvJkL8E13XKEJBSXTdOn5LN9RKs8ojDNU4W9B1 wIokPosLEOfQnSHV3PbVwv02F7G/VIx8f7MHJANrmdrNc8xHQ0fsGpniOMHrjqY1 vevC3tQ+Lg/4N4VY5UJAVXTkUGLR9Ynd9c2DrS12ZSdU7+26b7Q4dCDc3RuMXQDW QDxTKS4gvDepQm9iRL4GlIysKTYjkZFyjP+bCW2IAVpmOIHO85HyuBOme/TYdlJ5 cMA5C1qY7oqf16On/gdTYrclr16Q2ugTp8qxyBLxmx1jF2VyEVhjFUkclPHCGMFa vYmHvMXFaZkUAOdDggPhG0Ccre9UqsKquENUwBnaT0vgle6vDE59qH/CO9MHrMm9 ix6qmVQWs33Xtul4SESHEqnLJD2GUKOYsgweq114lT3UQksZvfklPjxgAuayDS4E sfQ9a7d+kQeDwBvjbKxCiN+V88uqGDbD023hee12rbCYwd0Ymvfaz41pZGGiz+jw kAcBcWUWCy0zNUzXXSKt1EMB+1ZwMLmvaz+M6V7JOIQwvnT92jbVV59Yx8ztt17X uleldOmzdgNE7ZmVbRH2g732e1lYCubP0IAhdGMIaDPKPpnSeslVbfsfoASIQUma oNO8EqoBNq/mquEKQ5t1 =trUD -----END PGP SIGNATURE----- From rwfranks at acm.org Fri Aug 15 20:49:33 2014 From: rwfranks at acm.org (Dick Franks) Date: Fri, 15 Aug 2014 21:49:33 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 0.79 In-Reply-To: <53EE1B81.2090805@nlnetlabs.nl> References: <53EE1B81.2090805@nlnetlabs.nl> Message-ID: On 15 August 2014 15:38, Willem Toorop wrote: [snip] > ... [Net::DNS::Resolver::Recurse] now also provides > recursive resolving through the conventional query, search and send > methods, enabling drop in replacement of Net::DNS::Resolver objects. > > Please bear in mind the additional load this imposes on DNS infrastructure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Sat Aug 16 08:54:56 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Sat, 16 Aug 2014 10:54:56 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 0.79 In-Reply-To: <53EE1B81.2090805@nlnetlabs.nl> References: <53EE1B81.2090805@nlnetlabs.nl> Message-ID: <53EF1C60.6090004@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear maintainers and users of Net::DNS, The release candidate tarball posted in the previous announcement did not actually include the OPENPGPKEY.pm file that implements the OPENPGPKEY RR. Here is a new release candidate tarball which has this fixed: link http://www.net-dns.org/download/Net-DNS-0.78_4.tar.gz sha1 5ce4f6afabb275de0253637446c84c776dd881c3 Sorry about this, - -- Willem Op 15-08-14 om 16:38 schreef Willem Toorop: > Dear maintainers and users of Net::DNS, > > We have a candidate for the upcoming bugfix release 0.79 of > Net::DNS. > > Besides bug fixes this release introduces the OPENPGPKEY RR. > > Also, the recursive resolver Net::DNS::Resolver::Recurse has > received a complete rework to make it a) always terminate, b) work > properly and c) not make too many unnecessary requests. It now > also provides recursive resolving through the conventional query, > search and send methods, enabling drop in replacement of > Net::DNS::Resolver objects. > > For a complete list of changes see the Changes section below. > > If no issues arise, the actual release will follow Friday the 22th > of August 2014. > > link http://www.net-dns.org/download/Net-DNS-0.78_3.tar.gz sha1 > 75fd73f0ee55200f19919fbb43d80ae07a339456 > > > Changes ======= Fix rt.cpan.org #97736 > > Net::DNS::Resolver->new mistakenly copies supplied arguments into > default configuration on first instantiation. > > Fix rt.cpan.org #97502 > > Net::DNS::Resolver->retrans does not accept a value of 1 (uses 2 > instead) > > Fix rt.cpan.org #81760 > > Reverted workaround for TXT issue preventing propagation of rule > updates for SpamAssassin versions earlier than 3.4.0 > > Fix rt.cpan.org #16630 > > Net::DNS::Resolver::Recurse issues lots of IMHO unnecessary DNS > requests. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT7xxcAAoJEOX4+CEvd6SY2U0P/jgMdwJPs+DcN2ftiq2zz0r0 PhWhYLrTPVMUG6Is0sVMn7OB1mDbWOy22hSe68roz1OPTRMhlCrqQLyVrK0qyfVa Df5wavE/HO546+S9gcQNzGH1CZI77PeLc8J+MfQG3g8tVf9h1Up/P4PN3CqhdO9k RXh1vFDVZ+/budEPrx5ff7Lpk3eODDp8B1PHBtHAfHR80luW5vrxdZYVIhPQZ0o6 WTxg+45j7aNGRl0AHnCkty3n/JRsjslJKZIzb8U5eEtBcbelfQ3KUc8fAZhZgfMJ 7QPeuAdmDPWm+XhZZctyyvosGPLYUdgfp80wSooIYx13YLL4C874cYsItHrMLf0T WSYeM0Y58ipPgoT7p7082oqVoD597JkGPNoK27T7rP1gg/k9whehDwwNPFq8+CKc HXolA0p9r81fZGwn/IiGruvL4aSF9DDpZSdKqGJ3zGE4yjTtRzf2wIOgrgLxnGQN WVTdZ6ZjypdpzbGh+zi+h4rpn3b+BQLZ8zrBRMMEOVc+LhHCEDDWFP70honC0aau HcTqx4xeAYQxI98aq1dpFVNJBPlEGPE+wKGu5qbQ4CvuF9nJLdRh4Y9yUv2malVi ENLHkDLhuEEZYQIAbVBAN848JnCTSOhfFOFMwKwI2WFBnidN+F1RGAPzFrCpEloH AZ6AE9Ompa4nnNdzkHLs =nfjR -----END PGP SIGNATURE----- From dougb at dougbarton.us Sat Aug 16 19:40:48 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 16 Aug 2014 12:40:48 -0700 Subject: [net-dns-users] Release candidate for Net::DNS 0.79 In-Reply-To: References: <53EE1B81.2090805@nlnetlabs.nl> Message-ID: <53EFB3C0.5000108@dougbarton.us> On 8/15/14 1:49 PM, Dick Franks wrote: > > On 15 August 2014 15:38, Willem Toorop > wrote: > [snip] > > ... [Net::DNS::Resolver::Recurse] now also provides > recursive resolving through the conventional query, search and send > methods, enabling drop in replacement of Net::DNS::Resolver objects. > > Please bear in mind the additional load this imposes on DNS infrastructure. Can you elaborate a bit on what you mean by this? Doug From rwfranks at acm.org Sun Aug 17 14:08:50 2014 From: rwfranks at acm.org (Dick Franks) Date: Sun, 17 Aug 2014 15:08:50 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 0.79 In-Reply-To: <53EFB3C0.5000108@dougbarton.us> References: <53EE1B81.2090805@nlnetlabs.nl> <53EFB3C0.5000108@dougbarton.us> Message-ID: On 16 August 2014 20:40, Doug Barton wrote: > On 8/15/14 1:49 PM, Dick Franks wrote: > >> >> On 15 August 2014 15:38, Willem Toorop > > wrote: >> [snip] >> >> ... [Net::DNS::Resolver::Recurse] now also provides >> recursive resolving through the conventional query, search and send >> methods, enabling drop in replacement of Net::DNS::Resolver objects. >> >> Please bear in mind the additional load this imposes on DNS >> infrastructure. >> > > Can you elaborate a bit on what you mean by this? > > Net::DNS::Resolver sends a single query to the default nameserver, with the RD bit set, which then does whatever queries are needed to find the answer. More importantly, the intermediate results are cached, which greatly reduces the traffic to the root and top level servers. Net::DNS::Resolver::Recurse performs all the necessary queries itself, with RD bit not set, and only a rudimentary cache which is discarded after each query. The result of the priming query to find the root nameservers is retained indefinitely. Try running the following code fragment and watch what happens. Then uncomment the recursive resolver line. This is a simple example; missing glue records produce much more complicated behaviour. #!/usr/bin/perl -w # use Net::DNS; use Net::DNS::Resolver::Recurse; my $resolver = new Net::DNS::Resolver( debug => 1 ); # $resolver = new Net::DNS::Resolver::Recurse( debug => 1 ); my $packet = $resolver->send( 'dougbarton.us', 'MX' ); __END__ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Sat Aug 16 22:37:31 2014 From: paul at nohats.ca (Paul Wouters) Date: Sat, 16 Aug 2014 18:37:31 -0400 (EDT) Subject: [net-dns-users] [NLnet Labs Maintainers] Release candidate for Net::DNS 0.79 In-Reply-To: <53EF1C60.6090004@nlnetlabs.nl> References: <53EE1B81.2090805@nlnetlabs.nl> <53EF1C60.6090004@nlnetlabs.nl> Message-ID: On Sat, 16 Aug 2014, Willem Toorop wrote: > The release candidate tarball posted in the previous announcement did > not actually include the OPENPGPKEY.pm file that implements the > OPENPGPKEY RR. > > Here is a new release candidate tarball which has this fixed: > > link http://www.net-dns.org/download/Net-DNS-0.78_4.tar.gz > sha1 5ce4f6afabb275de0253637446c84c776dd881c3 Seems to work, including doing an openpgpkey lookup for paul at nohats.ca. Thanks! Paul From rwfranks at acm.org Mon Aug 18 09:01:03 2014 From: rwfranks at acm.org (Dick Franks) Date: Mon, 18 Aug 2014 10:01:03 +0100 Subject: [net-dns-users] [NLnet Labs Maintainers] Release candidate for Net::DNS 0.79 In-Reply-To: References: <53EE1B81.2090805@nlnetlabs.nl> <53EF1C60.6090004@nlnetlabs.nl> Message-ID: Thanks Paul, When I read the draft, I was left with a lingering doubt about what exactly lurks within the Base64 encoded RDATA. I went with "key" and "keybin" mostly because that is what is used in similar RRs. In truth, this was just a simple cut-and-paste job. Would it be better described as "keyring" and "keyringbin" or am I misunderstandiing things? This will need to be settled quickly. Release will be on 22nd August. Your draft perhaps could be more illuminating by describing what the RDATA is supposed to contain, so guys like me can pick appropriate identifiers. Dick ________________________ On 16 August 2014 23:37, Paul Wouters wrote: > On Sat, 16 Aug 2014, Willem Toorop wrote: > > The release candidate tarball posted in the previous announcement did >> not actually include the OPENPGPKEY.pm file that implements the >> OPENPGPKEY RR. >> >> Here is a new release candidate tarball which has this fixed: >> >> link http://www.net-dns.org/download/Net-DNS-0.78_4.tar.gz >> sha1 5ce4f6afabb275de0253637446c84c776dd881c3 >> > > Seems to work, including doing an openpgpkey lookup for paul at nohats.ca. > > Thanks! > > Paul > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwessels at verisign.com Mon Aug 18 17:14:40 2014 From: dwessels at verisign.com (Wessels, Duane) Date: Mon, 18 Aug 2014 17:14:40 +0000 Subject: [net-dns-users] [NLnet Labs Maintainers] Release candidate for Net::DNS 0.79 In-Reply-To: References: <53EE1B81.2090805@nlnetlabs.nl> <53EF1C60.6090004@nlnetlabs.nl> Message-ID: <3244B52E-FFC3-4F0E-A486-857BE9F8B924@verisign.com> I believe "keyring" and "keyringbin" are the better descriptions. DW On Aug 18, 2014, at 2:01 AM, Dick Franks wrote: > Thanks Paul, > > When I read the draft, I was left with a lingering doubt about what exactly lurks within the Base64 encoded RDATA. > > I went with "key" and "keybin" mostly because that is what is used in similar RRs. In truth, this was just a simple cut-and-paste job. > > Would it be better described as "keyring" and "keyringbin" or am I misunderstandiing things? > > This will need to be settled quickly. Release will be on 22nd August. > > Your draft perhaps could be more illuminating by describing what the RDATA is supposed to contain, so guys like me can pick appropriate identifiers. > > > Dick > ________________________ > > > > On 16 August 2014 23:37, Paul Wouters wrote: > On Sat, 16 Aug 2014, Willem Toorop wrote: > > The release candidate tarball posted in the previous announcement did > not actually include the OPENPGPKEY.pm file that implements the > OPENPGPKEY RR. > > Here is a new release candidate tarball which has this fixed: > > link http://www.net-dns.org/download/Net-DNS-0.78_4.tar.gz > sha1 5ce4f6afabb275de0253637446c84c776dd881c3 > > Seems to work, including doing an openpgpkey lookup for paul at nohats.ca. > > Thanks! > > Paul > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From willem at nlnetlabs.nl Fri Aug 22 22:39:53 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Sat, 23 Aug 2014 00:39:53 +0200 Subject: [net-dns-users] Net::DNS 0.79 released Message-ID: <53F7C6B9.6080908@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear users of Net::DNS, I am pleased to announce version 0.79 of Net::DNS. Besides bugfixes this release has support for Android OS with Net::DNS::Resolver objects. Also an implementation of the draft OPENPGPKEY RR is within this release. Beware that the specification for this RR is still draft and is subject to change. The behaviour and/or interface of this implementation may also change. Use for experimentation only! Also, the recursive resolver Net::DNS::Resolver::Recurse has received a complete rework to make it a) always terminate, b) work properly and c) not make too many unnecessary requests. It now also provides recursive resolving through the conventional query, search and send methods. For a complete list see the Changes section below. link http://www.net-dns.org/download/Net-DNS-0.79.tar.gz sha1 de0b5a1be91305b733f843447d036a7129e524b6 Changes ======= Feature rt.cpan.org #98149 Add support for Android platform. Fix rt.cpan.org #97736 Net::DNS::Resolver->new mistakenly copies supplied arguments into default configuration on first instantiation. Fix rt.cpan.org #97502 Net::DNS::Resolver->retrans does not accept a value of 1 (uses 2 instead) Fix rt.cpan.org #83642 Configure CD flag in Net::DNS::Resolver->new Fix rt.cpan.org #81760 Reverted workaround for TXT issue preventing propagation of rule updates for SpamAssassin versions earlier than 3.4.0 Fix rt.cpan.org #16630 Net::DNS::Resolver::Recurse issues lots of IMHO unnecessary DNS requests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT98a5AAoJEOX4+CEvd6SYDH0P/3D+u/sFukMqfI470bUjFBFu Kem2pIg+R0lKruzc9dpXs+9lshgvotzWOVxS10wJ5f2R5SI5VUS3Bia5deIhUchi Lsewlfef+PxC9Yrq4DOT1bFwoa4MLbHBe711jprOeTn22/3+nC05KS1wlOiGup0y PBm8YHxdbacUTbYuugIWz2MTCtyE9m/JjADilPnGiX/fEIo5NZixfBHscu//r+zc fHQYEBs1sVC9lkHPAwoOleeodiHos6vpJqhF3fqBruSVQZ9HiK3xPoLN4Al9Pb6Q NtS+b1YlulTL9GkyQVBSWuqeGOAV5hOakRcaG5J832Ie+/X4JQ9jtHW2RyFFH75r YtrWX9nPspNCDGQqURUGHwzZMm2iv3hJvp2A+yNhoSKuYcZo9Zr45bkp4y4J1x2z uvbC1+JSBthKfRVoM/SUInSG0tFLXGqyHAe9OkMlkODUagC1b6KXW9O9USujpR1P crWbiW4PPhjP735cbqFi7hszDFDlMeafBR06B89nrMGGgx/nFdEiiqg/1EWl1hJ3 0EztcZdtg166cj8lBJaZ4uVPcyQvGU3bIKpfj/hX4UXvC09RouK8llFlzmLewLY6 nNwkIB3aQu2KXb8vocTqLCsRv2v9ecFp0rksLaBdVG+yHp6xo9/yiWsM2KaE64Qo cfAHtI5gSV3GE8IypuZ4 =ibBU -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Mon Sep 15 15:18:13 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 15 Sep 2014 17:18:13 +0200 Subject: [net-dns-users] Release candidate for Net:DNS 0.80 Message-ID: <54170335.4070209@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear users of Net::DNS We have a candidate for the upcoming single-bugfix release 0.80 of Net::DNS. With this release the "Too late to run INIT block ?" warnings that appear when "requiring" Net::DNS, instead of "using", are once again suppressed. The INIT block has no effect on Net::DNS operation and is only necessary for Net::DNS::SEC test scripts. Besides this bugfix, Net::DNS::Resolver can now, besides being forced to use IPv4 only, also be forced to use IPv6 only with the force_v6 method. Also documentation of Net::DNS::Resolver has been tidied. To make Cygwin installations more predictable and robust, Win32::IPHelper support for Resolver objects on Cygwin has been removed. Resolver objects are now based on the Cygwin specific base class always. For a complete list of changes and bugfixes see the CHANGES file. If no issues arise, the actual release will follow Monday the 22th of September 2014. link: http://www.net-dns.org/download/Net-DNS-0.79_2.tar.gz sha1: abc2e7e8abce7e68262b37b6d57d80d503580148 Changes ======= Removal of Win32::IPHelper support with cygwin Resolvers on Cygwin can get their DNS configuration from the registry directly via the /proc filesystem. Getting rid of the other method reduces dependencies and makes installations less error prone. Rework rt.cpan.org #96119 "Too late to run INIT block" warning for require Net::DNS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUFwMyAAoJEOX4+CEvd6SYgOgP+wfpyeJ/J6j+ZY+vRNtjeFko ZF0VNjMWatdESYTZdLfwKTDfn84JPTdyCHTut1KczcFW5zmiKVHEn/7w3MZyR45p EhLOEF5gUOGgmdMXLhJssijo8hPPdTLA3cXXYWSRcwROpKALtRXPvvJ0NrsPbMHW 6jZ6Ozl78Y8qdjEf9Y8PV6pa/EJBd5+oMIZGlXFNLxkZutbfKdY4Yfg3NUx1eweL mV1/O06+DmFBiIo8DBdzmakaKmEJCeTPUud4FdykYzWQEF6iyLYi6JHpSkFb5+q/ ZghFg+cdQ4jUDTeHIzcefOgXpjjckpAtKfM9vfl/iphjg1N87I0mlAQ8/p11wGCr gFIZuJtj9uVDduh50EQEJXvVpxgmxKtvib5okfFcJ65pBV78giP+oSdN84yN+aoM dKCxpqpKoRmU0ZPLgBsxJ1oHKIv4G5K5diG3z1w3Eck+4r1XWtRrJ5Xr58m31QdA k/pZjmBTWcJxxLiZKvL3n6+qGGeloOCVfo+J3RYAJNQqe73knR7UY9SiR+ElbYmF ySGL+c5XjROptRFkEdGiw6OVKL4eZ8xVg4HrJwPwSBtePDcybEWSp9imE+6lQgq0 XE/vrxNvWzpJlD3atZNO8P4Wo9uEQNuOfBsOAQt0jnm65hz/uSgkPQPGbDVveYjw xDbpoVLrxx/fcGauc5MU =a1d/ -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Mon Sep 22 11:57:47 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 22 Sep 2014 13:57:47 +0200 Subject: [net-dns-users] Net::DNS 0.80 released Message-ID: <54200EBB.9020003@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear users of Net::DNS, I am pleased to announce version 0.80 of Net::DNS. In this release a single bug is fixed; The "Too late to run INIT block ..." warnings that appeared when "requiring" Net::DNS, instead of "using", are once again suppressed. The INIT block has no effect on Net::DNS operation and is only necessary for Net::DNS::SEC test scripts. Besides this bug fix, Net::DNS::Resolver can now be forced to use IPv6 only with the force_v6 method. Also documentation of Net::DNS::Resolver has been tidied, improved and complemented. To make cygwin installations more predictable and robust, Win32::IPHelper support for cygwin has been removed. Resolver objects are now based on the cygwin specific base class always. For a complete list see the Changes section below. link: http://www.net-dns.org/download/Net-DNS-0.80.tar.gz sha1: 19df370fbdf214c9c51e2385f5c3aa791b347539 Changes ======= Removal of Win32::IPHelper support with cygwin Resolvers on Cygwin can get their DNS configuration from the registry directly via the /proc filesystem. Getting rid of the other method reduces dependencies and makes installations less error prone. Rework rt.cpan.org #96119 "Too late to run INIT block" warning for require Net::DNS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUIA6xAAoJEOX4+CEvd6SY6R0P/1nMzJWbcBETA9fvcxA4REGF F3JbHwuVpJ8BDkJxgL82H4pRpzzEkzuWf8grZxp1/qDvuHADKmFXTRWAkAPA8RVu iLRG02b9nsIJarp3nViYr7Kgertv0OPLy04j4ggs+BSecFvObKKcN0rHSiRyeRHe xO/1AZ+KXoxg/8HXwnCEJkeWFqKVID/cRRTdqBjrfBNUvsmTvRVK4GpBo4SPG+2S mARvIUXXkHpDBkhPqVbmJAIqRFA/yRGM6yLFF6Fky76GS13l+8znd9BED1Mxy4cL qfe6uHbC/VvIGhJE1fwYTEvN/S4nfur0tLiJTPdx2Q0uyi8UxX9os0pYJi/xAeaS X0QdTtYI3a8fzN4EEfmoq/39mzwteGe3qzhwZF3mfHl46oly162vme7+rTWeHwYK dJoSsio/p9xohLtFq9JSBT+XJeMqtay+79kdG+z6j/eK/SioucajCIhIOTpc8N0H jsPiGgyQwlR7MLxjhLvl/RdVdmKi9bF5BtbaiKyMYSjIYHIfJ5Jk0fUUr5+r+LnU LL0Jr/Q1BvlnsrPhfFah3jXQq/ZR4ZxScaUeLr/5Tuqn0JrwWsuuNQID1lJPl1Ia J2uMeLE33CkPmA09TYGe88Azmsc5ru5Z9ocQYqObTU0gkvdmE2Es117B9yNbrdAu LkMMhwpHQVzXQRug5PR6 =43pD -----END PGP SIGNATURE----- From rfg at tristatelogic.com Sun Sep 28 20:12:48 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 28 Sep 2014 13:12:48 -0700 Subject: [net-dns-users] AXFR of root zone Message-ID: <86848.1411935168@server1.tristatelogic.com> I need to be able to do an AXFR on the root zone. I tried this and got nothing: ======================================================================== #!/usr/local/bin/perl -w use Net::DNS; my $resolver = Net::DNS::Resolver->new; my @root_zone = $resolver->axfr ('.'); foreach my $rr (@root_zone) { $rr->print; } ======================================================================== OK, so how may I AXFR the root zone? There must be some trick I am missing. From jaap at NLnetLabs.nl Sun Sep 28 22:18:39 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 29 Sep 2014 00:18:39 +0200 Subject: [net-dns-users] AXFR of root zone In-Reply-To: <86848.1411935168@server1.tristatelogic.com> References: <86848.1411935168@server1.tristatelogic.com> Message-ID: <201409282218.s8SMIdIg089352@bela.nlnetlabs.nl> "Ronald F. Guilmette" writes: > I need to be able to do an AXFR on the root zone. use dig or ftp jaap From rwfranks at acm.org Sun Sep 28 22:42:41 2014 From: rwfranks at acm.org (Dick Franks) Date: Sun, 28 Sep 2014 23:42:41 +0100 Subject: [net-dns-users] AXFR of root zone In-Reply-To: <86848.1411935168@server1.tristatelogic.com> References: <86848.1411935168@server1.tristatelogic.com> Message-ID: On 28 September 2014 21:12, Ronald F. Guilmette wrote: > > I need to be able to do an AXFR on the root zone. > > I tried this and got nothing: > > ======================================================================== > #!/usr/local/bin/perl -w > > use Net::DNS; > > my $resolver = Net::DNS::Resolver->new; > > my @root_zone = $resolver->axfr ('.'); > > foreach my $rr (@root_zone) { > $rr->print; > } > ======================================================================== > > OK, so how may I AXFR the root zone? You can not. > There must be some trick I am missing. > 1) Your script fails because your local nameserver is not authoritative for the root zone. 2) Directing the request at one of the 13 root nameservers will also fail because, in common with the majority of operators, the good people who run the 13 authoritative root nameservers refuse AXFR requests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at nzrs.net.nz Sun Sep 28 22:51:43 2014 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Mon, 29 Sep 2014 11:51:43 +1300 Subject: [net-dns-users] AXFR of root zone In-Reply-To: References: <86848.1411935168@server1.tristatelogic.com> Message-ID: <542890FF.9060404@nzrs.net.nz> On 29/09/14 11:42 am, Dick Franks wrote: > > On 28 September 2014 21:12, Ronald F. Guilmette > wrote: > > > I need to be able to do an AXFR on the root zone. > > I tried this and got nothing: > > ======================================================================== > #!/usr/local/bin/perl -w > > use Net::DNS; > > my $resolver = Net::DNS::Resolver->new; > > my @root_zone = $resolver->axfr ('.'); > > foreach my $rr (@root_zone) { > $rr->print; > } > ======================================================================== > > OK, so how may I AXFR the root zone? > > You can not. > > > There must be some trick I am missing. > > > > 1) Your script fails because your local nameserver is not authoritative > for the root zone. Meaning you need to point your script to a server authoritative for the root zone to work, however, depending on your needs, you might want an alternative transport or source. > > 2) Directing the request at one of the 13 root nameservers will also > fail because, in common with the majority of operators, the good people > who run the 13 authoritative root nameservers refuse AXFR requests. Not exactly true: for n in a b c d e f g h i j k l m ; do echo "Root $n" ; dig axfr . @$n.root-servers.net | grep '^;; XFR' ; done Root a Root b ;; XFR size: 9076 records (messages 8, bytes 430404) Root c ;; XFR size: 9076 records (messages 8, bytes 430383) Root d Root e Root f ;; XFR size: 9076 records (messages 8, bytes 430383) Root g ;; XFR size: 9076 records (messages 8, bytes 430383) Root h Root i Root j Root k ;; XFR size: 9076 records (messages 24, bytes 387834) Root l Root m But it's guaranteed to stay that way. Cheers, > > > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 From rfg at tristatelogic.com Sun Sep 28 23:03:11 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 28 Sep 2014 16:03:11 -0700 Subject: [net-dns-users] AXFR of root zone In-Reply-To: Message-ID: <90442.1411945391@server1.tristatelogic.com> In message Dick Franks wrote: >On 28 September 2014 21:12, Ronald F. Guilmette >wrote: >> OK, so how may I AXFR the root zone? > >You can not. Actually, it appears to be quite possible to do this. >> There must be some trick I am missing. There was! See below. >1) Your script fails because your local nameserver is not authoritative for >the root zone. As has now been explained to me, yes, exactly. You are 100% correct that that was indeed the _primary_ problem. >2) Directing the request at one of the 13 root nameservers will also fail I'm sorry to have to disagree, but no, apparently, it won't. At least not for the B, C, and K root servers, which are the only ones other than the A server that I tried. Trying to perform the AXFR from the A server *definitely* fails, but it appears to work on for all of (or most of) the non-A servers. >because, in common with the majority of operators, the good people who run >the 13 authoritative root nameservers refuse AXFR requests. As a general rule, yes, it is indeed good policy to _not_ allow any Tom, Dick, and Harry to transfer one's zone files. However the root zone is kind-of special. It is important to a lot of people for a lot of reasons, and thus deserves to be open for inspection to the public at large. And indeed, as I have noted above, it apparently *is* in fact readily available (via AXFR) from many, or perhaps most of the official root servers (with the expection of the A server). However, as I have only just now been informed (on a different mailing list) there are even better places to fetch the root zone file from! Rather than going to any of the official root zone servers, it appears that one can go instead to one of two servers that ICANN has put up, and whose primary duties seem to be serving up the root zone... and a few other... for AXFR: http://www.dns.icann.org/services/axfr/ So I'm using those two servers now. The "trick"... which I have only just learned... to making the AXFR work is that one has to set the name servers explicitly before calling the Net::DNS::Resolver axfr method. Here is exactly how I am doing that now: my $res = Net::DNS::Resolver->new (nameservers => ['xfr.lax.dns.icann.org', 'xfr.cjr.dns.icann.org']); my @rr_list = $res->axfr ('.'); Works great! Try it! You'll like it! Regards, rfg P.S. Ya know, speaking of zone file security, a little known fact is that even a few TLD zone files are readily available for AXFR. In an ideal world, they all would be. There is nothing in any TLD zone file which has any reasonable need to be kept secret. From bmanning at isi.edu Sun Sep 28 21:15:17 2014 From: bmanning at isi.edu (manning bill) Date: Sun, 28 Sep 2014 14:15:17 -0700 Subject: [net-dns-users] AXFR of root zone In-Reply-To: <86848.1411935168@server1.tristatelogic.com> References: <86848.1411935168@server1.tristatelogic.com> Message-ID: I think both B and F allow axfr of the root zone. Or you can get a copy from ICANN /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 28September2014Sunday, at 13:12, Ronald F. Guilmette wrote: > > I need to be able to do an AXFR on the root zone. > > I tried this and got nothing: > > ======================================================================== > #!/usr/local/bin/perl -w > > use Net::DNS; > > my $resolver = Net::DNS::Resolver->new; > > my @root_zone = $resolver->axfr ('.'); > > foreach my $rr (@root_zone) { > $rr->print; > } > ======================================================================== > > OK, so how may I AXFR the root zone? > > There must be some trick I am missing. > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users From benjamin.zwittnig at register.si Mon Sep 29 07:51:43 2014 From: benjamin.zwittnig at register.si (Benjamin Zwittnig) Date: Mon, 29 Sep 2014 09:51:43 +0200 Subject: [net-dns-users] AXFR of root zone In-Reply-To: References: <86848.1411935168@server1.tristatelogic.com> Message-ID: <54290F8F.6050708@register.si> On 09/28/2014 11:15 PM, manning bill wrote: > I think both B and F allow axfr of the root zone. Or you can get a copy from ICANN This should also work: $ ldns-walk -f . Benjamin From dwessels at verisign.com Tue Sep 30 22:14:02 2014 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 30 Sep 2014 22:14:02 +0000 Subject: [net-dns-users] RRSIG->verify() bug Net::DNS::SEC 0.18 and later In-Reply-To: <4CE9CAB8-D0D2-4305-99F6-3C021C4DB0AF@verisign.com> References: <4CE9CAB8-D0D2-4305-99F6-3C021C4DB0AF@verisign.com> Message-ID: Whoops, that patch is not the solution for this bug. However, I'm pretty sure it has something to do with upper/lower case! DW On Sep 30, 2014, at 3:06 PM, Duane Wessels wrote: > Today I found one of my DNSSEC tools utilizing Net::DNS::SEC was reporting > mysterious validation failures. Tracked it to an RRSIG record with an > uppercase Signer's Name field (see 'dig us RRSIG'). > > I believe this may be the fix: > > > Index: RR/RRSIG.pm > =================================================================== > --- RR/RRSIG.pm (revision 1267) > +++ RR/RRSIG.pm (working copy) > @@ -262,7 +262,7 @@ > sigexpiration => $args{sigex} || 0, > algorithm => $private->algorithm, > keytag => $private->keytag, > - signame => $private->signame, > + signame => lc($private->signame), > ); > > $args{sigval} ||= 30 unless $self->{sigexpiration}; > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dwessels at verisign.com Tue Sep 30 22:25:15 2014 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 30 Sep 2014 22:25:15 +0000 Subject: [net-dns-users] RRSIG->verify() bug Net::DNS::SEC 0.18 and later In-Reply-To: References: <4CE9CAB8-D0D2-4305-99F6-3C021C4DB0AF@verisign.com> Message-ID: Maybe this is it? Index: RR/RRSIG.pm =================================================================== --- RR/RRSIG.pm (revision 1267) +++ RR/RRSIG.pm (working copy) @@ -516,7 +516,7 @@ $self->{typecovered} = 0 unless ref($rawdata); # SIG0 my @field = qw(typecovered algorithm labels orgttl sigexpiration siginception keytag); - my $sigdata = pack 'n C2 N3 n a*', @{$self}{@field}, $self->{signame}->encode; + my $sigdata = pack 'n C2 N3 n a*', @{$self}{@field}, $self->{signame}->canonical; print "preamble:\t", unpack( 'H*', $sigdata ) if $debug; unless ( ref($rawdata) ) { # SIG0 case On Sep 30, 2014, at 3:14 PM, Duane Wessels wrote: > Whoops, that patch is not the solution for this bug. However, I'm > pretty sure it has something to do with upper/lower case! > > DW > > > On Sep 30, 2014, at 3:06 PM, Duane Wessels wrote: > >> Today I found one of my DNSSEC tools utilizing Net::DNS::SEC was reporting >> mysterious validation failures. Tracked it to an RRSIG record with an >> uppercase Signer's Name field (see 'dig us RRSIG'). >> >> I believe this may be the fix: >> >> >> Index: RR/RRSIG.pm >> =================================================================== >> --- RR/RRSIG.pm (revision 1267) >> +++ RR/RRSIG.pm (working copy) >> @@ -262,7 +262,7 @@ >> sigexpiration => $args{sigex} || 0, >> algorithm => $private->algorithm, >> keytag => $private->keytag, >> - signame => $private->signame, >> + signame => lc($private->signame), >> ); >> >> $args{sigval} ||= 30 unless $self->{sigexpiration}; >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dwessels at verisign.com Tue Sep 30 22:06:11 2014 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 30 Sep 2014 22:06:11 +0000 Subject: [net-dns-users] RRSIG->verify() bug Net::DNS::SEC 0.18 and later Message-ID: <4CE9CAB8-D0D2-4305-99F6-3C021C4DB0AF@verisign.com> Today I found one of my DNSSEC tools utilizing Net::DNS::SEC was reporting mysterious validation failures. Tracked it to an RRSIG record with an uppercase Signer's Name field (see 'dig us RRSIG'). I believe this may be the fix: Index: RR/RRSIG.pm =================================================================== --- RR/RRSIG.pm (revision 1267) +++ RR/RRSIG.pm (working copy) @@ -262,7 +262,7 @@ sigexpiration => $args{sigex} || 0, algorithm => $private->algorithm, keytag => $private->keytag, - signame => $private->signame, + signame => lc($private->signame), ); $args{sigval} ||= 30 unless $self->{sigexpiration}; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rwfranks at acm.org Tue Sep 30 23:57:46 2014 From: rwfranks at acm.org (Dick Franks) Date: Wed, 1 Oct 2014 00:57:46 +0100 Subject: [net-dns-users] RRSIG->verify() bug Net::DNS::SEC 0.18 and later In-Reply-To: References: <4CE9CAB8-D0D2-4305-99F6-3C021C4DB0AF@verisign.com> Message-ID: $self->{signame}->canonical is not the solution (not in Net::DNS pre-0.73). Please can you raise a bug report in CPAN RT, citing RFC4034 (6.2) Dick ________________________ On 30 September 2014 23:25, Wessels, Duane wrote: > Maybe this is it? > > Index: RR/RRSIG.pm > =================================================================== > --- RR/RRSIG.pm (revision 1267) > +++ RR/RRSIG.pm (working copy) > @@ -516,7 +516,7 @@ > $self->{typecovered} = 0 unless ref($rawdata); # SIG0 > > my @field = qw(typecovered algorithm labels orgttl sigexpiration > siginception keytag); > - my $sigdata = pack 'n C2 N3 n a*', @{$self}{@field}, > $self->{signame}->encode; > + my $sigdata = pack 'n C2 N3 n a*', @{$self}{@field}, > $self->{signame}->canonical; > print "preamble:\t", unpack( 'H*', $sigdata ) if $debug; > > unless ( ref($rawdata) ) { # SIG0 case > > > > On Sep 30, 2014, at 3:14 PM, Duane Wessels wrote: > > > Whoops, that patch is not the solution for this bug. However, I'm > > pretty sure it has something to do with upper/lower case! > > > > DW > > > > > > On Sep 30, 2014, at 3:06 PM, Duane Wessels > wrote: > > > >> Today I found one of my DNSSEC tools utilizing Net::DNS::SEC was > reporting > >> mysterious validation failures. Tracked it to an RRSIG record with an > >> uppercase Signer's Name field (see 'dig us RRSIG'). > >> > >> I believe this may be the fix: > >> > >> > >> Index: RR/RRSIG.pm > >> =================================================================== > >> --- RR/RRSIG.pm (revision 1267) > >> +++ RR/RRSIG.pm (working copy) > >> @@ -262,7 +262,7 @@ > >> sigexpiration => $args{sigex} || 0, > >> algorithm => $private->algorithm, > >> keytag => $private->keytag, > >> - signame => $private->signame, > >> + signame => lc($private->signame), > >> ); > >> > >> $args{sigval} ||= 30 unless $self->{sigexpiration}; > >> > > > > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwessels at verisign.com Tue Oct 14 17:29:34 2014 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 14 Oct 2014 17:29:34 +0000 Subject: [net-dns-users] ECDSA support Message-ID: <4D280B8D-4F34-4CE6-8D8A-E98C56E6FF77@verisign.com> Geoff Huston gave a talk at the DNS-OARC workshop that increased attention on ECC-based DNSSEC. I have a number of tools that use Net::DNS::SEC and these tools currently cannot validate DNSSEC algorithms 13 and 14 (as far as I can tell). I see https://rt.cpan.org/Public/Bug/Display.html?id=85031 was filed some time ago. I'm wondering if any of the Net::DNS::SEC developers have been thinking about ECDSA support, or could provide pointers for us on how to begin implementing it? DW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tlhackque at yahoo.com Sat Oct 18 18:32:25 2014 From: tlhackque at yahoo.com (tlhackque) Date: Sat, 18 Oct 2014 14:32:25 -0400 Subject: [net-dns-users] 0.80: BADKEY BADSIG with TSIG; random errors Message-ID: <5442B239.5030604@yahoo.com> I upgraded from 0.6? to 0.80, and immediately things broke. RTs 99527, 99528, 99531 and 99571 resulted. Quick summary for everyone: o Random errors due to use of undefined Perl syntax ( (my|our) variable = initializer (if|unless|for|while..)). Can hit anywhere, quite likely in a persistent environment (e.g. mod_perl). o tsig() now can take a filename. Some filenames are mis-parsed, resulting in an invalid key name being sent. BADKEY errors o axfr() now verifies responses that are TSIG-signed (because the request is TSIG-signed). This is unconditional, and broken. Specifically, axfr receives the response, parses it & discards the wire data. When the time comes to verify, it reconstructs the wire data (deleting the TSIG record and modifying the header as required). However, encode( decode( wire_data ) ) does not always equal wire_data bit for bit. (It will be semantically equal, however.). Since the signature is computed bit-for-bit by the server, the Net::DNS computed signature does not match. (One reason: label compression. Net::DNS always does it. The server on the other end of the wire: (a) might not (b) might compress some labels but not others (c) might use different compression pointers from Net::DNS for the same labels.) BADSIG errors result. Thus, the actual wire data must be saved for signed answers; this will be an ugly fix. NOTE: This can also happen with regular queries if you call $answer->verify(). But at least it's not automagic for regular queries. See the RTs for more detail. I hope this saves someone else some pain; tracking these down is non-trivial. -- This communication may not represent my employer's views, if any, on the matters discussed. From willem at nlnetlabs.nl Fri Oct 24 08:57:59 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 24 Oct 2014 10:57:59 +0200 Subject: [net-dns-users] Net::DNS::SEC 0.21 released Message-ID: <544A1497.6070605@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear users of Net::DNS::SEC, We have a new Net::DNS::SEC release: 0.21. This is again a single bugfix release, rt.cpan.org #99250, that restores canonicalization of a RRSIG?s Signer Name before performing validation. Besides this fix, this release also corrects a few declaration with statement modifier occasions, as pointed out in rt.cpan.org #99527. Package maintainers beware! Net::DNS::SEC::Private has always had an implicit dependency on Crypt::OpenSSL::Random. This dependency has been made explicit in this release; both in the use statements in Private.pm as in the PREREQ_PM list in Makefile.PL. Private.pm will no longer load if Crypt::OpenSSL::Random is not available. Because of the smallness of the change we consider it safe and acceptable to shorten the release cycle and do a full release immediately. For a complete list of changes see the Changes sections below. link http://www.net-dns.org/download/Net-DNS-SEC-0.21.tar.gz sha1 e106cd0c887963ef03834170feae9d07f9ab2dad Changes ======= Fix: rt.cpan.org #99250 [RRSIG] validation fails when Signer's Name is upper case Fix: rt.cpan.org #99106 Premature end of base64 data (in 14-misc.t test script) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUShSXAAoJEOX4+CEvd6SYrcAP/2hFqciGffaKWF6ZZRtG5uUL asWkMDK2g/oCEo6IbAsTZjJ9TW883OKZBHxPpVTWx57hor6NDGJbHvQFIydw/4c6 hWGS+9B8BqVahW5NG9yJFo6G5K49PFSausnf7MXjzEwkAyeugx1fiNuhgLiwGAPc UiEc//5/EI7UfoLZTwbjB+pwnZJENpv2i7E6CANl5EzKO/ejGrklnSEMYbomBXd0 I/dhDbaz1obW5st6T6tu4yOK3PNY/mLPyiBV06AK1N9PX6/siXZqhrqdHLD7qpr7 B2e3Z+wmg76mfDKOcgkmie0NBM6OTFOUVY+30qNU7ixcxIJBJsoFWEWZwW55BhPy nn4BeAeEJW0phbWoHDzhEz04iH8fGUfEJe+E5baOty0GjFMvTEJWoA0xQFlQpSrm G6CjYfXxVjXGvduHk5y78fST6++qh630yCN8oR1NAss3y+0N11+MgM2i4pyeUuXQ n4dqnqlOcdF89bUDXXWHtXnYRVUuu5ED0Fjt1GnbruKRYOAHbpMuxZzf9YoDnGKm 7sCOS0Vl6B2IcWURXietyG4lgbWmynsfCtE3aE/9umdrmWx6Cmd8+Y2o79cG2j/L TZSvvrbnNxjo38QS4xEUoyWxeot066/IhgXMj3ywCeowuBfrF/dwWKr3V364dEcr ukSfkYTMAx6y53mwV4HA =N2lr -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Oct 24 09:25:11 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 24 Oct 2014 11:25:11 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 0.81 Message-ID: <544A1AF7.5000001@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear users of Net::DNS, We have a candidate for the upcoming bugfix release 0.81 of Net::DNS. This release addresses several bugs that came up in the last month, not least because of the review and assessment of tlhackque. Thank you tlhackque. For a complete list see the Changes section below. Because we had no platform or version sensitive changes, we consider it safe to shorten the release cycle a little. If no issues arise, the actual release will follow Wednesday the 29th of October 2014. link http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz sha1 e07f54fd3cef69df0dbb55799050b93b29527852 Changes ======= Fix rt.cpan.org #99571 AXFR BADSIG failures Fix rt.cpan.org #99531 Resolver doc error - when is a 'bug' a 'bug'? [TSIG verification] Fix rt.cpan.org #99528 TSIG::create fails with some filenames Fix rt.cpan.org #99527 Random errors... [declaration with statement modifier] Fix rt.cpan.org #99429 Infinite recursion in Net::DNS::Resolver::Recurse::send when following certain delegations with empty-non terminals. Fix rt.cpan.org #99320 Net::DNS::ZoneFile bug in "$ORIGIN ." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUShr3AAoJEOX4+CEvd6SYrz4P/2HDgXQt0HyJ6DV92eXoQ6AC KWG6Zs50hvggHkmKNw02lPoVrTqfFTX/13O4hzAi22S/LViIpZmG+TeCrrTcnTFc 63kUyaaWvW/gpzEFcz4LP5J9/tFZASN0Q54ERq0Q4yBfLO/bWnx7Av33Qs5cF6oY VL/gwuRrxm1LbUYwZyISsMEmFkt83/XfLfYs521h44dc8GSUujMUvv9Nd+O3h9dT x8LE5F5CWdid2vYHlf1W7exzwLklMi8QnFUKKY3BwAtiUJuPC8Ooz9wEGQzifcnk 70jZV/6ujVQfSIlRlOTKvovFjSOdaOecA3wV4tOyp8V3NawQu7qI2Iv4eBWc6ZAf Ts/xqZwcBbKi69Zo1ZNirf8+C33iBiA8ymySAgWOMNWZ+Qef3JAubgusyB2EkvlM WQQTeXaV+xvukjK+P0TVfhKnIsLuPry+GBJf+2HcjC0GxZiuFElh1PKdrjR3ZNw0 z/h64bPhmn2FJ9QB9WF1MyfF7wipOMmNEkzT1FuUg7+fdGbAzHjtI7FSrGWsJnmy dIq7fi2kmckKYxAvhkC8iuzkU7t8PJgnumbtb0b3NbmUPjeKZPWZPAk0R2n8ItX8 ie9OrBvEZR44/SwqQFd1r+nXukAJ1B33hxxjBoobW8oi+pcIj2BKP+Ls6jPdnclk qTC0U5Lno7Mlg1QkThcg =4wSM -----END PGP SIGNATURE----- From tlhackque at yahoo.com Fri Oct 24 10:46:56 2014 From: tlhackque at yahoo.com (tlhackque) Date: Fri, 24 Oct 2014 06:46:56 -0400 Subject: [net-dns-users] New Release candidates In-Reply-To: References: Message-ID: <544A2E20.2020300@yahoo.com> On 24-Oct-14 06:00, net-dns-users-request at nlnetlabs.nl wrote: > 1. Net::DNS::SEC 0.21 released (Willem Toorop) > 2. Release candidate for Net::DNS 0.81 (Willem Toorop) > First, a public thank you to Dick Franks for promptly working on the RTs that I raised, including through the weekend! And thanks to anyone else who worked behind the scenes. Second, in attempting to get the releases mentioned for some testing, I discovered that net-dns.org's IPv6 address doesn't seem to have the webserver on-line: wget http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz --2014-10-24 06:07:04-- http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz Resolving www.net-dns.org (www.net-dns.org)... 2a04:b900::2:0:0:22, 185.49.140.22 Connecting to www.net-dns.org (www.net-dns.org)|2a04:b900::2:0:0:22|:80... [Hang] I have connectivity to the IPv6 address: ping6 2a04:b900::2:0:0:22 PING 2a04:b900::2:0:0:22(2a04:b900::2:0:0:22) 56 data bytes 64 bytes from 2a04:b900::2:0:0:22: icmp_seq=0 ttl=51 time=146 ms 64 bytes from 2a04:b900::2:0:0:22: icmp_seq=1 ttl=51 time=142 ms --- 2a04:b900::2:0:0:22 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 142.109/144.355/146.602/2.278 ms, pipe 2 telnet 2a04:b900::2:0:0:22 80 Trying 2a04:b900::2:0:0:22... [hang] host www.net-dns.org www.net-dns.org has address 185.49.140.22 www.net-dns.org has IPv6 address 2a04:b900::2:0:0:22 So there's a firewall or webserver configuration issue. I did access the files via IPv4, but you probably should fix IPv6... There is also a rather unusual PTR record/CNAME chain for the IPv6 address: dig -x 2a04:b900::2:0:0:22 ; <<>> DiG 9.9.1-P2 <<>> -x 2a04:b900::2:0:0:22 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33293 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;2.2.0.0.0.0.0.0.0.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.b.4.0.a.2.ip6.arpa. IN PTR ;; ANSWER SECTION: 2.2.0.0.0.0.0.0.0.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.b.4.0.a.2.ip6.arpa. 2224 IN CNAME 22.140.49.185.in-addr.arpa. 22.140.49.185.in-addr.arpa. 2225 IN PTR blogs.nlnetlabs.nl. ;; AUTHORITY SECTION: 140.49.185.in-addr.arpa. 2225 IN NS mcvax.nlnetlabs.nl. 140.49.185.in-addr.arpa. 2225 IN NS ns.nlnetlabs.nl. ;; ADDITIONAL SECTION: mcvax.nlnetlabs.nl. 5618 IN A 192.16.197.229 ;; Query time: 8 msec I don't think it's illegal - but it is strange to have an IPv6 address PTR resolve to a different hostname... IPv6 addresses are cheap enough that it's recommended to allocate one per service. -- This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Fri Oct 24 12:11:38 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 24 Oct 2014 14:11:38 +0200 Subject: [net-dns-users] New Release candidates In-Reply-To: <544A2E20.2020300@yahoo.com> References: <544A2E20.2020300@yahoo.com> Message-ID: <544A41FA.7060009@nlnetlabs.nl> Sorry tlhackque, We do not have firewall issues. I have checked from several ring nodes from the NLNOG ring, and they are all able to connect over IPv6 fine. I've looked at some of the unreachables and they indeed do have IPv6 issues. nlnetlabs at nlnetlabs01:~$ ring-http -6 'www.net-dns.org' 256 servers: OK unreachable via: xlshosting01 cambrium01 tripleit01 inotel01 rezopole01 voxel01 lagis01 keenondots01 claranet02 backbone02 bluezonejordan01 nicchile01 rnp01 beanfield01 robtex01 rackfish01 trueinternet01 popsc01 iplan01 sapphire01 maxitel01 itps01 ssh connection failed: bdhub01 blacklotus01 citynetwork01 cloudnl01 cybercom01 ehsab02 enestdata01 mainloop01 riseup01 nlnetlabs at nlnetlabs01:~$ Maybe there is another issue (Path MTU black hole?). Are you able to fetch a small file like http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz.sha1 ? Thanks for reporting though! -- Willem Op 24-10-14 om 12:46 schreef tlhackque: > On 24-Oct-14 06:00, net-dns-users-request at nlnetlabs.nl wrote: >> 1. Net::DNS::SEC 0.21 released (Willem Toorop) >> 2. Release candidate for Net::DNS 0.81 (Willem Toorop) >> > First, a public thank you to Dick Franks for promptly working on the RTs > that I raised, including through the weekend! And thanks to anyone else > who worked behind the scenes. > > Second, in attempting to get the releases mentioned for some testing, I > discovered that net-dns.org's IPv6 address doesn't seem to have the > webserver on-line: > > wget http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz > --2014-10-24 06:07:04-- > http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz > Resolving www.net-dns.org (www.net-dns.org)... 2a04:b900::2:0:0:22, > 185.49.140.22 > Connecting to www.net-dns.org (www.net-dns.org)|2a04:b900::2:0:0:22|:80... > [Hang] > > I have connectivity to the IPv6 address: > ping6 2a04:b900::2:0:0:22 > PING 2a04:b900::2:0:0:22(2a04:b900::2:0:0:22) 56 data bytes > 64 bytes from 2a04:b900::2:0:0:22: icmp_seq=0 ttl=51 time=146 ms > 64 bytes from 2a04:b900::2:0:0:22: icmp_seq=1 ttl=51 time=142 ms > > --- 2a04:b900::2:0:0:22 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1002ms > rtt min/avg/max/mdev = 142.109/144.355/146.602/2.278 ms, pipe 2 > > telnet 2a04:b900::2:0:0:22 80 > Trying 2a04:b900::2:0:0:22... > [hang] > > host www.net-dns.org > www.net-dns.org has address 185.49.140.22 > www.net-dns.org has IPv6 address 2a04:b900::2:0:0:22 > > So there's a firewall or webserver configuration issue. > > I did access the files via IPv4, but you probably should fix IPv6... > > There is also a rather unusual PTR record/CNAME chain for the IPv6 address: > dig -x 2a04:b900::2:0:0:22 > > ; <<>> DiG 9.9.1-P2 <<>> -x 2a04:b900::2:0:0:22 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33293 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;2.2.0.0.0.0.0.0.0.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.b.4.0.a.2.ip6.arpa. > IN PTR > > ;; ANSWER SECTION: > 2.2.0.0.0.0.0.0.0.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.b.4.0.a.2.ip6.arpa. 2224 > IN CNAME 22.140.49.185.in-addr.arpa. > 22.140.49.185.in-addr.arpa. 2225 IN PTR blogs.nlnetlabs.nl. > > ;; AUTHORITY SECTION: > 140.49.185.in-addr.arpa. 2225 IN NS mcvax.nlnetlabs.nl. > 140.49.185.in-addr.arpa. 2225 IN NS ns.nlnetlabs.nl. > > ;; ADDITIONAL SECTION: > mcvax.nlnetlabs.nl. 5618 IN A 192.16.197.229 > > ;; Query time: 8 msec > > I don't think it's illegal - but it is strange to have an IPv6 address > PTR resolve to a different hostname... IPv6 addresses are cheap enough > that it's recommended to allocate one per service. > > -- > This communication may not represent my employer's views, > if any, on the matters discussed. > > > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > From tlhackque at yahoo.com Sat Oct 25 10:33:51 2014 From: tlhackque at yahoo.com (tlhackque) Date: Sat, 25 Oct 2014 06:33:51 -0400 Subject: [net-dns-users] New Release candidates In-Reply-To: <544A41FA.7060009@nlnetlabs.nl> References: <544A2E20.2020300@yahoo.com> <544A41FA.7060009@nlnetlabs.nl> Message-ID: <544B7C8F.1080206@yahoo.com> > Sorry tlhackque, > > We do not have firewall issues. I have checked from several ring nodes > from the NLNOG ring, and they are all able to connect over IPv6 fine. > I've looked at some of the unreachables and they indeed do have IPv6 issues. > > nlnetlabs at nlnetlabs01:~$ ring-http -6 'www.net-dns.org' > 256 servers: OK > unreachable via: xlshosting01 cambrium01 tripleit01 inotel01 rezopole01 > voxel01 lagis01 keenondots01 claranet02 backbone02 bluezonejordan01 > nicchile01 rnp01 beanfield01 robtex01 rackfish01 trueinternet01 popsc01 > iplan01 sapphire01 maxitel01 itps01 > ssh connection failed: bdhub01 blacklotus01 citynetwork01 cloudnl01 > cybercom01 ehsab02 enestdata01 mainloop01 riseup01 > nlnetlabs at nlnetlabs01:~$ > > Maybe there is another issue (Path MTU black hole?). > Are you able to fetch a small file like > http://www.net-dns.org/download/Net-DNS-0.80_2.tar.gz.sha1 ? Thanks for investigating. Telnet fails to connect from here, so it's not an MTU path issue. (Or at least, these connections aren't getting that far.) ping shows the expected MTU, and is happy to fragment larger packets. I'll work on tracking it down from this end. So far, the new releases look good. > Thanks for reporting though! > > -- Willem From tlhackque at yahoo.com Sun Oct 26 11:36:26 2014 From: tlhackque at yahoo.com (tlhackque) Date: Sun, 26 Oct 2014 07:36:26 -0400 Subject: [net-dns-users] RC 0.81 Message-ID: <544CDCBA.9050703@yahoo.com> Since I noted here that 0.81 RC (0.80_2) looked good -- subsequent code review turned up an issue with one of the fixes. Details in RT. -- This communication may not represent my employer's views, if any, on the matters discussed. From clists at buxtonfamily.us Mon Oct 27 04:02:01 2014 From: clists at buxtonfamily.us (Chris Buxton) Date: Sun, 26 Oct 2014 21:02:01 -0700 Subject: [net-dns-users] Parsing MS DNS zone files Message-ID: <54A46235-2FB4-4AAD-BE47-58365F2402B4@buxtonfamily.us> Hi, I'm trying to parse MS DNS zone files using Net::DNS::Zonefile, but it's having issues with two non-standard Microsoft additions to the format: 1. Age values. For example: _kerberos._tcp.direktion._sites.dc._msdcs [AGE:3627351] 600 SRV 0 100 88 atzt0009.at.zurich.com. 2. WINS records. For example: @ 0 WINS L2 C900 ( 192.168.47.221 192.168.47.222 ) I don't actually need these data points. I just need to have Net::DNS::ZoneFile::read not fail (return null) when encountering them. I have a lot of this data, such that it would be painful to rely on manual remediation. Does anyone have any ideas? Thanks, Chris Buxton -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Mon Oct 27 06:49:42 2014 From: rwfranks at acm.org (Dick Franks) Date: Mon, 27 Oct 2014 06:49:42 +0000 Subject: [net-dns-users] Parsing MS DNS zone files In-Reply-To: <54A46235-2FB4-4AAD-BE47-58365F2402B4@buxtonfamily.us> References: <54A46235-2FB4-4AAD-BE47-58365F2402B4@buxtonfamily.us> Message-ID: Simply handle the exception: use Net::DNS::ZoneFile; my $zonefile = new Net::DNS::ZoneFile($filename); while ( my $rr = eval{ $zonefile->read } || $@ ) { print($@) && next if $@; $rr->print; # or whatever } At the moment you get the full confession. I will tone it down in next revision. Dick Franks ________________________ On 27 October 2014 04:02, Chris Buxton wrote: > Hi, > > I'm trying to parse MS DNS zone files using Net::DNS::Zonefile, but it's > having issues with two non-standard Microsoft additions to the format: > > 1. Age values. For example: > > _kerberos._tcp.direktion._sites.dc._msdcs [AGE:3627351] 600 SRV 0 > 100 88 atzt0009.at.zurich.com. > > 2. WINS records. For example: > > @ 0 WINS L2 C900 ( > 192.168.47.221 > 192.168.47.222 ) > > I don't actually need these data points. I just need to have > Net::DNS::ZoneFile::read not fail (return null) when encountering them. I > have a lot of this data, such that it would be painful to rely on manual > remediation. Does anyone have any ideas? > > Thanks, > Chris Buxton > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlhackque at yahoo.com Mon Oct 27 11:52:06 2014 From: tlhackque at yahoo.com (tlhackque) Date: Mon, 27 Oct 2014 07:52:06 -0400 Subject: [net-dns-users] Parsing MS DNS zone files In-Reply-To: <54A46235-2FB4-4AAD-BE47-58365F2402B4@buxtonfamily.us> References: <54A46235-2FB4-4AAD-BE47-58365F2402B4@buxtonfamily.us> Message-ID: <544E31E6.6000207@yahoo.com> On 27-Oct-14 00:02, Chris Buxton wrote: > Hi, > > I'm trying to parse MS DNS zone files using Net::DNS::Zonefile, but > it's having issues with two non-standard Microsoft additions to the > format: > > 1. Age values. For example: > > _kerberos._tcp.direktion._sites.dc._msdcs [AGE:3627351] 600 SRV > 0 100 88 atzt0009.at.zurich.com . > > 2. WINS records. For example: > > @ 0 WINS L2 C900 ( > 192.168.47.221 > 192.168.47.222 ) > > I don't actually need these data points. I just need to have > Net::DNS::ZoneFile::read not fail (return null) when encountering > them. I have a lot of this data, such that it would be painful to rely > on manual remediation. Does anyone have any ideas? > > Thanks, > Chris Buxton I'm not an MS DNS admin expert - perhaps there's an 'export a standard zonefile' utility somewhere. A quick search didn't turn one up, but I may have missed it. One approach is to use axfr() instead of reading the file. You can tell the MS server not to transfer these records - there's a 'do not repicate this record' checkbox somewhere. See http://technet.microsoft.com/en-us/library/cc784258(v=ws.10).aspx. Or you can use Dick's approach and trap the exception - though I'd match for these cases on the error string in case you trip on another error from time to time. I'd use axfr() if possible - that's the standard API to DNS. M$ extensions are always a moving target. At least you can beat them up if that's broken. If axfr() isn't allowed from the hosting server, or if these files aren't served by one: I might even go as far as running a private M$ server with read-only access to these zone files, on a non-standard port rather than forcibly read the files... I really, really don't like chasing M$... If at some point you need the WINS/WINS-R records, it wouldn't be hard to write a Net::DNS class for them. You might suggest an API for registering a private class so that you don't have to patch the dispatch hash. Then you could submit it to CPAN - assuming the Net::DNS folks don't take it. Hmm, looks like a 5cent response to a 1cent question. Oh, well. Good luck. -- This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Wed Oct 29 14:04:55 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 29 Oct 2014 15:04:55 +0100 Subject: [net-dns-users] Net::DNS 0.81 released Message-ID: <5450F407.1000104@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear users of Net::DNS, We have just released version 0.81 of Net::DNS. This release addresses several bugs found in the last month, not least because of the review and assessment of tlhackque. Thank you tlhackque. For a complete list of changes and bugfixes see the Changes below. link http://www.net-dns.org/download/Net-DNS-0.81.tar.gz sha1 b0f08e555587ccd8a063196db1a57ef1acd818bf Changes ======= Fix rt.cpan.org #99571 AXFR BADSIG failures Fix rt.cpan.org #99531 Resolver doc error - when is a 'bug' a 'bug'? [TSIG verification] Fix rt.cpan.org #99528 TSIG::create fails with some filenames Fix rt.cpan.org #99527 Random errors... [declaration with statement modifier] Fix rt.cpan.org #99429 Infinite recursion in Net::DNS::Resolver::Recurse::send when following certain delegations with empty-non terminals. Fix rt.cpan.org #99320 Net::DNS::ZoneFile bug in "$ORIGIN ." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUUPQHAAoJEOX4+CEvd6SYAcgP/RwoX4mQQpwyXfUSeThWGih/ 6vsu3h0CMz8vH+rddKLp/4bNseqCvsjYVqWsMfDRtpcq6kpM1oOUFNTGsf1DhLIy 7y2G98sMa2B107uewPX7XrPhH6etADd1I61Aano56rZUZff2285x01MM965ik5dX LRGYdTeEZWiJLu4nDuLKqjnGShbswg6kZM/mHn1x8Mo5cX0VMM6MPCcZox6VuOy1 SKBO6NjGXmyCBwlwiQGuYZEGmW0R31XG8BuELWY2Ij+KyiXcO4bf4zq983HLP3oc mixKojjk83sGtUDsiIaTRrDUx2AY1ReTWWMv5c4GZmtZDDAkUajS+CZlNORA3qpU jGmfoPuuUTYG+BRQKvfPIhJ1utj+eUKAkt2kQQ/fjrzLTP03qDTHgeX0wItgdOpW W8u/8kPmIAVPQafTTpuKncNGPg58blQSSkpDyBL7hFNThY6ujXitsGQTHllW+VZk gh1JPEsuOXQoCqd7oEVumZRBUGl2P+B7X3HG7LwERtPPnxbbM/hbwLA3Y4ZAGark 2dWpWaSdyJf4Z9yJN79pgNWHUeva9Sw/vFmQjn7OJd0hwE62rdjjQGZXCxK3txjt AElr5wzwFboZr/1D254n2E40O5zM065ESczELV45LbbFdhFAu0dTJRzia1LqkSrU y55L/0Sr9Ka+bjNx/7Cv =Qa0N -----END PGP SIGNATURE----- From clists at buxtonfamily.us Wed Oct 29 21:52:13 2014 From: clists at buxtonfamily.us (Chris Buxton) Date: Wed, 29 Oct 2014 14:52:13 -0700 Subject: [net-dns-users] Parsing MS DNS zone files In-Reply-To: <544E31E6.6000207@yahoo.com> References: <54A46235-2FB4-4AAD-BE47-58365F2402B4@buxtonfamily.us> <544E31E6.6000207@yahoo.com> Message-ID: Thanks for the replies. Normally, I would indeed use zone transfers to pull data in a standard format. However, for my current task, this is not an option. I ended up solving the aging values problem using shell commands to strip this easily-identifiable data from the source files. I then (temporarily) solved the WINS problem by hacking Net::DNS::ZoneFile::_getRR to skip WINS records. $line = $self->_getline if $line =~ /\sWINS\s/; Perhaps in the future I will add a Net::DNS::RR::WINS package to better account for this, but I don't have time for that right at the moment. Thanks, Chris > On Oct 27, 2014, at 4:52 AM, tlhackque wrote: > > On 27-Oct-14 00:02, Chris Buxton wrote: >> Hi, >> >> I'm trying to parse MS DNS zone files using Net::DNS::Zonefile, but it's having issues with two non-standard Microsoft additions to the format: >> >> 1. Age values. For example: >> >> _kerberos._tcp.direktion._sites.dc._msdcs [AGE:3627351] 600 SRV 0 100 88 atzt0009.at.zurich.com . >> >> 2. WINS records. For example: >> >> @ 0 WINS L2 C900 ( >> 192.168.47.221 >> 192.168.47.222 ) >> >> I don't actually need these data points. I just need to have Net::DNS::ZoneFile::read not fail (return null) when encountering them. I have a lot of this data, such that it would be painful to rely on manual remediation. Does anyone have any ideas? >> >> Thanks, >> Chris Buxton > > I'm not an MS DNS admin expert - perhaps there's an 'export a standard zonefile' utility somewhere. A quick search didn't turn one up, but I may have missed it. > > One approach is to use axfr() instead of reading the file. You can tell the MS server not to transfer these records - there's a 'do not repicate this record' checkbox somewhere. See http://technet.microsoft.com/en-us/library/cc784258(v=ws.10).aspx . > > Or you can use Dick's approach and trap the exception - though I'd match for these cases on the error string in case you trip on another error from time to time. > > I'd use axfr() if possible - that's the standard API to DNS. M$ extensions are always a moving target. At least you can beat them up if that's broken. > > If axfr() isn't allowed from the hosting server, or if these files aren't served by one: I might even go as far as running a private M$ server with read-only access to these zone files, on a non-standard port rather than forcibly read the files... > > I really, really don't like chasing M$... > > If at some point you need the WINS/WINS-R records, it wouldn't be hard to write a Net::DNS class for them. You might suggest an API for registering a private class so that you don't have to patch the dispatch hash. Then you could submit it to CPAN - assuming the Net::DNS folks don't take it. > > Hmm, looks like a 5cent response to a 1cent question. Oh, well. > > Good luck. > > -- > This communication may not represent my employer's views, > if any, on the matters discussed. > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users -------------- next part -------------- An HTML attachment was scrubbed... URL: