You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2013/02/18 18:18:11 UTC
[Bug 6910] New: What DNS buffer size (EDNS) - or to implement a DNS
over TCP fallback
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: dev@spamassassin.apache.org
Reporter: Mark.Martinec@ijs.si
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.
[Bug 6910] What DNS buffer size (EDNS) - or to implement a DNS over
TCP fallback
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6910
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #1 from Kevin A. McGrail <km...@pccc.com> ---
Since EDNS is disabled by default, it sounds to me like a sane buffer would be
4096. Is the buffer configurable?
Not it for the TCP fallback but I see the importance!
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6910] What DNS buffer size (EDNS) - or to implement a DNS over
TCP fallback
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6910
--- Comment #3 from Kevin A. McGrail <km...@pccc.com> ---
(In reply to comment #2)
> > Since EDNS is disabled by default, it sounds to me like a sane buffer would
> > be 4096. Is the buffer configurable?
>
> Currently EDNS is disabled by default for compatibility with previous
> versions (i.e. a 512 bytes buffer is implied).
>
> Setting buffer size to 4096 by default would be my choice too,
> it should work well (and would mostly avoid a need for a TCP fallback)
> with a local recursive DNS server, which is used by most if not all
> serious installations.
>
> For some SOHO sites using their ISP's DNS server (or some public DNS server),
> this may break their DNS resolving and would require them to explicitly
> turn off the option in their SpamAssassin configuration - so this may
> require a compatibility note in release notes. On the other hand, such
> sites even now probably suffer from breakage in their DNSBL lookups,
> without realizing they have a problem or just not caring about it.
>
I agree that a local caching nameserver is the best setup for any installation.
Having that setup will support EDNS without the same concerns.
So to me it seems like 3.4.0 is a good time to turn on EDNS by default...
> Btw, setting a buffer size to anything larger than 512 bytes implies
> the EDNS option in a DNS packet. Or in other words: the EDNS option
> in a DNS query its the (only) mechanism by which a client can indicate
> it is capable of receiving UDP replies larger than the traditional
> 512 bytes limit.
Good point.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6910] What DNS buffer size (EDNS) - or to implement a DNS over
TCP fallback
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6910
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|Undefined |3.4.0
--- Comment #4 from Mark Martinec <Ma...@ijs.si> ---
Ok, changing a default to 'dns_options edns=4096'.
Will remember to add this to compatibility section of release notes.
trunk:
Bug 6910: changed a default to edns=4096 (What DNS buffer size (EDNS);
adjust Plugin::DKIM accordingly
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/Plugin/DKIM.pm
Committed revision 1448607.
The current documentation (Conf.pm) now says:
=item dns_options opts (default: norotate, nodns0x20, edns=4096)
Provides a (whitespace or comma -separated) list of options applying
to DNS resolving. Available options are: I<rotate>, I<dns0x20> and
I<edns> (or I<edns0>). Option name may be negated by prepending a I<no>
(e.g. I<norotate>, I<NoEDNS>) to counteract a previously enabled option.
Option names are not case-sensitive. The I<dns_options> directive may
appear in configuration files multiple times, the last setting prevails.
Option I<edns> (or I<edsn0>) may take a value which specifies a requestor's
acceptable UDP payload size according to EDNS0 specifications (RFC 2671bis
draft), e.g. I<edns=4096>. When EDNS0 is off (I<noedns> or I<edns=512>)
a traditional implied UDP payload size is 512 bytes. When the option is
specified but a value is not provided, a conservative default of 1240 bytes
is implied. It is recommended to keep I<edns> enabled when using a local
recursive DNS server which supports EDNS0 (like most modern DNS servers do),
a suitable setting in this case is I<edns=4096>, which is also a default.
Allowing packets larger than 512 bytes can avoid truncation of answer
resource records in large DNS responses (like in TXT records of some SPF
and DKIM responses, or when an unreasonable number of A records is published
by some domain). The option should be disabled when a recursive DNS server
is only reachable through some old-fashioned firewall which bans DNS UDP
packets larger than 512 bytes. A suitable value when a non-local recursive
DNS server is used and a firewall does allow EDNS0 but blocks fragmented
IP packets is perhaps 1240 bytes, allowing a DNS UDP packet to fit within
a single IP packet in most cases.
[...]
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 6910] What DNS buffer size (EDNS) - or to implement a DNS over
TCP fallback
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6910
--- Comment #2 from Mark Martinec <Ma...@ijs.si> ---
> Since EDNS is disabled by default, it sounds to me like a sane buffer would
> be 4096. Is the buffer configurable?
Currently EDNS is disabled by default for compatibility with previous versions
(i.e. a 512 bytes buffer is implied).
Setting buffer size to 4096 by default would be my choice too,
it should work well (and would mostly avoid a need for a TCP fallback)
with a local recursive DNS server, which is used by most if not all
serious installations.
For some SOHO sites using their ISP's DNS server (or some public DNS server),
this may break their DNS resolving and would require them to explicitly
turn off the option in their SpamAssassin configuration - so this may
require a compatibility note in release notes. On the other hand, such
sites even now probably suffer from breakage in their DNSBL lookups,
without realizing they have a problem or just not caring about it.
Btw, setting a buffer size to anything larger than 512 bytes implies
the EDNS option in a DNS packet. Or in other words: the EDNS option
in a DNS query its the (only) mechanism by which a client can indicate
it is capable of receiving UDP replies larger than the traditional
512 bytes limit.
--
You are receiving this mail because:
You are the assignee for the bug.