http://bugzilla.spamassassin.org/show_bug.cgi?id=4260
------- Additional Comments From [EMAIL PROTECTED] 2005-05-10 17:03 ------- Regarding comment #56 and comment #58 -- I would have to use only the data from the question section. That turns out not to be so easy to get, as Question->data takes an argument of the byte offset of the question data packet within Packet->data. Also, looking at the Net::DNS source code, it appears that the return value is computed on the fly from the non-binary qname, qtype, and qclass fields. So there is little reason to try to get Question->data instead. What is relevant about your suggestion is that Net::DNS does store its canonicalized values in qname, etc., once the packet is created. So I can use $packet->id . $ques->qname . $ques->qtype . $ques->qclass to get a perfect key to uniquely match up the query and reply packets. Regarding my comment #55, the slowdown I saw seems to have been a bug in my code. Starting from scratch and proceeding carefully I have found that I can simply use $id = $packet->id . $ques->qname . $ques->qtype . $ques->qclass as the key, let perl do the hashing, and everything is as fast as using the numeric packet id alone as the key. That should completely eliminate the collisions that the bogus RRs are indicating, as well as all those which are not picked up by the test for bogus RRs but could still produce incorrect results. Using this I should be able to test how many of those latter collisions are in a typical mass check run. It will be some hours of testing to verify all this. The nice thing about this is that it requires almost no new code to make it work. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
