This is a specific case of a more general bug, that being:
A query for a type on an entry that does exist but does not have that
specific type, causes an infinite loop.
Example:
$ dig -tTXT ns1.netscape.com.
; <<>> DiG 9.2.2-P2 <<>> -tTXT ns1.netscape.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44700
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.netscape.com. IN TXT
;; AUTHORITY SECTION:
netscape.com. 515 IN SOA ns.netscape.com.
dnsmaster.netscape.com. 2003102000 3600 900 604800 600
;; Query time: 22 msec
;; SERVER: 216.190.237.135#53(216.190.237.135)
;; WHEN: Fri Oct 24 17:09:02 2003
;; MSG SIZE rcvd: 83
$
Trying to run this same query through Net::DNS::Resolver::Recurse
would cause the loop because NS1.NETSCAPE.COM does have a record for
type "A" but none from type "TXT".
Here is the equivalent perl code which of course will hang:
#!perl
use Net::DNS::Resolver::Recurse;
my $res = new Net::DNS::Resolver::Recurse;
my $packet = $res->query_dorecursion("ns1.netscape.com.", "TXT");
On Tue, 14 Oct 2003, Chris Reinhardt wrote:
Show quoted text> I think we should just handle this special case
> and return the packet with the single SOA
> record in the authority section.
I disagree. As stated in the documentation, query_dorecursion is
intended to behave just like query, except doing the recursion itself
instead of asking another resolver to do it. The normal query method
of Net::DNS::Resolver would return undef because the answer section is
empty. Some applications depend on this functionality and returning
the packet itself would yield a "true" value but without answers.
