<div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On 19 April 2016 at 06:38, Doug Barton <span dir="ltr"><<a href="mailto:dougb@dougbarton.us" target="_blank">dougb@dougbarton.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is better in some ways, and worse in others. :)<br>
<br>
The errorstring is being filled again for search/query/send, which is great. :)</blockquote><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  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.</blockquote><div><br></div><div>If you are going to persist with this argument, at least do us the courtesy of citing verifiable facts.<br><br>        my $resolver = Net::DNS::Resolver->new();<br>        $resolver->nameserver('185.49.140.63');`<br>        $resolver->domain('<a href="http://net-dns.org">net-dns.org</a>');<br><br>        my @zone = eval { $resolver->axfr() };<br>        print scalar(@zone), "\n";<br>        my $errorstring = $resolver->errorstring;<br>        print length($errorstring), "\t$errorstring\n";<br><br></div><div>produces<br><br>        2648<br>        0<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br></blockquote><div><br>0.81<br><br>        2648<br>        25    unknown error or no error<br><br></div><div>axfr() did not modify errorstring in any way at all.<br></div><div>It is easy to demonstrate that if other values occur in errorstring they were left over from a previous query, which is downright unhelpful.<br><br></div><div>Worse, the documentation implied that errorstring() relates to axfr(), which it clearly does not, and never did.<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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:<br>
<br>
aaa.    86400   in      ds      \# 24 54cb08016d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2X<br></blockquote><div><br></div><div>Because Net::DNS::SEC was not installed.<br><br></div><div>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.<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I can certainly see how this is suboptimal, and the new format is better, but the problem is that it has a newline embedded:<br>
<br>
aaa.        86400   in      ds      ( 21707 8 1<br>
        6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 )<br>
<br>
Can we get this in one line? It makes it a whole lot easier to process. (FWIW, the print method has the same issue)<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

And in the future can we avoid newlines in the data?<br></blockquote><div><br><br></div></div></div></div>