https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6075
--- Comment #21 from Sidney Markowitz <[email protected]> 2009-03-02 14:25:35 PST --- (In reply to comment #12) > Is there any way I can make the debugger more verbose? Any flag I can activate > in ".pm" modules or anything I can test on my side...? As I recall, when I was debugging that code there were the dbg statements in SpamAssassin that are activated with -D dns and are specifically no more verbose than would be useful for general troubleshooting with debug logs, the debug option in the NET::DNS::Resolver constructor, and then for more detail after that I had to insert my own debug output statements that I removed once I found the bug. No shortcuts to the usual step-by-step debugging. After reading all the other comments after comment #12, I would agree that your best bet is to set up your own local caching DNS server. Either the problem will go away, in which case you can attribute it to the complexities of your ISP's name server setup, or else it will continue and you can look closely at what SpamAssassin and your DNS server are doing. The only other approach I see is digging deep into NET::DNS::Resolver to see exactly where the packets go and how they come back. I would give up on trying to extract a piece of perl code to call Net::DNS::Resolver the same way as SpamAssassin is doing. SpamAssassin has a very different task then most clients built on top of Net::DNS::Resolver because it is sending out many queries that are to be dealt with asynchronously as they come back. The way it uses Net::DNS::Resolver is going to be very different from simple test harnesses that call Net::DNS::Resolver. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
