From willem at nlnetlabs.nl Mon Feb 29 14:25:29 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 29 Feb 2016 15:25:29 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 1.05 Message-ID: <56D454D9.4000701@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear users of Net::DNS, We have a candidate for the upcoming bugfix release 1.05 of Net::DNS. ? TSIG algorithm names will be compared case insensitive again (bug since 1.02). ? Makefile.PL will issue a warning when an earlier version of Net::DNS (before 1.01) was installed on a different (architecture dependent) location. ? The asynchronous support functions (bgsend / bgread) now support transparent retry over TCP with truncated UDP packets. Also support for the SMIMEA resource record was added. For a complete list of changes and bugfixes see the Changes below. Regression testing results for this candidate can be found here: https://www.net-dns.org/regression/ Please review this candidate carefully. If no issues arise, the actual release will follow Monday the 7th of March 2016. link: https://www.net-dns.org/download/Net-DNS-1.04_04.tar.gz sha1: 5ac718d9843f1d7badc4aa2f02d4cf9566d202c4 asc : https://www.net-dns.org/download/Net-DNS-1.04_04.tar.gz.asc Changes ======= Fix rt.cpan.org #111559 1.04: TSIG not working anymore (TSIG.pm) Fix rt.cpan.org #108908 Installing recent version gets shadowed by old version. Warnings added to Makefile.PL and t/00-version.t. Fix rt.cpan.org #66900 Net::DNS::Async unable to retry truncated UDP using TCP because of limitations in Net::DNS. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1FTZAAoJEOX4+CEvd6SYCeUP/RxkJPz2psztj2IE9KumhlGo SL5FB+6/qWIcvMcAX2QTw5wfVqlugiRlFmiSLh4Pn9R9ej70PPO/b2AIsSuZhnzC Hp6Jll9GARq/ozEvuhbeVMeIxUCU2k5OunISnWcNLyoYtJvOYyxhokQfEdCmAiaB UVSyc4Ak+V2p2ewyiFulBE19wXyoUcVY6PhKtj/kLK8HQPcoDb6uSpwzg2i9Oddk wc3KvzUSBD+shQTTE75RxnxIlPvXnHicPv05CX1m3OtWF3qQAuyzdRGFKuD8jT2Z EzELMI+6+UguowyogmM6RrixzSOF92z9acPa3iRIe/zE+ct8HHKn9W+S7XkNoC7n 6/s4az5xODjN7YoExXgeCzZQQR/xBjpxjXMKVHVUUv+4e4lc8Dw09UUfaGTa38Wq 5hPQqGR8EuK1XC80tgJMdvJBdOm5pUin8XCtbmHFSJ6V6EozOCM1mWkRDOJ4Lb2a xCvVyq1bQvaYlbWv3tnhsBIAfAiiPiKJbRSNNefaSDHGQvhibP5N0T+tQJYYR+4c AvemJiKyMDYv3fKxBmHCaFx6W1A6tQ4XFO550RfT/a2PoFW2LxYPD8EFbxXsdp7B 6RvE40T5h+Hmuxhj533XIbJY/Y7zCgL4UxlqBP/93br1mfq2FgXjr0jKyE/ASjnH Td+TEiFozW8LkoZNqsBz =DQyO -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Mon Mar 7 21:20:37 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 7 Mar 2016 22:20:37 +0100 Subject: [net-dns-users] Net::DNS 1.05 released Message-ID: <56DDF0A5.1000206@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear users of Net::DNS, We have a new release, version 1.05 of Net::DNS. This release addresses the following issues: ? TSIG algorithm names will be compared case insensitive again (bug since 1.02). ? Makefile.PL will issue a warning when an earlier version of Net::DNS (before 1.01) was installed on a different (architecture dependent) location. Besides these fixes, the asynchronous support function (bgsend / bgread) have been improved and now support transparent retry over TCP with truncated UDP packets. Also support for the SMIMEA resource record was added. For a complete list of changes and bug fixes see the Changes below. Regression testing for this release can be found here: https://www.net-dns.org/regression/ link: https://www.net-dns.org/download/Net-DNS-1.05.tar.gz sha1: e6425e65b7ec88d0f7f749f40ff5b8f9325c34fb asc : https://www.net-dns.org/download/Net-DNS-1.05.tar.gz.asc Changes ======= Fix rt.cpan.org #111559 1.04: TSIG not working anymore (TSIG.pm) Fix rt.cpan.org #108908 Installing recent version gets shadowed by old version. Warnings added to Makefile.PL and t/00-version.t. Fix rt.cpan.org #66900 Net::DNS::Async unable to retry truncated UDP using TCP because of limitations in Net::DNS. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW3fClAAoJEOX4+CEvd6SYyZ0QAKUCJTwMqdbGZqEvoBli9+64 LC9vbSHVwu6cQxSM5dlvR6pMXbyH3oJ3CPAe2a3dWZxC3stt34DY+4Voa5cAtyap P1Rv15K8SEizUS998YcxmhqyF5NqIhxIKgoe1GzT0x+ZesTtjdLxomYdWf7JkSiK 2rlN5FRBDdbTXCdkLhqokZ5iudJwe2QIeCwx3UlszofOU8aVGo2omSIgzM9HrNsX Pgh4qv3WgbgLBns08XVfHVJ4ypJROrVXdajJ5JPuNVgkfHkD7NcKHFZ9JoOF5WeV RL8bQzwgCf2j+NWn2tbhuLFMx+fitpodvEgHyzLFt7Z0zp7OJZ6NJqdgOqFNeggd lYFjEKuiAo3xwQ5JjD/kPWiuiF4DMzXUdNulCwgjsmOYUmxBDpay3dixHhhhQIwg JrYW1MShK8Y+7wOUUiiXBmwvuAsVUHAuo/5R7VZUTxzapbN2+t3T0bVd39+ZsH+W vrZ8aldkWZOHZTbgneU7sMIrdNQBqwsDBmpbGaxZwJt5Ol5IsKWhYWs9yg568fUM WoZhFyrtXi3nD9sFcHMkYVeZOx4FCBoLb8gINLHx6UbJnwm8Nles3BINzjQ1L2D4 V0iUbHafFPvTr1z371Z5xkWjFfR3wPzK2YuGzF6HHdC437o/ErhhAZy1z6QoCKxK 7CyG90ztjJ5EopFPNs+K =4Oz0 -----END PGP SIGNATURE----- From dougb at dougbarton.us Fri Apr 8 17:09:50 2016 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 08 Apr 2016 17:09:50 +0000 Subject: [net-dns-users] With 1.05 on OS X I'm not seeing errorstring on queries Message-ID: I'm on a Mac with Perl 5.18.2, and Net::DNS 1.05 installed via CPAN and local::lib. I have some scripts that I've been using for over a decade that are suddenly failing because I'm not getting anything from the errorstring method. It's not returning anything at all. With all the same stuff and a similar script that uses axfr I do get the expected response from the errorstring method. I always use send in scripts, but I've tried search and query too, same results. Is this a known issue? I can put together a small test script to demonstrate if necessary, but I wanted to check first if there is something obvious that I'm missing. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Sat Apr 9 00:20:42 2016 From: rwfranks at acm.org (Dick Franks) Date: Sat, 9 Apr 2016 01:20:42 +0100 Subject: [net-dns-users] With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: References: Message-ID: On 8 April 2016 at 18:09, Doug Barton wrote: > I'm on a Mac with Perl 5.18.2, and Net::DNS 1.05 installed via CPAN and > local::lib. I have some scripts that I've been using for over a decade that > are suddenly failing because I'm not getting anything from the errorstring > method. It's not returning anything at all. With all the same stuff and a > similar script that uses axfr I do get the expected response from the > errorstring method. I always use send in scripts, but I've tried search and > query too, same results. > > Is this a known issue? I can put together a small test script to > demonstrate if necessary, but I wanted to check first if there is something > obvious that I'm missing. > hard to tell without a specific example > _______________________________________________ > 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 dougb at dougbarton.us Tue Apr 12 00:32:45 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 12 Apr 2016 00:32:45 +0000 Subject: [net-dns-users] With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: References: Message-ID: April 8 2016 5:21 PM, "Dick Franks" wrote: On 8 April 2016 at 18:09, Doug Barton wrote: I'm on a Mac with Perl 5.18.2, and Net::DNS 1.05 installed via CPAN and local::lib. I have some scripts that I've been using for over a decade that are suddenly failing because I'm not getting anything from the errorstring method. It's not returning anything at all. With all the same stuff and a similar script that uses axfr I do get the expected response from the errorstring method. I always use send in scripts, but I've tried search and query too, same results. Is this a known issue? I can put together a small test script to demonstrate if necessary, but I wanted to check first if there is something obvious that I'm missing. hard to tell without a specific example Fair enough, thanks for the response. :) I have created a demo script that does things the same way I do them in my larger, more complex scripts, and attached the output that I get when I run it. I turned on debug for the queries so that it's easy to see that the query itself actually succeeded, and returns the expected result. Any insight here would be greatly appreciated, as at this point this issue is blocking other work. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: perl-net-dns-errorstring-out.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: send-method-no-errorstring.pl Type: text/perl Size: 1021 bytes Desc: not available URL: From rwfranks at acm.org Tue Apr 12 18:09:54 2016 From: rwfranks at acm.org (Dick Franks) Date: Tue, 12 Apr 2016 19:09:54 +0100 Subject: [net-dns-users] With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: References: Message-ID: Dealing with each case as a separate issue. First, modify your AXFR example so we know for certain that it works: use Net::DNS; print "Perl Version: $^V\n"; print "Net::DNS Version: ", Net::DNS->version, "\n"; print "\nTesting AXFR\n"; my $axfr_res = Net::DNS::Resolver->new or die "Instantiation failed: $!"; $axfr_res->nameservers("192.5.5.241"); my @rr_list = $axfr_res->axfr('.') or die "AXFR failed: $!"; print scalar(@rr_list), " RRs in zone\n"; print "errorstring: ", $axfr_res->errorstring, "\n"; exit; Armed with the result we should be able to answer three questions: Perl Version: v5.22.1 Net::DNS Version: 1.05 Testing AXFR 17636 RRs in zone errorstring: RCODE from server: NOERROR 1) Was there an error? Clearly not. 2) Is $res->errorstring defined? Yes 3) Did it ever contain just "NOERROR"? To answer that we need to look back into history. Perl Version: v5.22.1 Net::DNS Version: 0.25 (Aug 2002) Testing AXFR 17636 RRs in zone errorstring: no zone transfer in progress Perl Version: v5.22.1 Net::DNS Version: 0.43 (Dec 2003) Testing AXFR 17636 RRs in zone errorstring: unknown error or no error Perl Version: v5.22.1 Net::DNS Version: 1.03 (Nov 2015) Testing AXFR 17636 RRs in zone errorstring: unknown error or no error The default text indicates that no attempt was made to put anything in errorstring before version 1.04. The answer seems to be "No" As there was no error, I may consider reversing my decision at 1.04 and to leave errorstring empty. Dick Franks ________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Tue Apr 12 21:13:43 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 12 Apr 2016 21:13:43 +0000 Subject: [net-dns-users] Fwd: Re: With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: References: Message-ID: The AXFR code works, it always has. I copied it directly from a working script. I added the code you suggested to my demo script and it gave the expected result. You are correct that in the past the string that the errorstring method returned for a successful AXFR result contained "no error," not the actual RCODE. I was able to change my script to deal with either string. But that's not the thing I'm actually asking about. :) Prior to the current version (I haven't been keeping track, but from what you've written it seems like maybe the change was made in 1.04) the errorstring method always contained something when used for queries. If I run my demo script on my Ubuntu system I get the following results: Perl Version: v5.20.2 Net::DNS Version: 0.81 Testing AXFR 17636 RRs in zone Query status for AXFR (Should be NOERROR): unknown error or no errorThen for the queries I get this for all 3 methods: Query status for method search: (Should be NXDOMAIN): NXDOMAIN In my previously working script I also have tests such as: if ($res->errorstring eq 'query timed out') { } elsif ($res->errorstring eq 'connection failed') { } elsif ($res->errorstring =~ /NXDOMAIN/i) { } elsif (not $res->errorstring eq 'NOERROR') {(and please keep in mind that I've been using this script, largely unchanged, for over a decade). So I see two problems here. The first, less serious problem, is that you've changed the semantic for how errorstring is constructed for AXFRs. I can chalk that up to having to keep things up to date as libraries change over time. That doesn't mean I like it, or that I think it's Ok, but it's something I can live with. The far more serious problem is that the errorstring method has been gutted altogether for queries. For my purpose I need to know what happened to my query, not just the results. Of course I can use Net::DNS::Header for this, and I'll re-write my code accordingly. But should I have to? Dramatically changing the way that this method works with no notice to the community is not good software engineering. (It's probably worth mentioning that there is another problem, namely that the changes to the errorstring method were not listed in the CHANGES file.) If you're wondering why platforms like Debian are staying with such old versions of Net::DNS, this kind of thing is why. My proposal is to simply restore the previous semantics that the errorstring method was using. I don't see any good reason to change them, but I'm willing to listen to an argument in that regard. That said, I think you're on the right track with the change that was made to the errorstring for the axfr method. Rather than such a verbose message however I'd suggest that instead you just append "RCODE: " to whatever the errorstring method was previously returning. For the example in my demo script you'd get "RCODE: NOERROR." That way if a user needs the RCODE value it's available, even if they use the search or query methods (since you can't get the header without using send). For cases where previously the errorstring was returning just the RCODE (such as the search/query/send methods in the case of NXDOMAIN) it should continue to return just that of course. That is, I'd like to maintain consistency with whatever it was returning previously, and only append the RCODE string as above when the previous errorstring did not contain it. Doug -------- Forwarded message ------- From: "Dick Franks" To: net-dns-users at nlnetlabs.nl (mailto:net-dns-users at nlnetlabs.nl) Sent: April 12 2016 11:10 AM Subject: Re: [net-dns-users] With 1.05 on OS X I'm not seeing errorstring on queries Dealing with each case as a separate issue. First, modify your AXFR example so we know for certain that it works: use Net::DNS; print "Perl Version: $^Vn"; print "Net::DNS Version: ", Net::DNS->version, "n"; print "nTesting AXFRn"; my $axfr_res = Net::DNS::Resolver->new or die "Instantiation failed: $!"; $axfr_res->nameservers("192.5.5.241"); my @rr_list = $axfr_res->axfr('.') or die "AXFR failed: $!"; print scalar(@rr_list), " RRs in zonen"; print "errorstring: ", $axfr_res->errorstring, "n"; exit; Armed with the result we should be able to answer three questions: Perl Version: v5.22.1 Net::DNS Version: 1.05 Testing AXFR 17636 RRs in zone errorstring: RCODE from server: NOERROR 1) Was there an error? Clearly not. 2) Is $res->errorstring defined? Yes 3) Did it ever contain just "NOERROR"? To answer that we need to look back into history. Perl Version: v5.22.1 Net::DNS Version: 0.25 (Aug 2002) Testing AXFR 17636 RRs in zone errorstring: no zone transfer in progress Perl Version: v5.22.1 Net::DNS Version: 0.43 (Dec 2003) Testing AXFR 17636 RRs in zone errorstring: unknown error or no error Perl Version: v5.22.1 Net::DNS Version: 1.03 (Nov 2015) Testing AXFR 17636 RRs in zone errorstring: unknown error or no error The default text indicates that no attempt was made to put anything in errorstring before version 1.04. The answer seems to be "No" As there was no error, I may consider reversing my decision at 1.04 and to leave errorstring empty. Dick Franks ________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Wed Apr 13 00:32:22 2016 From: rwfranks at acm.org (Dick Franks) Date: Wed, 13 Apr 2016 01:32:22 +0100 Subject: [net-dns-users] Fwd: Re: With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: References: Message-ID: axfr() Since 0.43 there has been no attempt to provide anything in errorstring. The motivation for doing something different now was to provide some means of finding out what went wrong with TSIG verifications which is not easy to uncover without it. I see no justification for filling errorstring when there is no useful information to impart. Adding RCODE: NOERROR provides no useful information because the transfer gets aborted if anything else shows up in a packet header (per RFC1035, 6.3). send() The proper place to test the outcome of the transaction is using $result->header->rcode() which is a recognised feature of DNS protocol. I note that errorstring has always been set (redundantly) the same as rcode. Perhaps we need to accept that as one of Net::DNS's historical quirks, which probably arose from design indecision in its very early history. It is certainly present in 0.12, where hardly anything else works exactly as it does now. As with axfr(), TSIG errors get funnelled into errorstring, so there is no longer any guarantee that it will be one of the usual RCODE mnemonics. Other than that, I am minded to restore the old behaviour. Dick Franks ________________________ On 12 April 2016 at 22:13, Doug Barton wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Sun Apr 17 21:11:00 2016 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 17 Apr 2016 14:11:00 -0700 Subject: [net-dns-users] Fwd: Re: With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: References: Message-ID: <5713FBE4.8080400@dougbarton.us> On 04/12/2016 05:32 PM, Dick Franks wrote: > axfr() > > Since 0.43 there has been no attempt to provide anything in errorstring. My experience (which goes back well over a decade) is at odds with your assertion. For successful AXFRs it's filled with "unknown error or no error" and as far as I can tell by going back in RCS to at least 2004, it always has been. > The motivation for doing something different now was to provide some > means of finding out what went wrong with TSIG verifications which is > not easy to uncover without it. That seems reasonable. > I see no justification for filling > errorstring when there is no useful information to impart. Consistency with previous versions of the module is all the justification you need. > Adding > RCODE: NOERROR provides no useful information because the transfer gets > aborted if anything else shows up in a packet header (per RFC1035, 6.3). First, I'm not sure that's always been true, which is why I added the test I have for AXFR in the first place. Second, while it may be true that the transfer aborts in those circumstances now, using the RCODE to indicate that it was successful (as has already been done essentially since day 1) is good future-proofing. > send() > > The proper place to test the outcome of the transaction is using > $result->header->rcode() which is a recognised feature of DNS protocol. As I mentioned previously, that only works for the send method. It does not work for search or query. > I note that errorstring has always been set (redundantly) the same as > rcode. Perhaps we need to accept that as one of Net::DNS's historical > quirks, which probably arose from design indecision in its very early > history. It is certainly present in 0.12, where hardly anything else > works exactly as it does now. Maintaining consistency with previous code is its own value, and an incredibly important one. Making sure that RCODE remains available to the search and query methods is valuable as well. > As with axfr(), TSIG errors get funnelled into errorstring, so there is > no longer any guarantee that it will be one of the usual RCODE > mnemonics. Other than that, I am minded to restore the old behaviour. Yay! That's a good start. :) Doug From rwfranks at acm.org Sun Apr 17 23:30:32 2016 From: rwfranks at acm.org (Dick Franks) Date: Mon, 18 Apr 2016 00:30:32 +0100 Subject: [net-dns-users] Fwd: Re: With 1.05 on OS X I'm not seeing errorstring on queries In-Reply-To: <5713FBE4.8080400@dougbarton.us> References: <5713FBE4.8080400@dougbarton.us> Message-ID: On 17 April 2016 at 22:11, Doug Barton wrote: > On 04/12/2016 05:32 PM, Dick Franks wrote: > >> axfr() >> >> Since 0.43 there has been no attempt to provide anything in errorstring. >> > > My experience (which goes back well over a decade) is at odds with your > assertion. For successful AXFRs it's filled with "unknown error or no > error" and as far as I can tell by going back in RCS to at least 2004, it > always has been. > Your experience is no match for my perl script which repeats a test using every version from 0.12 to 1.05. So I make my assertions without the slightest risk of contradiction. [snip] > Adding > >> RCODE: NOERROR provides no useful information because the transfer gets >> aborted if anything else shows up in a packet header (per RFC1035, 6.3). >> > > First, I'm not sure that's always been true, which is why I added the test > I have for AXFR in the first place. Second, while it may be true that the > transfer aborts in those circumstances now, using the RCODE to indicate > that it was successful (as has already been done essentially since day 1) > is good future-proofing. > Unconvinced. If there is no error, there is no point in providing errorstring to explain that there wasn't one. > > send() >> >> The proper place to test the outcome of the transaction is using >> $result->header->rcode() which is a recognised feature of DNS protocol. >> > > As I mentioned previously, that only works for the send method. It does > not work for search or query. Good point > I note that errorstring has always been set (redundantly) the same as >> rcode. Perhaps we need to accept that as one of Net::DNS's historical >> quirks, which probably arose from design indecision in its very early >> history. It is certainly present in 0.12, where hardly anything else >> works exactly as it does now. >> > > Maintaining consistency with previous code is its own value, and an > incredibly important one. Making sure that RCODE remains available to the > search and query methods is valuable as well. Same point > As with axfr(), TSIG errors get funnelled into errorstring, so there is >> no longer any guarantee that it will be one of the usual RCODE >> mnemonics. Other than that, I am minded to restore the old behaviour. >> > > Yay! That's a good start. :) > > Follows from your observation about search and query -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Mon Apr 18 09:45:14 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 18 Apr 2016 11:45:14 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 Message-ID: <5714ACAA.5060804@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear All, We have a candidate for the upcoming 1.06 bug fix release of Net::DNS. ? Parsing of scoped IPv6 has been fixed when IO::Socket::IP is used (regression since 1.05). ? Interfering middle boxes will no longer be able to hang recursive lookups and interfere with unit tests. ? errorstring() results for non-errors has been restored ("regression" since 1.05) Besides these bug fixes, this release ? has better TSIG error reporting ? will be able to do asynchronous TCP fall backs, even using bare sockets (which is discouraged usage, but occurs in the wild). ? has better Resolver.pm documentation ? and has great coverage results! Regression testing results for this candidate can be found here: https://www.net-dns.org/regression/ Please review this candidate carefully. If no issues arise, the actual release will follow Monday the 25th of April 2016. link https://www.net-dns.org/download/Net-DNS-1.05_05.tar.gz sha1 404208b92ce318c5cb5682a232e1f2db8e34a62b asc https://www.net-dns.org/download/Net-DNS-1.05_05.tar.gz.asc Changes ======= Fix rt.cpan.org #113579 Net::DNS::Resolver dies on scoped IPv6 nameserver address Fix rt.cpan.org #113020 Resolve::Recurse Hangs Fix rt.cpan.org #112860 improperly terminated AXFR at t/08-IPv4.t line 446. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFKypAAoJEOX4+CEvd6SYrYQP/R2EUxmskTv+4ZCbB0BGlRI/ Kwsae5K7TDUSVq7yEw+/XroZfSMImTLt3eL6Zvo1RGBCANpO11fogxkhJo1KvyQF FFsVkyqp4Vsbvz+08MACAYAPGs4LtgTJAoNkKyBCt6Ix9ktyOMaBBbEC+liVnGzc Rqz4DbScCJp2AwEKyfiRSc9vWELpphgYg2yonybVQ8ocHCtCmh8EG5rUDS2y43QO qz2PQ1wr1eDDV3dIJoVTbxx4CpZqZ+wZSqsKbswOTTj4RWdltwwO0uzDkeRzkRbZ KahjIFXmLZI3SmKXVknK3e6UMzQLNrV/nIs9tN620jWMKI+/EOuFqrAVmQHpft0L k0v0VcGIAEh6M1R9aD7DQGFmK0zoTkTOdGcVkKuPCoGpbrn3B0kFgZ/KJvU/FPMS 0mE5MTCZ2yp5SY8AApzezK1QXVkcZjDvGsz3/uE4F+8Y89xlYK0iKea2q+U+tXEI +LuaL4OxqPYMJRig8L3ItmAsrzGyvA5CIbGKRZM0aQRZclyBeCswVbP4gGlE9Jy9 tKPB1lsJ7OYnO2R4vtPMKQzHBlK4UDvvotT2ZvSK6F6Whv7a4dMPMHzta5q8XLt6 6R5VL/bRLOJ7xApVMpEkISqhDazSL59jYx879SnlqGbIhmbYFbLFqEc/K1Uza2PW vf0TLQHw/iaasECklVNg =5WwU -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Mon Apr 18 10:05:30 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Mon, 18 Apr 2016 12:05:30 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <5714ACAA.5060804@nlnetlabs.nl> References: <5714ACAA.5060804@nlnetlabs.nl> Message-ID: <5714B16A.8040007@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Correction. This candidate does *not* have asynchronous TCP fall back when using bare sockets. This feature perished during regression testing. Sorry, - -- Willem Op 18-04-16 om 11:45 schreef Willem Toorop: > Dear All, > > We have a candidate for the upcoming 1.06 bug fix release of Net::DNS. > > ? Parsing of scoped IPv6 has been fixed when IO::Socket::IP is used > (regression since 1.05). > ? Interfering middle boxes will no longer be able to hang recursive > lookups and interfere with unit tests. > ? errorstring() results for non-errors has been restored > ("regression" since 1.05) > > Besides these bug fixes, this release > ? has better TSIG error reporting > ? will be able to do asynchronous TCP fall backs, even using bare > sockets (which is discouraged usage, but occurs in the wild). > ? has better Resolver.pm documentation > ? and has great coverage results! > > Regression testing results for this candidate can be found here: > https://www.net-dns.org/regression/ > > Please review this candidate carefully. If no issues arise, the > actual release will follow Monday the 25th of April 2016. > > > link https://www.net-dns.org/download/Net-DNS-1.05_05.tar.gz > sha1 404208b92ce318c5cb5682a232e1f2db8e34a62b > asc https://www.net-dns.org/download/Net-DNS-1.05_05.tar.gz.asc > > > Changes > ======= > Fix rt.cpan.org #113579 > > Net::DNS::Resolver dies on scoped IPv6 nameserver address > > Fix rt.cpan.org #113020 > > Resolve::Recurse Hangs > > Fix rt.cpan.org #112860 > > improperly terminated AXFR at t/08-IPv4.t line 446. > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFLFqAAoJEOX4+CEvd6SYG6oP/AvWTQN51bx2aNBblvW7yq1C hTlWEidFnj/DhS3yw23Ex+W7J0/VuKzzrsr6KqicLKXkczzNTmrAIH1QxnmIEyb2 YjanhiVOXrbnUM64lpkGks02DU4BlNyDwoA4uxG3yNKrNzOzIMm1nNMUxg42HV6i k6Xd1feLU+04dznxKD41GwvYt7puWpFAEhE3qiPejwiCvSVOf9dC0YYy4jGnTTPr onaLgZbVRmVrVCsiW8cnOsYJ97SzPDht883J6+b2PktItv6NW5nJq1NOll6GyCcL NmR6EII7++Ju0h4hk03zSgeLGB9Ey70n04uiauM2O1MY/AeiL/+kAiAGTLOkHUWd +GQCS/uQttDj9SGvdGrgtIXQjmlS5+2xpRGwAxPsv6QFGBfAmwulXv4V2UvhdnY3 EjI7NHtvn5Ahapo17Gvpp7ewBXuzLnkDxXKOF5jMFpZkCed7hnPoFvBC1QJ+b5xW oaQ/qf5ALq4frVoH5N7tBOUyvZs/7iiE5WL4UbJuHGAp9QwDfjLcr3KjnnyFG48E Na7O2RXPtu/fdc9QEC9fRwfzvM4R/TOMGMgy5UAOjJ8sXBwGQ2tuu2dEu12fEYN7 VBPET/e4iDNEh+ABlmkKtcpwuFDD61BkABTkjrmZ8+CIe1fTijwetriAM8aANpeG RuNUQ7Xv6sanBudKtPMY =oWTa -----END PGP SIGNATURE----- From dougb at dougbarton.us Tue Apr 19 05:38:48 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Apr 2016 05:38:48 +0000 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <5714ACAA.5060804@nlnetlabs.nl> References: <5714ACAA.5060804@nlnetlabs.nl> Message-ID: <699a16f6df76b838f9254022b029e542@dougbarton.us> This is better in some ways, and worse in others. :) The errorstring is being filled again for search/query/send, which is great. :) However the errorstring for AXFR is now empty (not undefined, there is actually a string there, but it seems to be one, or maybe two spaces. This is a regression against both 1.05 and versions previous to the errorstring nuking (1.04?). The demo script I sent to the list previously can demonstrate the problem. Also the output from that script that I sent along with it shows the previous output for errorstring after AXFR for both 1.05 and 0.81. Today I also identified another problem with the way that DS records are printed that was also present in 1.05 release. In previous versions (for example 0.81 that I'm using on Ubuntu) The DS records were formatted like this when they were printed out using $rr->string: aaa. 86400 in ds \# 24 54cb08016d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2X I can certainly see how this is suboptimal, and the new format is better, but the problem is that it has a newline embedded: aaa. 86400 in ds ( 21707 8 1 6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 ) Can we get this in one line? It makes it a whole lot easier to process. (FWIW, the print method has the same issue) And in the future can we avoid newlines in the data? Doug April 18 2016 2:45 AM, "Willem Toorop" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear All, > > We have a candidate for the upcoming 1.06 bug fix release of Net::DNS. > > ? Parsing of scoped IPv6 has been fixed when IO::Socket::IP is used > (regression since 1.05). > ? Interfering middle boxes will no longer be able to hang recursive > lookups and interfere with unit tests. > ? errorstring() results for non-errors has been restored > ("regression" since 1.05) > > Besides these bug fixes, this release > ? has better TSIG error reporting > ? will be able to do asynchronous TCP fall backs, even using bare > sockets (which is discouraged usage, but occurs in the wild). > ? has better Resolver.pm documentation > ? and has great coverage results! > > Regression testing results for this candidate can be found here: > https://www.net-dns.org/regression > > Please review this candidate carefully. If no issues arise, the > actual release will follow Monday the 25th of April 2016. > > link https://www.net-dns.org/download/Net-DNS-1.05_05.tar.gz > sha1 404208b92ce318c5cb5682a232e1f2db8e34a62b > asc https://www.net-dns.org/download/Net-DNS-1.05_05.tar.gz.asc > > Changes > ======= > Fix rt.cpan.org #113579 > > Net::DNS::Resolver dies on scoped IPv6 nameserver address > > Fix rt.cpan.org #113020 > > Resolve::Recurse Hangs > > Fix rt.cpan.org #112860 > > improperly terminated AXFR at t/08-IPv4.t line 446. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXFKypAAoJEOX4+CEvd6SYrYQP/R2EUxmskTv+4ZCbB0BGlRI/ > Kwsae5K7TDUSVq7yEw+/XroZfSMImTLt3eL6Zvo1RGBCANpO11fogxkhJo1KvyQF > FFsVkyqp4Vsbvz+08MACAYAPGs4LtgTJAoNkKyBCt6Ix9ktyOMaBBbEC+liVnGzc > Rqz4DbScCJp2AwEKyfiRSc9vWELpphgYg2yonybVQ8ocHCtCmh8EG5rUDS2y43QO > qz2PQ1wr1eDDV3dIJoVTbxx4CpZqZ+wZSqsKbswOTTj4RWdltwwO0uzDkeRzkRbZ > KahjIFXmLZI3SmKXVknK3e6UMzQLNrV/nIs9tN620jWMKI+/EOuFqrAVmQHpft0L > k0v0VcGIAEh6M1R9aD7DQGFmK0zoTkTOdGcVkKuPCoGpbrn3B0kFgZ/KJvU/FPMS > 0mE5MTCZ2yp5SY8AApzezK1QXVkcZjDvGsz3/uE4F+8Y89xlYK0iKea2q+U+tXEI > +LuaL4OxqPYMJRig8L3ItmAsrzGyvA5CIbGKRZM0aQRZclyBeCswVbP4gGlE9Jy9 > tKPB1lsJ7OYnO2R4vtPMKQzHBlK4UDvvotT2ZvSK6F6Whv7a4dMPMHzta5q8XLt6 > 6R5VL/bRLOJ7xApVMpEkISqhDazSL59jYx879SnlqGbIhmbYFbLFqEc/K1Uza2PW > vf0TLQHw/iaasECklVNg > =5WwU > -----END PGP SIGNATURE----- > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users From dougb at dougbarton.us Tue Apr 19 06:42:42 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Apr 2016 06:42:42 +0000 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <699a16f6df76b838f9254022b029e542@dougbarton.us> References: <699a16f6df76b838f9254022b029e542@dougbarton.us> <5714ACAA.5060804@nlnetlabs.nl> Message-ID: April 18 2016 10:39 PM, "Doug Barton" wrote: > I can certainly see how this is suboptimal, and the new format is better, but the problem is that > it has a newline embedded: > > aaa. 86400 in ds ( 21707 8 1 > 6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 ) > > Can we get this in one line? It makes it a whole lot easier to process. (FWIW, the print method has > the same issue) > > And in the future can we avoid newlines in the data? So it's actually worse than I thought. :( The wrapping and adding of parens seems to be a function of line length, not record type. There are DS records in the root zone that don't trigger the wrapping, and there are AAAA records in the root zone that do: d.xn--node.globalanycastcloud.freenom.net. 172800 IN AAAA ( 2a04:1b00:b::4 ) dns1.u-registry.com. 172800 IN AAAA ( 2604:4300:a:8c:5054:ff:fe47:8582 ) Can we please remove this ill-advised change altogether? When processing these records it magnifies my code complexity significantly if I have to test every record for the presence of newlines, join them if they are present, extract patterns with and without parens, etc. I can absorb the development cost of testing for two different DS record formats because the new format is a legitimate improvement. But having to deal with the multiline/paren issue appearing at random for certain (all?) record types is not Ok. Doug From willem at nlnetlabs.nl Tue Apr 19 07:15:35 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 19 Apr 2016 09:15:35 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: References: <699a16f6df76b838f9254022b029e542@dougbarton.us> <5714ACAA.5060804@nlnetlabs.nl> Message-ID: <5715DB17.8000901@nlnetlabs.nl> Hi Doug, The output format is simply DNS presentation format. It is a well known and reasonably well defined format (already described in RFC1035 as "Master file" format). It is not something which is specific for Net::DNS. You can use the zone parsing functions of Net::DNS to read this output, or the output from any other software that writes DNS presentation format for that matter. Have a look at the documentation of Net::DNS::ZoneFile. Kind regards, -- Willem Toorop Op 19-04-16 om 08:42 schreef Doug Barton: > April 18 2016 10:39 PM, "Doug Barton" wrote: > >> I can certainly see how this is suboptimal, and the new format is better, but the problem is that >> it has a newline embedded: >> >> aaa. 86400 in ds ( 21707 8 1 >> 6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 ) >> >> Can we get this in one line? It makes it a whole lot easier to process. (FWIW, the print method has >> the same issue) >> >> And in the future can we avoid newlines in the data? > > So it's actually worse than I thought. :( The wrapping and adding of parens seems to be a function of line length, not record type. There are DS records in the root zone that don't trigger the wrapping, and there are AAAA records in the root zone that do: > > d.xn--node.globalanycastcloud.freenom.net. 172800 IN AAAA ( > 2a04:1b00:b::4 ) > > dns1.u-registry.com. 172800 IN AAAA ( > 2604:4300:a:8c:5054:ff:fe47:8582 ) > > Can we please remove this ill-advised change altogether? When processing these records it magnifies my code complexity significantly if I have to test every record for the presence of newlines, join them if they are present, extract patterns with and without parens, etc. I can absorb the development cost of testing for two different DS record formats because the new format is a legitimate improvement. But having to deal with the multiline/paren issue appearing at random for certain (all?) record types is not Ok. > > Doug > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > From willem at nlnetlabs.nl Tue Apr 19 07:51:38 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 19 Apr 2016 09:51:38 +0200 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <5715DB17.8000901@nlnetlabs.nl> References: <699a16f6df76b838f9254022b029e542@dougbarton.us> <5714ACAA.5060804@nlnetlabs.nl> <5715DB17.8000901@nlnetlabs.nl> Message-ID: <5715E38A.6020709@nlnetlabs.nl> Hi Doug, I just want to add that I'm sorry to hear upgraded Net::DNS is causing you trouble. However, it would be wise to process zone files with Net::DNS::ZoneFile even if all resource records would have been on a single line, because it also anticipates comments and $INCLUDE, $ORIGIN, $TTL and even the non-standard $GENERATE directive. Parsing zone files with Net::DNS::ZoneFile will make your scripts more generic (as it can read presentation format from other software as well). Having that said, we could consider influencing the parameters for presentation format (like for # columns) as a feature request. It requires thinking about how to do this best architecturally though, and will not make the 1.06 release. Kind regards, -- Willem Toorop Op 19-04-16 om 09:15 schreef Willem Toorop: > Hi Doug, > > The output format is simply DNS presentation format. It is a well known > and reasonably well defined format (already described in RFC1035 as > "Master file" format). It is not something which is specific for Net::DNS. > > You can use the zone parsing functions of Net::DNS to read this output, > or the output from any other software that writes DNS presentation > format for that matter. Have a look at the documentation of > Net::DNS::ZoneFile. > > Kind regards, > > -- Willem Toorop > > > > Op 19-04-16 om 08:42 schreef Doug Barton: >> April 18 2016 10:39 PM, "Doug Barton" wrote: >> >>> I can certainly see how this is suboptimal, and the new format is better, but the problem is that >>> it has a newline embedded: >>> >>> aaa. 86400 in ds ( 21707 8 1 >>> 6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 ) >>> >>> Can we get this in one line? It makes it a whole lot easier to process. (FWIW, the print method has >>> the same issue) >>> >>> And in the future can we avoid newlines in the data? >> >> So it's actually worse than I thought. :( The wrapping and adding of parens seems to be a function of line length, not record type. There are DS records in the root zone that don't trigger the wrapping, and there are AAAA records in the root zone that do: >> >> d.xn--node.globalanycastcloud.freenom.net. 172800 IN AAAA ( >> 2a04:1b00:b::4 ) >> >> dns1.u-registry.com. 172800 IN AAAA ( >> 2604:4300:a:8c:5054:ff:fe47:8582 ) >> >> Can we please remove this ill-advised change altogether? When processing these records it magnifies my code complexity significantly if I have to test every record for the presence of newlines, join them if they are present, extract patterns with and without parens, etc. I can absorb the development cost of testing for two different DS record formats because the new format is a legitimate improvement. But having to deal with the multiline/paren issue appearing at random for certain (all?) record types is not Ok. >> >> Doug >> _______________________________________________ >> 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 > From rwfranks at acm.org Tue Apr 19 15:39:06 2016 From: rwfranks at acm.org (Dick Franks) Date: Tue, 19 Apr 2016 16:39:06 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <699a16f6df76b838f9254022b029e542@dougbarton.us> References: <5714ACAA.5060804@nlnetlabs.nl> <699a16f6df76b838f9254022b029e542@dougbarton.us> Message-ID: On 19 April 2016 at 06:38, Doug Barton wrote: > This is better in some ways, and worse in others. :) > > The errorstring is being filled again for search/query/send, which is > great. :) However the errorstring for AXFR is now empty (not undefined, there is > actually a string there, but it seems to be one, or maybe two spaces. If you are going to persist with this argument, at least do us the courtesy of citing verifiable facts. my $resolver = Net::DNS::Resolver->new(); $resolver->nameserver('185.49.140.63');` $resolver->domain('net-dns.org'); my @zone = eval { $resolver->axfr() }; print scalar(@zone), "\n"; my $errorstring = $resolver->errorstring; print length($errorstring), "\t$errorstring\n"; produces 2648 0 > This is a regression against both 1.05 and versions previous to the > errorstring nuking (1.04?). The demo script I sent to the list previously > can demonstrate the problem. Also the output from that script that I sent > along with it shows the previous output for errorstring after AXFR for both > 1.05 and 0.81. > 0.81 2648 25 unknown error or no error axfr() did not modify errorstring in any way at all. It is easy to demonstrate that if other values occur in errorstring they were left over from a previous query, which is downright unhelpful. Worse, the documentation implied that errorstring() relates to axfr(), which it clearly does not, and never did. Today I also identified another problem with the way that DS records are > printed that was also present in 1.05 release. In previous versions (for > example 0.81 that I'm using on Ubuntu) The DS records were formatted like > this when they were printed out using $rr->string: > > aaa. 86400 in ds \# 24 > 54cb08016d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2X > Because Net::DNS::SEC was not installed. The DNSSEC RRs were moved into Net::DNS to allow users to see intelligible data, even if they have no intention of doing signing or validation. I can certainly see how this is suboptimal, and the new format is better, > but the problem is that it has a newline embedded: > > aaa. 86400 in ds ( 21707 8 1 > 6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 ) > > Can we get this in one line? It makes it a whole lot easier to process. > (FWIW, the print method has the same issue) > And in the future can we avoid newlines in the data? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfranks at acm.org Tue Apr 19 15:44:12 2016 From: rwfranks at acm.org (Dick Franks) Date: Tue, 19 Apr 2016 16:44:12 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <5715E38A.6020709@nlnetlabs.nl> References: <699a16f6df76b838f9254022b029e542@dougbarton.us> <5714ACAA.5060804@nlnetlabs.nl> <5715DB17.8000901@nlnetlabs.nl> <5715E38A.6020709@nlnetlabs.nl> Message-ID: On 19 April 2016 at 08:51, Willem Toorop wrote: > Hi Doug, > > I just want to add that I'm sorry to hear upgraded Net::DNS is causing > you trouble. However, it would be wise to process zone files with > Net::DNS::ZoneFile even if all resource records would have been on a > single line, because it also anticipates comments and $INCLUDE, $ORIGIN, > $TTL and even the non-standard $GENERATE directive. Parsing zone files > with Net::DNS::ZoneFile will make your scripts more generic (as it can > read presentation format from other software as well). > > Having that said, we could consider influencing the parameters for > presentation format (like for # columns) as a feature request. It > requires thinking about how to do this best architecturally though, and > will not make the 1.06 release. > I will be happy to fix contraventions of RFC1035, if there are any. There is no architectural issue with increasing the line length parameter, but line folding is still going to happen with long RRs. Folds only occur between RDATA elements, which in practical terms means that short elements are grouped on a line and long elements occupy a whole line. The end result is remarkably insensitive to the line length parameter except in those rare cases where there is a long sequence of short elements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Tue Apr 19 18:58:11 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Apr 2016 11:58:11 -0700 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: References: <5714ACAA.5060804@nlnetlabs.nl> <699a16f6df76b838f9254022b029e542@dougbarton.us> Message-ID: <57167FC3.7040900@dougbarton.us> On 04/19/2016 08:39 AM, Dick Franks wrote: > > On 19 April 2016 at 06:38, Doug Barton > wrote: > However the errorstring for AXFR is now empty (not undefined, > there is actually a string there, but it seems to be one, or maybe > two spaces. > > > If you are going to persist with this argument, at least do us the > courtesy of citing verifiable facts. > > my $resolver = Net::DNS::Resolver->new(); > $resolver->nameserver('185.49.140.63');` > $resolver->domain('net-dns.org '); > > my @zone = eval { $resolver->axfr() }; > print scalar(@zone), "\n"; > my $errorstring = $resolver->errorstring; > print length($errorstring), "\t$errorstring\n"; > > produces > > 2648 > 0 You focused on the wrong part of what I said. Previous to this RC errorstring was undefined, which allowed me to wrap my previous code in an 'if (defined ...' block. Now it's defined, but empty (or has spaces, or doesn't, whatever). That's much worse, as now I have to do a string compare. > This is a regression against both 1.05 and versions previous to the > errorstring nuking (1.04?). The demo script I sent to the list > previously can demonstrate the problem. Also the output from that > script that I sent along with it shows the previous output for > errorstring after AXFR for both 1.05 and 0.81. > > > 0.81 > > 2648 > 25 unknown error or no error > > axfr() did not modify errorstring in any way at all. I'm not sure how you're using the word "modify" in that sentence. In any case, what you printed out above shows what I've been saying all along. In previous versions errorstring was populated after a successful AXFR. In my opinion that state of affairs should be maintained. However we have gone from: prior to 1.05 (or is it 1.04?) defined and populated 1.05 undefined 1.06-RC1 defined, but not populated So we're getting worse instead of better. > It is easy to demonstrate that if other values occur in errorstring they > were left over from a previous query, which is downright unhelpful. I agree that errorstring should be cleared before each new call to the resolver object. In fact I would be surprised if it wasn't. However in both your demo above, and in my functional script, the ONLY use of the resolver object is the AXFR. So I'm hard pressed to see how this comment relates. > Worse, the documentation implied that errorstring() relates to axfr(), > which it clearly does not, and never did. So how is it getting filled in previous versions? Doug From dougb at dougbarton.us Tue Apr 19 19:14:04 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Apr 2016 12:14:04 -0700 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <5715E38A.6020709@nlnetlabs.nl> References: <699a16f6df76b838f9254022b029e542@dougbarton.us> <5714ACAA.5060804@nlnetlabs.nl> <5715DB17.8000901@nlnetlabs.nl> <5715E38A.6020709@nlnetlabs.nl> Message-ID: <5716837C.4070900@dougbarton.us> On 04/19/2016 12:51 AM, Willem Toorop wrote: > Hi Doug, > > I just want to add that I'm sorry to hear upgraded Net::DNS is causing > you trouble. Let's be clear. "Upgraded Net::DNS" didn't just happen, the lack of backwards compatibility is a direct result of decisions which you(pl) have made in regards to changing the format of the data as it's output to the caller. That's not Ok. I cannot emphasize this point strongly enough. Net::DNS is very old code. It has a huge installed base, with millions of scripts written against it. The very concept of changing the data presentation format of data based on parameters not under the control of the caller (in this case line length) is horrifically bad design to start with. But even assuming that a rational argument could be made for doing that in new code, there are no circumstances where a change of this nature is Ok in a well established library. I don't care what your justification is, I don't care how well established the new format is, I don't care. This isn't something that you do, ever. Now if you think your new presentation format is awesome, or valuable, or whatever, that's fine .... create a NEW method for the NEW format, and let people vote with their feet. I'm all for innovation, and if you did that my only feedback would be that in over 20 years as a DNS admin and many tens of thousands of zones files reviewed I've never seen someone line wrap an A or AAAA record. But I don't care, because I'm not going to use that new method. The string method however needs to be left alone ... it should return its data on one line, with no parens, just like it always has. > However, it would be wise to process zone files with > Net::DNS::ZoneFile That's great advice, except that I'm not processing zone files. > Having that said, we could consider influencing the parameters for > presentation format (like for # columns) as a feature request. It > requires thinking about how to do this best architecturally though, and > will not make the 1.06 release. I am not asking for a new feature. I'm asking you to remove (or relocate) the incredibly wrong-headed new feature that you already added due to it causing significant regression in the established code base (and being a painfully bad idea in the first place). Doug > Op 19-04-16 om 09:15 schreef Willem Toorop: >> Hi Doug, >> >> The output format is simply DNS presentation format. It is a well known >> and reasonably well defined format (already described in RFC1035 as >> "Master file" format). It is not something which is specific for Net::DNS. >> >> You can use the zone parsing functions of Net::DNS to read this output, >> or the output from any other software that writes DNS presentation >> format for that matter. Have a look at the documentation of >> Net::DNS::ZoneFile. >> >> Kind regards, >> >> -- Willem Toorop >> >> >> >> Op 19-04-16 om 08:42 schreef Doug Barton: >>> April 18 2016 10:39 PM, "Doug Barton" wrote: >>> >>>> I can certainly see how this is suboptimal, and the new format is better, but the problem is that >>>> it has a newline embedded: >>>> >>>> aaa. 86400 in ds ( 21707 8 1 >>>> 6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 ) >>>> >>>> Can we get this in one line? It makes it a whole lot easier to process. (FWIW, the print method has >>>> the same issue) >>>> >>>> And in the future can we avoid newlines in the data? >>> >>> So it's actually worse than I thought. :( The wrapping and adding of parens seems to be a function of line length, not record type. There are DS records in the root zone that don't trigger the wrapping, and there are AAAA records in the root zone that do: >>> >>> d.xn--node.globalanycastcloud.freenom.net. 172800 IN AAAA ( >>> 2a04:1b00:b::4 ) >>> >>> dns1.u-registry.com. 172800 IN AAAA ( >>> 2604:4300:a:8c:5054:ff:fe47:8582 ) >>> >>> Can we please remove this ill-advised change altogether? When processing these records it magnifies my code complexity significantly if I have to test every record for the presence of newlines, join them if they are present, extract patterns with and without parens, etc. I can absorb the development cost of testing for two different DS record formats because the new format is a legitimate improvement. But having to deal with the multiline/paren issue appearing at random for certain (all?) record types is not Ok. >>> >>> Doug >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users > From rwfranks at acm.org Wed Apr 20 00:16:18 2016 From: rwfranks at acm.org (Dick Franks) Date: Wed, 20 Apr 2016 01:16:18 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <57167FC3.7040900@dougbarton.us> References: <5714ACAA.5060804@nlnetlabs.nl> <699a16f6df76b838f9254022b029e542@dougbarton.us> <57167FC3.7040900@dougbarton.us> Message-ID: On 19 April 2016 at 19:58, Doug Barton wrote: > On 04/19/2016 08:39 AM, Dick Franks wrote: > > You focused on the wrong part of what I said. Previous to this RC > errorstring was undefined, which allowed me to wrap my previous code in an > 'if (defined ...' block. Now it's defined, but empty (or has spaces, or > doesn't, whatever). That's much worse, as now I have to do a string compare. > We appear to have a problem establishing simple matters of fact. Slightly modifying my previous snippet: print 'Net::DNS ', Net::DNS->version, "\n"; my $resolver = Net::DNS::Resolver->new(); $resolver->nameserver('ns.net-dns.org'); my @zone = eval { $resolver->axfr('net-dns.org') }; print scalar(@zone), "\n"; my $errorstring = $resolver->errorstring; print "errorstring is ", defined($errorstring) ? "defined\n" : "undefined\n"; gives Net::DNS 1.05 2648 errorstring is defined -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Wed Apr 20 01:35:00 2016 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Apr 2016 18:35:00 -0700 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: References: <5714ACAA.5060804@nlnetlabs.nl> <699a16f6df76b838f9254022b029e542@dougbarton.us> <57167FC3.7040900@dougbarton.us> Message-ID: <5716DCC4.30501@dougbarton.us> On 04/19/2016 05:16 PM, Dick Franks wrote: > > On 19 April 2016 at 19:58, Doug Barton > wrote: > > On 04/19/2016 08:39 AM, Dick Franks wrote: > > You focused on the wrong part of what I said. Previous to this RC > errorstring was undefined, which allowed me to wrap my previous code > in an 'if (defined ...' block. Now it's defined, but empty (or has > spaces, or doesn't, whatever). That's much worse, as now I have to > do a string compare. > > > We appear to have a problem establishing simple matters of fact. No, I keep hoping that I don't have to spell out everything in nauseating detail. :) Previously, if there was nothing in errorstring, it was also undefined. Obviously if there is a message there (as both you and I have demonstrated to be true in the past) it had to be defined. The current state with the 1.06-RC is that the field is empty, but the variable is defined. That means that I can't just wrap my error-checking routine in 'is (defined ...' I now have to do a string compare. (In fact it's worse than that, I have to do both.) That's bad. Also, you ignored the other issues that I raised in my previous message about errorstring. It would be great if you could respond to those as well. Doug From rwfranks at acm.org Wed Apr 20 04:08:10 2016 From: rwfranks at acm.org (Dick Franks) Date: Wed, 20 Apr 2016 05:08:10 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 1.06 In-Reply-To: <5716DCC4.30501@dougbarton.us> References: <5714ACAA.5060804@nlnetlabs.nl> <699a16f6df76b838f9254022b029e542@dougbarton.us> <57167FC3.7040900@dougbarton.us> <5716DCC4.30501@dougbarton.us> Message-ID: On 20 April 2016 at 02:35, Doug Barton wrote: > On 04/19/2016 05:16 PM, Dick Franks wrote: > >> >> On 19 April 2016 at 19:58, Doug Barton > > wrote: >> >> On 04/19/2016 08:39 AM, Dick Franks wrote: >> >> You focused on the wrong part of what I said. Previous to this RC >> errorstring was undefined, which allowed me to wrap my previous code >> in an 'if (defined ...' block. Now it's defined, but empty (or has >> spaces, or doesn't, whatever). That's much worse, as now I have to >> do a string compare. >> >> >> We appear to have a problem establishing simple matters of fact. >> > > No, I keep hoping that I don't have to spell out everything in nauseating > detail. :) > > Previously, if there was nothing in errorstring, it was also undefined. What is there to misunderstand about "defined"? I have demonstrated, in nauseating detail as you put it, that errorstring *IS* defined after axfr() using Net::DNS 1.05. You have provided not a shred of reproducible evidence to show otherwise. > Obviously if there is a message there (as both you and I have demonstrated > to be true in the past) it had to be defined. > > The current state with the 1.06-RC is that the field is empty, but the > variable is defined. That means that I can't just wrap my error-checking > routine in 'is (defined ...' I now have to do a string compare. (In fact > it's worse than that, I have to do both.) That's bad. > ROFL > Also, you ignored the other issues that I raised in my previous message > about errorstring. It would be great if you could respond to those as well. I have better things to do -------------- next part -------------- An HTML attachment was scrubbed... URL: From beachbumm777 at gmail.com Sun May 8 05:12:59 2016 From: beachbumm777 at gmail.com (anti trust) Date: Sat, 7 May 2016 22:12:59 -0700 Subject: [net-dns-users] (no subject) Message-ID: How does this work -------------- next part -------------- An HTML attachment was scrubbed... URL: From beachbumm777 at gmail.com Sun May 8 10:02:35 2016 From: beachbumm777 at gmail.com (anti trust) Date: Sun, 8 May 2016 03:02:35 -0700 Subject: [net-dns-users] Send list Message-ID: I need a dns to send stuff too -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Fri May 20 12:08:34 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 20 May 2016 14:08:34 +0200 Subject: [net-dns-users] Second release candidate for Net::DNS 1.06 Message-ID: <573EFE42.2080205@nlnetlabs.nl> Dear all, We have a second candidate for the upcoming 1.06 bugfix release of Net::DNS. A list of bugfixes can be found in the Changes section below. This release candidate includes changes resulting from discussion and comments from the mailing list on error handling with zone transfers. Resulting in: * axfr() in list context returns the complete zone if successful. If an error occurs, an empty list is returned with errorstring() indicating the reason. * axfr() in scalar context returns an iterator if successful. If a connection failure occurs, undef is returned with errorstring() indicating the reason. The iterator will raise an exception if the transfer can not be completed. * Resolver documentation has been clarified to make explicit that errorstring() is valid immediately after an error and meaningless otherwise. In the process of reducing code complexity and improving code coverage of the unit tests, the value of errorstring() is with this release candidate *meaningless* when not consulted directly after failure, similar to the predefined perl variable $! (see perlvar). Testing successful zone transfer by testing errorstring() for a value that it was known to have before the transfer, will no longer work. Please review this candidate carefully. In particular with respect to error handling. If no issues arise, the actual release will follow Friday the 27th of May. link: https://www.net-dns.org/download/Net-DNS-1.05_06.tar.gz sha1: 5d8533d408ecf8135111132bbf82959190f25ee9 asc : https://www.net-dns.org/download/Net-DNS-1.05_06.tar.gz.asc Regression testing results: https://www.net-dns.org/regression/. Changes ======= Fix rt.cpan.org #113579 Net::DNS::Resolver dies on scoped IPv6 nameserver address Fix rt.cpan.org #113020 Resolve::Recurse Hangs Fix rt.cpan.org #112860 improperly terminated AXFR at t/08-IPv4.t line 446. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From willem at nlnetlabs.nl Fri May 27 19:18:13 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 27 May 2016 21:18:13 +0200 Subject: [net-dns-users] Net::DNS 1.06 released Message-ID: <57489D75.3040305@nlnetlabs.nl> Dear users of Net::DNS, We have a new release, version 1.06 of Net::DNS. This release addresses the following issues: - Parsing of scoped IPv6 has been fixed when IO::Socket::IP is used (regression since 1.05). - Interfering middle boxes will no longer be able to hang recursive lookups and interfere with unit tests. - Linking of CNAMEs to its target address records with resolver->nameservers() will be done case insensitive. This release also includes updated error reporting, resulting from discussion and comments from the mailing list: - axfr() in list context returns the complete zone if successful. If an error occurs, an empty list is returned with errorstring() indicating the reason. - axfr() in scalar context returns an iterator if successful. If a connection failure occurs, undef is returned with errorstring() indicating the reason. The iterator will raise an exception if the transfer can not be completed. - Resolver documentation has been clarified to make explicit that errorstring() is valid immediately after an error and meaningless otherwise. For a complete list of changes and bugfixes see the Changes section. link: https://www.net-dns.org/download/Net-DNS-1.06.tar.gz sha1: 1bd2a07cc0cc2b2414f38208a17f9742a0252418 asc : https://www.net-dns.org/download/Net-DNS-1.06.tar.gz.asc Regression testing results: https://www.net-dns.org/regression/. Changes ======= Fix rt.cpan.org #114351 Case sensitive compression breaks resolver->nameservers() Fix rt.cpan.org #113579 Net::DNS::Resolver dies on scoped IPv6 nameserver address Fix rt.cpan.org #113020 Resolve::Recurse Hangs Fix rt.cpan.org #112860 improperly terminated AXFR at t/08-IPv4.t line 446. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From willem at nlnetlabs.nl Fri Aug 26 12:23:35 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 26 Aug 2016 14:23:35 +0200 Subject: [net-dns-users] Net::DNS::SEC 1.03 released Message-ID: Dear all, We have just released version 1.03 of Net::DNS::SEC. This release has no core code changes whatsoever. It contains only an altered Makefile.PL that avoids problems with old MakeMaker and improved unit tests to get 100% coverage! and to address issues arising from incompatible versions of prerequisite. For a complete list of changes and bugfixes see Changes below. link: https://www.net-dns.org/download/Net-DNS-SEC-1.03.tar.gz sha1: 6db12f0189390c9a7221a6691a21f74ab956b87b asc : https://www.net-dns.org/download/Net-DNS-SEC-1.03.tar.gz.asc Changes ======= Fix: rt.cpan.org #108908 Tests break when Net::DNS gets shadowed by existing pre-1.01 version. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From willem at nlnetlabs.nl Fri Dec 23 15:25:19 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 23 Dec 2016 16:25:19 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 1.07 Message-ID: Dear users of Net::DNS, We have a candidate for the upcoming 1.07 release of Net::DNS. This release contains bugfixes and general maintenance work only. For a complete overview see the Changes below. Please review this candidate carefully. If no issues arise, the actual release will follow Thurday the 29th of December 2016. link : https://www.net-dns.org/download/Net-DNS-1.06_06.tar.gz sha256: 6d10d37e035acb608f06d59c053992bc0a5d71306a4cf3d0713cc2f10a5976f8 asc : https://www.net-dns.org/download/Net-DNS-1.06_06.tar.gz.asc Regression test results: https://www.net-dns.org/regression/ Changes ======= Fix rt.cpan.org #118598/#108908 Serious Makefile.PL issues "make install" now suppressed if pre-1.01 version detected Fix rt.cpan.org #115558 Net::DNS::Nameserver does not allow EDNS replies Fix rt.cpan.org #114917 Net::DNS::ZoneFile fails to parse mixed case mnemonics Fix rt.cpan.org #114876 Use of uninitialized value in lc at MSWin32.pm line 77 Fix rt.cpan.org #114819 Net::DNS fails to compile with taint checks enabled -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 829 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Fri Dec 23 22:26:43 2016 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 23 Dec 2016 22:26:43 +0000 Subject: [net-dns-users] Release candidate for Net::DNS 1.07 In-Reply-To: References: Message-ID: <09b79c6e144662fcc0ee2c9f5357b59d@dougbarton.us> No regressions on my usual workaday scripts. However I did see this error in the test suite: t/08-IPv4.t ................... 76/86 unresolvable name: cname.t.net-dns.org at t/08-IPv4.t line 501. t/08-IPv6.t ................... 76/86 unresolvable name: cname.t.net-dns.org at t/08-IPv6.t line 503. Odd for a couple of reasons ... this is what I got from the system resolver: host cname.t.net-dns.org cname.t.net-dns.org is an alias for a.t.net-dns.org. cname.t.net-dns.org is an alias for a.t.net-dns.org. Not sure how you get that kind of result. Using dig on the same system (OS X El Cap) returns the expected result only once. hope this helps, Doug December 23, 2016 7:33 AM, "Willem Toorop" wrote: > Dear users of Net::DNS, > > We have a candidate for the upcoming 1.07 release of Net::DNS. > > This release contains bugfixes and general maintenance work only. > For a complete overview see the Changes below. > > Please review this candidate carefully. If no issues arise, the actual > release will follow Thurday the 29th of December 2016. > > link : https://www.net-dns.org/download/Net-DNS-1.06_06.tar.gz > sha256: 6d10d37e035acb608f06d59c053992bc0a5d71306a4cf3d0713cc2f10a5976f8 > asc : https://www.net-dns.org/download/Net-DNS-1.06_06.tar.gz.asc > > Regression test results: https://www.net-dns.org/regression > > Changes > ======= > Fix rt.cpan.org #118598/#108908 > > Serious Makefile.PL issues > "make install" now suppressed if pre-1.01 version detected > > Fix rt.cpan.org #115558 > > Net::DNS::Nameserver does not allow EDNS replies > > Fix rt.cpan.org #114917 > > Net::DNS::ZoneFile fails to parse mixed case mnemonics > > Fix rt.cpan.org #114876 > > Use of uninitialized value in lc at MSWin32.pm line 77 > > Fix rt.cpan.org #114819 > > Net::DNS fails to compile with taint checks enabled > > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users From willem at nlnetlabs.nl Thu Dec 29 17:16:50 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 29 Dec 2016 18:16:50 +0100 Subject: [net-dns-users] Net::DNS 1.07 Released Message-ID: <9abab551-e24d-8b94-0ae9-31e9ff61e35d@nlnetlabs.nl> Dear All, We have a new release, version 1.07 of Net::DNS. This release contains bugfixes and general maintenance work only. For a complete list of changes and bugfixes see the Changes section. link : https://www.net-dns.org/download/Net-DNS-1.07.tar.gz sha256: 5f91497f1af9f690153fa05a27a7d73ddada08bed40536fe2d0ac759b7af8492 asc : https://www.net-dns.org/download/Net-DNS-1.07.tar.gz.asc Regression testing results: https://www.net-dns.org/regression/. Changes ======= Fix rt.cpan.org #118598/#108908 Serious Makefile.PL issues "make install" now suppressed if pre-1.01 version detected Fix rt.cpan.org #115558 Net::DNS::Nameserver does not allow EDNS replies Fix rt.cpan.org #114917 Net::DNS::ZoneFile fails to parse mixed case mnemonics Fix rt.cpan.org #114876 Use of uninitialized value in lc at MSWin32.pm line 77 Fix rt.cpan.org #114819 Net::DNS fails to compile with taint checks enabled -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 829 bytes Desc: OpenPGP digital signature URL: