https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8225
--- Comment #3 from Mark Martinec <Mark.Martinec@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.
--- Comment #3 from Mark Martinec <Mark.Martinec@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.