Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 75330
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: ABH [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.68
Fixed in: (no value)



Subject: Fatal test failures on 0.68 from 10-recurse.t
On carious RHEL/CentOS 5.x systems (perl 5.8.8) I get this test failure installing Net::DNS 0.68: t/10-recurse...............Use of uninitialized value in concatenation (.) or string at t/NonFatal.pm line 28. # got: '2' # expected: '3' # Looks like you planned 12 tests but only ran 11. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED test 12 Failed 1/12 tests, 91.67% okay Output from stdout attached.
Subject: 10-recurse-verbose.txt

Message body is not shown because it is too large.

Hi ABH, The test that failed counted the recursive steps towards a.t.net-dns.org. When asking the .org authoritative about net-dns.org, it received four possible authoritative nameservers, but glue for just one: ns1.net-dns.org. The server listening on ns1.net-dns.org was down (triggering the error) and the other nameservers were not tried because their IP address was unknown. I think this is an error an will look into it. Thanks for the report.
Hi ABH, I'm happy to tell you that this issue is now resolved in trunk. When recursing, the IP addresses of delegation nameservers were looked up only when no glue records were available for none of the delegations at all. With glue, the other (glueless) nameservers were simply dropped. This was obviously wrong. I have fixed it in such a way that the IP's of the other nameservers are looked up if querying the one with glue failed. This at least leads to an answer, but can take many more queries then the minimum needed. t/10-recurse.t had to be fixed to accept at least 3 i.s.o. precisely 3. Because of some other broken nameservers, it took 48 queries for a.t.net-dns.org. (with a non responsive ns1.net-dns.org). Ideally one would wish to lookup the nameserver "to be queried" only (when necessary), but that is out of the scope of this ticket. Thanks again for our report, -- Willem
Thank you for fixing it so quick!