[net-dns-users] AXFR (was: Re: sep() and is_sep())

[Dick Franks]

On 2 June 2014 13:34, Calle Dybedahl <calle at init.se> wrote:

>
> 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”.
>
> Your claim was that axfr() API had changed, which it has not.

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.

Change was clearly anticipated by somebody because the perldoc for 0.74
also contains a warning:

IMPORTANT:

    This method currently returns the "IO::Socket::INET" object that will be
    used for reading, or "undef" on error. DO NOT DEPEND ON "axfr_start()"
    returning a socket object. THIS MIGHT CHANGE in future releases.

And it just did.

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.

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.


If memory usage is your main objection, it would be sensible to know how
big a problem that poses.

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.

Upper bound memory useage estimate:  1350  .  6M6  = 8.9G bytes.
Discouraging, but feasible on big hardware.

Using axfr_start() and axfr_next() to get the packets and iterating over
the RRs inside would seem to be the better option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20140602/6cd29f99/attachment.htm>