Thanks for trying it out. You were right about the eval - it was part of a callback routine called from Tk::Timer. I don't know why it wasn't crashing the whole program, but I swear I had strict and diagnostics on.

I eventually got it working with Net::DNS, and managed to reproduce the error there too. But because the query is broken into parts I was able to get a bit closer to the problem. If you do a reverse lookup (effectively an ordinary lookup on the reverse zone) and there's no record, you actually get a DNS reply packet with no records in it rather than a fail. But it appears the writers of the code did not envisage a DNS lookup that was partially successful (returns a packet with no RRs, rather than failing outright), since if you can get through to the primary DNS for a zone you can always get either a address RR or a not found (for a host->address lookup). But the reverse zone DNS seems to return a 'found' (since we know the machine exists) with no RRs (since the machine doesn't have a hostname that the DNS knows about). The code doesn't seem do any sanity checking, tries to load an RR (which isn't there) and then falls over.

Phew!

The short of that is that reverse DNS lookups on broken domains can break the support libraries. The only real way to be sure is to use Net::DNS and check that you actually have a RR before you try and print it out.

* A RR is a resource record, or a mapping from hostname to ip address or vice versa. They have to be manually entered in the DNS but some DNS admins get lazy/clever and don't enter the ip address to hostname listing.

____________________
Jeremy
I didn't believe in evil until I dated it.