Bill Cole wrote: > 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) {
Good call, the attached patch fixed . Drove me nuts, thanks Rick
