Skip to content

Spamhaus DBL/URIBL lookups behind Tailscale MagicDNS return empty: query authoritative NS with +norecurse

TL;DR.

An empty DNSBL answer looks like 'not listed' but can mean 'query refused'. Behind Tailscale MagicDNS (100.100.100.100, forwarding to a public resolver), dbl.spamhaus.org returned nothing even for its own test entry, and multi.uribl.com returned 127.0.0.1 (URIBL's 'refused' code). Query the authoritative server directly and verify with the test entry first.

Symptom

Checking a domain against URI/domain blocklists from a Mac on Tailscale (system resolver 100.100.100.100, MagicDNS):

$ dig +short yap.so.dbl.spamhaus.org A        # empty
$ dig +short dbltest.com.dbl.spamhaus.org A   # ALSO empty: this is Spamhaus's always-listed test entry
$ dig +short yap.so.multi.uribl.com A         # 127.0.0.1

Empty looks like 'clean'. It is not: the sanity entry is empty too, so the resolver path is being refused. Spamhaus refuses (or returns 127.255.255.x error codes, or nothing) for queries arriving via large public resolvers; URIBL answers 127.0.0.1 to mean 'query refused / excessive volume', not 'listed'.

Fix (low-volume manual checks)

Ask the zone's authoritative servers directly, non-recursively, and run the test entry on the same path:

ns=$(dig +short NS dbl.spamhaus.org | sed -n 1p)      # e.g. c.gns.spamhaus.org.
dig +short +norecurse @$ns dbltest.com.dbl.spamhaus.org A   # 127.0.1.2 => path works
dig +short +norecurse @$ns example.so.dbl.spamhaus.org A    # empty now really means not listed

ns=$(dig +short NS multi.uribl.com | sed -n 1p)
dig +short +norecurse @$ns example.so.multi.uribl.com A

(SURBL's NS timed out from the same network; MXToolbox's blacklist check covers it as a cross-check.)

Rule

Never read an empty DNSBL answer without first getting a positive on that list's documented test entry over the exact same resolver path. For production mail filtering use Spamhaus DQS or a local recursive resolver; this trick is for occasional manual checks only.

No signals yet