Score:0

Server

RCVD_IN_DNSWL_BLOCKED in SpamAssassin as it doesn't use local DNS

Andrew Newby

1/24/24, 10:33 AM

I'm not sure what I have wrong here. It used to work on Ubuntu 18.04, but doesn't on 20.04 it seems. I have unbound DNS server setup:

unbound-control status
version: 1.9.4
verbosity: 1
threads: 1
modules: 3 [ subnet validator iterator ]
uptime: 314 seconds
options: reuseport control(ssl)
unbound (pid 1074177) is running...

In /etc/resolv.conf I have:

#domain members.linode.com
#search members.linode.com
#nameserver 212.71.252.5
#nameserver 212.71.253.5
#nameserver 178.79.182.5
#nameserver 176.58.107.5
#nameserver 176.58.116.5
#nameserver 176.58.121.5
#nameserver 151.236.220.5
#nameserver 109.74.192.20
#nameserver 109.74.193.20
#nameserver 109.74.194.20
#options rotate

nameserver 127.0.0.1
options edns0
search members.linode.com

In /etc/spamassassin/local.cf I have:

dns_server 127.0.0.1

I have rebooted the server, yet it seems

0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See DnsBlocklists for more information. [209.85.218.53 listed in list.dnswl.org]

Am I missing something?

A bit more details on what the server is setting:

systemd-resolve --status
Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 127.0.0.1
         DNS Servers: 127.0.0.1
          DNS Domain: members.linode.com
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (eth0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 176.58.107.5
         DNS Servers: 176.58.107.5
                      212.71.253.5
                      151.236.220.5
          DNS Domain: members.linode.com

UPDATE:

As suggested, here is the output of sudo ss -lntp|grep 53:

LISTEN    0         256              127.0.0.1:53               0.0.0.0:*        users:(("unbound",pid=783,fd=6))
LISTEN    0         4096         127.0.0.53%lo:53               0.0.0.0:*        users:(("systemd-resolve",pid=524,fd=13))
LISTEN    0         256              127.0.0.1:8953             0.0.0.0:*        users:(("unbound",pid=783,fd=7))
LISTEN    0         256                  [::1]:53                  [::]:*        users:(("unbound",pid=783,fd=4))

347

1 + 6

spamassassin

unbound

ubuntu-20.04

tripleee

2/2/24, 5:58 AM

Did you read the linked information page? It's slightly unclear, but it does explain the problem. *"Resolving the block might be as simple as using your own non-forwarding caching nameserver to avoid being lumped together with other users queries; setting up your own mirror of the DNS-blocklist; or paying to use the blocklist."*

Andrew Newby

2/2/24, 8:57 AM

@tripleee yes, I'm using Unbound ( https://www.atlantic.net/vps-hosting/how-to-set-up-unbound-dns-resolver-on-ubuntu-20-04/ ), so it *should* be using that when making the requests - but it doesn't seem to be

tripleee

2/2/24, 9:47 AM

Your ISP could still be NATting your traffic so it looks like it comes from them, or etc. What you have configured locally doesn't really reveal anything about what traffic the DNSBL is seeing.

Andrew Newby

2/2/24, 1:55 PM

@tripleee any ideas on how to test that theory? On https://www.dnswl.org/?p=152 it suggests testing: `dig -t txt amiblocked.dnswl.org`. For the result I get: `amiblocked.dnswl.org. 185 IN TXT "no"` and the query section: `SERVER: 127.0.0.1#53(127.0.0.1)`

tripleee

2/2/24, 1:57 PM

That's looking good per se. Did you execute this from the server where you have SpamAssassin running?

Andrew Newby

2/2/24, 2:09 PM

@tripleee yes :) The frustrating part is that sometimes we get the error, sometimes we don't. /etc/resolv.conf only has the local nameserver set: `nameserver 127.0.0.1` vs the original one on the server: `nameserver 127.0.0.53`. I've just updated my question with the output of `systemd-resolve --status`

Score:1

Server

Jacob Geigle

2/4/24, 10:06 PM

Edit: As stated here-> https://www.linode.com/community/questions/21413/rcvd_in_dnswl_hi-false-positives It's known that linode users are having this issue. It looks as though your DNS queries are getting forwarded through linode's resolvers, which are blocked because so many users all funnel through them. Based on this output from systemd-resolve --status:

     DNS Servers: 176.58.107.5
                  212.71.253.5
                  151.236.220.5

I would double check that unbound is indeed running-> sudo ss -lntp|grep 53 Double check it's configuration to be a recursive server, and set systemd-resolve to query it as it's upstream. systemd-resolve --set-dns=SERVER or vim /etc/systemd/resolved.conf

+ 1

Andrew Newby

2/5/24, 7:37 AM

Thanks -but its using the local DNS server: `DNS Servers: 127.0.0.1`, which is unbound. I've added comments in the opening post for your port 53 test (too much to post in a comment)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: RCVD_IN_DNSWL_BLOCKED in SpamAssassin as it doesn't use local DNS

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.