| Subject: | Net::DNS::Resolver::Recurse issues lots of IMHO unnecessary DNS requests. |
When trying to find out why our monitoring system occasionally
gets timeouts when trying to resolve NS records using
Net::DNS::Resolver::Recurse version 515 from Net::DNS 0.55
(that is, the resolving process sometimes seems to take about
a minute), I noticed that Net::DNS::Resolver::Recurse issues
a lot of IMHO unneccessary queries, e.g. it needs 18 queries
for resolving (the A RRset for) www.noris.de where 6 should
be sufficient, cmp. the debug output attached, which I
created using the following script:
| #!/usr/bin/perl -w
|
| use strict;
|
| use Net::DNS::Resolver::Recurse;
|
| my $res = Net::DNS::Resolver::Recurse->new or die;
| $res->hints('198.41.0.4');
| $res->debug(1);
| $res->query_dorecursion('www.noris.de');
The problem is as follows:
In its answer to request #2, c.de.net tells the module that dns{1,2,3}.noris.net are authoritative for noris.net, but does
not provide IP addresses for this servers in the additional
section.
So Net::DNS::Resolver::Recurse tries to find out these IP
addresses itself, which it does in a very unefficient manner:
* It first tries to look up an AAAA RRset for dns1.noris.net,
even though our machine does not have IPv6 connectivity anyway.
* When it learns from answer #5 that there is no AAAA record
for dns1.noris.net, it starts to look up the A RRset for
that server. Although it should already know from answer #4
that dns.noris.{de,net,ch} are authoritative for noris.net,
it starts over at d.root-servers.net to find that out again
(requests #6 and #7).
* After finding out the (A)ddress for dns1.noris.net it does
the same (first resolving the AAAA RRset, then the A RRset)
for dns{2,3}.noris.net, issuing ten further DNS queries (#8
to #17). Why does it do that anyway? IMHO the knowledge
of the address of dns1.noris.net should be sufficient to
send query #18 and thus determine the requested answer.
Please let me know whether you intend to optimize this in the
near future yourself, or if you'd appreciate a patch for it,
because if neither nor, I'd probably have to switch back to
my own resolver library.
Regards,
fany
Message body not shown because it is not plain text.