<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body><div data-html-editor-font-wrapper="true" style="font-family: arial, sans-serif; font-size: 13px;">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. <br><br>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. :)<br><br>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 <em><strong>something</strong></em> when used <em><strong>for queries</strong></em>. If I run my demo script on my Ubuntu system I get the following results:<p><br>Perl Version: v5.20.2<br>Net::DNS Version: 0.81</p><p>Testing AXFR<br>17636 RRs in zone<br>Query status for AXFR (Should be NOERROR): unknown error or no error</p>Then for the queries I get this for all 3 methods:<p><br>Query status for method search: (Should be NXDOMAIN): NXDOMAIN<br><br>In my previously working script I also have tests such as:</p><p> if ($res->errorstring eq 'query timed out') {<br> } elsif ($res->errorstring eq 'connection failed') {<br> } elsif ($res->errorstring =~ /NXDOMAIN/i) {<br> } elsif (not $res->errorstring eq 'NOERROR') {</p>(and please keep in mind that I've been using this script, largely unchanged, for over a decade).<br><br>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. <br><br>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. <br><br>(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.)<br><br>If you're wondering why platforms like Debian are staying with such old versions of Net::DNS, this kind of thing is why. <br><br>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: <result>" 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.<br><br>Doug<br><br>-------- Forwarded message -------<br>From: "Dick Franks" <<a target="_blank" tabindex="-1" href="mailto:%22Dick%20Franks%22%20<rwfranks@acm.org>">rwfranks@acm.org</a>><br>To: <a target="_blank" tabindex="-1" href="mailto:net-dns-users@nlnetlabs.nl">net-dns-users@nlnetlabs.nl</a><br>Sent: April 12 2016 11:10 AM<br>Subject: Re: [net-dns-users] With 1.05 on OS X I'm not seeing errorstring on queries<br> <div><div><div dir="ltr"><div><div><div><div><div>Dealing with each case as a separate issue.<br><br>First, modify your AXFR example so we know for certain that it works:<br><br> use Net::DNS;<br><br> print "Perl Version: $^V\n";<br> print "Net::DNS Version: ", Net::DNS->version, "\n";<br><br> print "\nTesting AXFR\n";<br> my $axfr_res = Net::DNS::Resolver->new or die "Instantiation failed: $!";<br> $axfr_res->nameservers("192.5.5.241");<br> my @rr_list = $axfr_res->axfr('.') or die "AXFR failed: $!";<br><br> print scalar(@rr_list), " RRs in zone\n";<br> print "errorstring: ", $axfr_res->errorstring, "\n";<br> exit;<br><br> </div>Armed with the result we should be able to answer three questions:<br><br> Perl Version: v5.22.1<br> Net::DNS Version: 1.05<br><br> Testing AXFR<br> 17636 RRs in zone<br> errorstring: RCODE from server: NOERROR<br> </div>1) Was there an error?<br> </div><div>Clearly not.</div><div></div>2) Is $res->errorstring defined?<br> </div><div>Yes<br> </div></div>3) Did it ever contain just "NOERROR"?<div><div><div><div><div><div></div><div>To answer that we need to look back into history.<br><br> Perl Version: v5.22.1<br> Net::DNS Version: 0.25 (Aug 2002)<br><br> Testing AXFR<br> 17636 RRs in zone<br> errorstring: no zone transfer in progress<br><br><br> Perl Version: v5.22.1<br> Net::DNS Version: 0.43 (Dec 2003)<br><br> Testing AXFR<br> 17636 RRs in zone<br> errorstring: unknown error or no error<br><br> </div><div> Perl Version: v5.22.1<br> Net::DNS Version: 1.03 (Nov 2015)<br><br> Testing AXFR<br> 17636 RRs in zone<br> errorstring: unknown error or no error<br> </div><div>The default text indicates that no attempt was made to put anything in errorstring before version 1.04.<br> </div><div>The answer seems to be "No"<br> </div><div>As there was no error, I may consider reversing my decision at 1.04 and to leave errorstring empty.</div><div></div></div></div></div></div></div><div> <div><div><div dir="ltr">Dick Franks<br><span><font color="#888888">________________________</font></span></div></div></div></div></div></div></div><br> </div></body></html>