https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8225
--- Comment #3 from Mark Martinec <mark.marti...@ijs.si> --- > [...] we have no code for DNS > queries using TCP, and we have quite a bit of code to support reuse of > sockets for efficiency with the large number of queries Reusing sockets is only a partial reason for using UDP for queries. Perhaps more important is the ability to shoot out dozens of DNS queries almost simultaneously (while going through the rules), and then process replies (quasi asynchronously) while they are arriving, thus interleaving rules processing time with a stream of returning DNS replies, greatly reducing idle wait times and total elapsed time to a SA result. There are two timing constraints that govern how long we are willing to wait for DNS replies: the rbl_timeout configuration option, and the dynamic master_deadline. These allow us to abort slow-responding DNS queries in time when a deadline is approaching, so that SpamAssassin can be used in a pre-queue mailer setup, which is much more time sensitive than a post-queue setup. See _start_lookup() in AsyncLoop.pm on how it calculates $t_end . Letting Net::DNS do an automatic fallback to TCP introduces inability to restrict elapsed time, and serializes DNS queries. We should be careful to decide when this is worthwhile. Using a local DNS resolver which supports EDNS0 (UDP queries with a large buffer, e.g. 4 kB) greatly reduces a need for a TCP DNS query, as even the most unreasonably large DNS records fit into a UDP packet most of the time. Just don't use a DNS resolver outside of ones local network, which is a good practice for SpamAssassin anyway. -- You are receiving this mail because: You are the assignee for the bug.
