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.1Empty 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.