<div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On 2 June 2014 13:34, 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><div><br></div><div>In Net::DNS 0.74 there were methods in Net::DNS::Resolver called axfr_start and axfr_next. In 0.76 there no longer is. I do not agree that that counts as “unchanged”.</div>


<div><br></div></div></div></blockquote><div>Your claim was that axfr() API had changed, which it has not.<br><br></div><div>The primary purpose of both axfr_start() and axfr_next() is to support axfr(). If the requirements change inside there, inevitably they need to change. They have no independent life of their own.<br>


<br></div><div>Change was clearly anticipated by somebody because the perldoc for 0.74 also contains a warning:<br><br>IMPORTANT:<br><br>    This method currently returns the "IO::Socket::INET" object that will be<br>


    used for reading, or "undef" on error. DO NOT DEPEND ON "axfr_start()"<br>    returning a socket object. THIS MIGHT CHANGE in future releases.<br><br></div><div>And it just did.<br><br></div><div>

It is still there, but now it returns a packet, which contains the TSIG record, which cannot be verified without access to the original request packet. The logic is further complicated by the fact that the second and subsequent TSIG records cannot be verified unless its predecessor is also available.<br>


<br></div><div style="word-wrap:break-word">The only practical way to achieve this is for both axfr_start() and axfr_next() to return a packet which can be verified and then the RRs unpacked. Itteration over the RRs themselves is unnecessary for axfr() itself.<br>

<div><br><br></div><div>If memory usage is your main objection, it would be sensible to know how big a problem that poses.<br>
<br></div><div></div><div>As .SE is a TLD, about 50% of your 6.6M will be RRSIGs, almost everything else slightly smaller.  Most of the space is occupied by the RR object hash, the RDATA is almost irrelevant.<br>
<br></div><div>Upper bound memory useage estimate:  1350  .  6M6  = 8.9G bytes.<br></div><div>Discouraging, but feasible on big hardware.<br><br></div><div>Using axfr_start() and axfr_next() to get the packets and iterating over the RRs inside would seem to be the better option.<br>

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