https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6910
Bug ID: 6910
Summary: What DNS buffer size (EDNS) - or to implement a DNS
over TCP fallback
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Libraries
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Now that the Bug 6862 enhancement request implemented an EDNS setting
("Allow a DNS resolver to use EDNS - UDP packets larger than 512 bytes")
and also started logging (at the info level) cases of truncated DNS
responses which should have been re-tried over TCP, examining the log
shows that it is not uncommon for SpamAssassin not to receive a
satisfactory DNS response because the reply would be larger than
a default UDP buffer size of 512 bytes.
To refresh our mind: a DNS query packet may indicate a maximum
UDP buffer size it is willing to accept for a DNS reply over UDP.
A traditional default is 512 bytes. Using an EDNS option in a
DNS query a larger buffer size may be specified. If a reply
over UDP would require more than allowed size, the responding
DNS server sets a 'truncated' flag in a reply and provides only
a small subset of requested data, or possibly none at all.
When a reply has the 'truncated' flag turned on, the client
is supposed to re-issue the DNS query, but this time over TCP
- and SpamAssassin doesn't do that!
Years ago, when SpamAssassin project chose to avoid calling
Net::DNS::Resolver::query but would use an asynchronous
bgsend and bgread and callbacks to make it possible to have
multiple DNS queries outstanding in parallel, apparently a need
for a fallback to TCP in case of a truncated response was never
considered or implemented.
Here is a list of DNS queries logged over the last day or two,
which returned a 'truncated' flag in a reply (with EDNS disabled,
i.e. replies would exceed 512 bytes):
cnt type/domain
1 A/mktlionbrasil.info
1 MX/tenalps.gtml1.com
1 TXT/dlx35949.pur3.net
1 TXT/pmi.org
1 TXT/verticalresponse.com
1 TXT/vtex.com.br
2 A/ns58.phtco.com
2 A/ns59.phtco.com
2 NS/ahmu.edu.cn
2 TXT/hilton.com
2 TXT/ukrs394971.pur3.net
2 TXT/wiley.com
3 A/mx03.relaymailers.jp
3 TXT/anastasiadate.com
3 TXT/ukrs394972.pur3.net
4 TXT/dmx1.bfi0.com
4 TXT/upr.si
4 PTR/<IP>.in-addr.arpa
5 A/cyberediclick.com
5 A/cydrous.com
6 TXT/spcollege.edu
20 MX/vigoda.ru
20 TXT/vigoda.ru
23 TXT/usc.edu
85 TXT/<IP>.sa-trusted.bondedsender.org
124 TXT/<IP>.sa-accredit.habeas.com
157 TXT/spf1.amazon.com
215 A/antirediclick.com
815 A/clicksplusdirect.com
For a requested A (or MX) record in most cases it means the domain
is declaring a ridiculous number of A records, and SpamAssassin
received none of them! For TXT records it usually means a SPF
or DNSBL answer was too long, but often at least some subset
of the information does reach SpamAssassin. A long Google's
DKIM public key also falls in this category if a resolver would
be a 'Bind', which provides a marginally larger reply compared
to the 'Unbound' DSN server.
Specifying a large UDP buffer size using ENDS0 option would
avoid most if not all of the above cases. A need for a fallback
to TCP is diminished when a buffer size is sufficiently large.
Unfortunately specifying a large buffer size has some consequences:
- some DNS recursive servers do not support EDNS option (rare these days)
- DNS recursive servers cap the size by its own limit, so usually
the limit is 4096 even if a client would be willing to accept
a larger size reply
- some firewalls would block queries with an EDNS option, or would
block replies exceeding a traditional 512 byte limit
- when a large UDP packet is wrapped to an IP layer (subject to MTU),
the packet needs to be fragmented, and some firewalls would
block IP fragments.
A fragmentation and firewall issues are usually only in play if
SpamAssassin is using a remote recursive DNS servers (e.g. a public
server, or ISP's server). When a recursive DNS servers is local
(which is a normal case at any site beyond a SOHO site), this is not
a problem, and ENDS0 buffer size of 4096 can be safely specified,
avoiding most if not all needs for a TCP fallback. A local recursive
DNS server would do its normal TCP fallback facing the target DNS,
but would obey the local ENDS0 option towards its local clients.
For compatibility with previous versions of SpamAssassin, and for
the benefit of SOHO users, the current default is 'dns_options noedns'.
Keeping this would require SpamAssassin to implement a TCP fallback
(or accept the current situation where some replies are lost).
Choosing a larger default may break some SOHO installations.
So the question(s):
- what should be a default buffer size? 'dns_options EDNS=nnnn'
- anybody volunteering to implement DNS over TCP fallback? :)
--
You are receiving this mail because:
You are the assignee for the bug.
