<div dir="ltr"><div class="gmail_extra"><div><div dir="ltr"><span></span></div></div>
<br><div class="gmail_quote">On 2 June 2014 08:31, Calle Dybedahl <span dir="ltr"><<a href="mailto:calle@init.se" target="_blank">calle@init.se</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">

<div style="word-wrap:break-word"><div><br></div>I just found that the interface to AXFR has also changed completely.</div></blockquote><div><br></div><div>Wild exaggeration.  TSIG verification has been added.  In all other respects, the API is unchanged.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>1) Without the concluding SOA record, how do I tell if the server sent me the whole zone or stopped in the middle?</div>

<div></div></div></blockquote><div> <br>    Returns a list of "Net::DNS::RR" objects, or empty list if the zone<br>    transfer failed.<br></div><div><br>    The redundant SOA record that terminates the zone transfer is not returned<br>

    to the caller.<br></div><div>[perldoc Net::DNS::Resolver]<br></div><div><br></div><div>Although the perldoc for 0.68 says it returns undef if zone transfer failed, the code never actually did so.<br><br></div><div>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.<br>

<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>2) Returning all RRs in a single list rather than giving me one at a time</div>

</div></blockquote><div><br></div><div>$res->axfr() has always returned a single list.<br></div><div> <br></div><div>The internal axfr_start() and axfr_next() return a packet. This is necessary to perform TSIG verification. <br>

</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> Suggestions?</div></div></blockquote>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""></span><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-size:12px"></span></span><span class=""></span></div>

</div></blockquote><div> 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.<br>

<br><br></div></div></div></div>