<div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On 17 April 2016 at 22:11, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/12/2016 05:32 PM, Dick Franks wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
axfr()<br>
<br>
Since 0.43 there has been no attempt to provide anything in errorstring.<br>
</blockquote>
<br></span>
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.<span class=""><br></span></blockquote><div><br></div><div>Your experience is no match for my perl script which repeats a test using every version from 0.12 to 1.05.<br></div><div>So I make my assertions without the slightest risk of contradiction.<br></div><div> </div><div>[snip]<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adding<br><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
RCODE: NOERROR provides no useful information because the transfer gets<br>
aborted if anything else shows up in a packet header (per RFC1035, 6.3).<br>
</blockquote>
<br></span>
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.<span class=""><br></span></blockquote><div><br></div><div>Unconvinced.<br></div><div>If there is no error, there is no point in providing errorstring to explain that there wasn't one.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
send()<br>
<br>
The proper place to test the outcome of the transaction is using<br>
$result->header->rcode() which is a recognised feature of DNS protocol.<br>
</blockquote>
<br></span>
As I mentioned previously, that only works for the send method. It does not work for search or query.</blockquote><div><br></div><div>Good point<br></div><div> <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I note that errorstring has always been set (redundantly) the same as<br>
rcode.  Perhaps we need to accept that as one of Net::DNS's historical<br>
quirks, which probably arose from design indecision in its very early<br>
history.  It is certainly present in 0.12, where hardly anything else<br>
works exactly as it does now.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>Same point<br> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As with axfr(), TSIG errors get funnelled into errorstring, so there is<br>
no longer any guarantee that it will be one of the usual RCODE<br>
mnemonics.  Other than that, I am minded to restore the old behaviour.<br>
</blockquote>
<br></span>
Yay! That's a good start. :)<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div>Follows from your observation about search and query<br></div><div><br><br></div></div></div></div>