On 14 Apr 2017, at 16:54, Rick wrote:
Everything having to do with DNS has gone terribly wrong since the
update.
Spamd cannot do anything at all with DNS even though it's a local
caching NS
and EVERTHING else is resolving just fine. It does pull the name
server
entry correctly but it resolves nothng. If I force it use DNS all
queries
fail. I am at the end of my rope as this issue makes no sense in any
way
shape or fashion. I am including the debug output from spamd --debug
-D dns
(BTW: I tried 8.8.8.8 and 8.8.4.4 in resolv.conf too. Always detects
NS out
of resolv.conf fine)
This is a known problem fixed in both the 3.4 and trunk branches in
Subversion. The root cause is compound flux in how Net::DNS behaved
between v0.83 and v1.03, breaking SA's use of DNS in multiple places. To
cover ALL of the Net::DNS problems, you can apply the patches from bugs
7223, 7231, and 7265. Your specific case looks like it is only the issue
addressed in 7223. Links:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7231
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7265
We're in the end stages of prepping a 3.4.2 release "soonish" so a
checkout from the 3.4 branch should be very close to what gets released
as 3.4.2. If you are willing to run from a svn checkout for a while,
that will get those 3 fixes as well as others.
Here's how I diagnosed the problem:
spamd --debug -D dns
[ abridged...]
Apr 14 16:46:04.987 [17374] dbg: dns: is Net::DNS::Resolver available?
yes
Apr 14 16:46:04.987 [17374] dbg: dns: Net::DNS version: 1.09
Net::DNS is >1.03, so it has all of the "fixes" to its API that caused
SA problems.
Apr 14 16:46:04.987 [17374] dbg: dns: looking up NS records for user
specified domains: gmail.com, yahoo.com, foxnews.com
Apr 14 16:46:04.993 [17374] dbg: dns: attempt 1/1, trying
connect/sendto to
[127.0.0.1]:53
Apr 14 16:46:04.993 [17374] dbg: dns: connect_sock, resolver: yes
Apr 14 16:46:04.998 [17374] dbg: dns: 53959 configured local ports for
DNS
queries
Apr 14 16:46:04.998 [17374] dbg: dns: LocalAddr: [0.0.0.0]:58033, name
server: [127.0.0.1]:53, module IO::Socket::IP
Apr 14 16:46:04.999 [17374] dbg: dns: resolver socket rx buffer size
is
124928 bytes, local port 58033
Apr 14 16:46:05.000 [17374] dbg: dns: providing a callback for id:
44235/IN/NS/yahoo.com
Completely normal DNS asynchronous query setup, query id is 44235
Apr 14 16:46:05.002 [17374] dbg: dns: dns reply 44235 is OK, 0 answer
records
Completely normal DNS reply ("OK") for query id 44235 but with 0 answer
records.
This is what you get when you ask a nameserver for something that it is
not authoritative for and does not have cached without the "recursion
desired" query flag. This is the change which caused bug 7223: Net::DNS
used to always set RD by default, until it stopped doing so in 1.01. The
patch for this is actually so trivial I'll include it here:
--- lib/Mail/SpamAssassin/DnsResolver.pm.orig 2015/07/20
18:23:18 1691991
+++ lib/Mail/SpamAssassin/DnsResolver.pm 2015/07/20 18:24:48 1691992
@@ -592,6 +592,9 @@
};
if ($packet) {
+ # RD flag needs to be set explicitly since Net::DNS 1.01, Bug 7223
+ $packet->header->rd(1);
+
# my $udp_payload_size = $self->{res}->udppacketsize;
my $udp_payload_size = $self->{conf}->{dns_options}->{edns};
if ($udp_payload_size && $udp_payload_size > 512) {
