Google’s Public DNS Says the Blocklist Test Address Doesn’t Exist
Every IPv4 blocklist has to list 127.0.0.2. This morning Google answered “no such name” for it on Spamhaus, Cloudflare answered with an error code, and the fallback path in my own IP checker would read Google’s answer as “not listed”.
DNS blocklists have a built-in self-test. RFC 5782, the 2010 document that describes how they work, says it plainly: “IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.” It also says they “MUST NOT contain an entry for 127.0.0.1.”
So the test is the same for every list. Ask the list about 127.0.0.2 and you should get an answer back, normally 127.0.0.2 itself. Ask about 127.0.0.1 and you should get nothing. If 127.0.0.2 comes back empty, your lookups aren’t working, whatever the list says about any real address.
This morning, at 07:23 UTC, I asked Spamhaus’s ZEN list about 127.0.0.2 through Google’s and Cloudflare’s public resolvers. They gave me two different wrong answers.
What Google and Cloudflare sent back
A blocklist query is an ordinary DNS lookup. You reverse the address and put the list’s zone after it, so the test query for ZEN is 2.0.0.127.zen.spamhaus.org. I sent it to Google Public DNS and to Cloudflare's 1.1.1.1 through their JSON lookup pages, which return the raw answer.
Google returned status 3, which is NXDOMAIN: the name does not exist. The authority section came from Spamhaus’s own zone, with hostmaster.spamhaus.org in it, so this wasn't Google failing to reach Spamhaus. The query got there and came back with "no such name". I got the same result for 2.0.0.127.sbl.spamhaus.org, Spamhaus's SBL zone.
Cloudflare returned an answer: 127.255.255.254. Then I asked Cloudflare about 127.0.0.1, the address no list is allowed to contain. Same answer, 127.255.255.254.
Why the two answers fail differently
Cloudflare’s answer is documented. In a February 2021 post, Spamhaus listed the codes its public mirrors return when they won’t answer a query. 127.255.255.254 means "Query via public/open resolver/generic rDNS". The same post is clear about what those codes are: "none of these return codes relate to the reputation of the query – they are error codes."
A January 2022 Spamhaus post explains the reason for Cloudflare in particular. Spamhaus’s free mirrors are for small, non-commercial use, and Spamhaus monitors usage against its terms. In Spamhaus’s words, “Cloudflare masks organizations’ queries to the Project’s Public Mirrors”, so Spamhaus can’t tell who is asking or how much. It began returning the error code across Cloudflare’s address space from 15 February 2022.
The danger with the Cloudflare answer is that it looks like a listing. A blocklist that lists an address answers with a 127.x.x.x address, and so does this error. Mail software that doesn’t recognise the code can count it as a hit, and since Cloudflare gave it for 127.0.0.1 too, every sender would be listed. Spamhaus warned about exactly this: “serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists.”
At least that failure is loud. Rejected mail produces bounces, and people see bounces.
Google’s answer is the quiet one. NXDOMAIN is exactly what a blocklist returns for an address it doesn’t list. A mail server that gets NXDOMAIN for a real sender’s address has no way to tell “not listed” from “not answered”. Nothing in the answer looks like an error. The blocklist check is effectively switched off, and nothing reports it.
Get Josepollman’s stories in your inbox
Join Medium for free to get updates from this writer.
I read two Spamhaus pages this morning, and neither describes what Google’s resolver gets back. Google may be getting a different treatment from Cloudflare for its own reasons, and that could change. What I can say is what came back today, for the test address, through both resolvers.
The test is one line
If you run a mail server, or a monitoring script, or anything else that checks Spamhaus, run this from the machine that does the checking, using whatever resolver that machine actually uses:
dig +short 2.0.0.127.zen.spamhaus.org
The answer should include 127.0.0.2. If you get nothing at all, or anything starting with 127.255.255, your blocklist lookups are not working and every “clean” result from that machine means nothing.
Why it matters which machine: the resolver your laptop uses tells you nothing about the one your server uses, and a server can end up on a public resolver without anyone choosing it. Spamhaus’s own advice is either to query from a dedicated address with proper forward and reverse DNS, or to switch to its free Data Query Service, which uses a registered key.
Then I read my own code
I build notspoofed.com, a set of free email authentication tools. One of them is a sending-IP checker that looks an address up on eight blocklists, Spamhaus ZEN first. The source is public, so after the Google result I opened it to see which of these two failures it could fall into.
The file that lists the blocklists says every zone in it “was verified to answer correctly for 127.0.0.2" and "to stay silent for 127.0.0.1". There's a function that treats anything starting with 127.255.255 as a refusal, not a listing, and the result page shows that list as "unknown". The page says so in plain words: "It is not the same as 'not listed', and we do not report it as such." So the Cloudflare failure is handled. When I ran the checker on Google's own address, 8.8.8.8, this morning, one list, Barracuda, failed to answer, and the page reported it as unknown, not clean.
The code also expects its own recursive resolver, so Spamhaus sees a real, attributable server instead of a public one. A comment in the file explains why: public resolvers get the refusal code, and that “silently removes the two most important blocklists from the results.”
But the same file keeps two public resolvers as backups behind it, 1.1.1.1 and then 8.8.8.8, so that “a dead Unbound” (the resolver software) “degrades the blocklist checks rather than taking the whole site down.” And the blocklist code reads an empty answer as clean. NXDOMAIN is an empty answer.
Put those together and there’s a path to the quiet failure. If the checker’s own resolver and 1.1.1.1 were both out of reach, the query would go to Google, Google would say the name doesn’t exist, and my tool would show Spamhaus ZEN as “not listed”. That’s the false all-clear the tool’s own comments say it is built to avoid. It needs two things to fail first, so it isn’t likely. But it’s possible, and nothing on the page would show it.
There’s a second, smaller problem. You can’t run the RFC test through the tool yourself. Enter 127.0.0.2 and it refuses: “127.0.0.2 is a private or reserved address, so it cannot be a public sending IP.” That’s true of sending IPs, and it means the one input that proves the lookups work is the one the form won’t take.
What the check should do instead
The verification the file describes was done when the list was written, and as far as I can see in the code, it isn’t repeated when a check runs. The fix is to do it on every check: before trusting a “not listed” from a blocklist, ask the same list about 127.0.0.2 through the same resolver. If that doesn’t come back listed, report the list as unknown for this check, whatever the reason. It costs one extra query per list, and the result can be cached for a few minutes.
It’s the same test as the dig line above, run by the software instead of by a person who remembers to. A blocklist that can’t find its own test entry isn’t telling you anything about your sender, and the check should say so instead of showing a green row.
If you want to see how your own sending address looks on the major lists, with refusals shown as unknown, the checker is at notspoofed.com/ip. Run the dig line from your own server too. They test different machines.
Sources: RFC 5782, section 5 (rfc-editor.org). Spamhaus, “Using our public mirrors? Check your return codes now”, 11 February 2021. Spamhaus, “If you query the legacy DNSBLs via Cloudflare’s DNS move to Spamhaus Technology’s free Data Query Service”, 17 January 2022. Resolver answers from dns.google and cloudflare-dns.com, 26 October 2026, 07:23 UTC.
