Loading today’s stories
Build1 distinct publisher2 min readPublished
Blocklists answer as DNS zones, and the big ones reply to public-resolver lookups with a 127.255.255.254 refusal that naive free tools read as a hit.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The arithmetic explains why this bug survives code review. An answer inside 127.0.0.0/8 means listed [4], and that range holds 16,777,216 addresses, of which the 127.255.255.0/24 refusal block accounts for 256, roughly 0.0015 percent of the space [15]. A range check on 127/8 is correct about nearly all of it and wrong about the specific answer Spamhaus reserves for callers arriving through a public resolver [8].
The refusal code carries information about the asker, not about the IP under test. Spamhaus's 127.255.255.254 documents as "query via public/open resolver" [8], which is a statement about the resolver that delivered the question, and according to the Merlonix write-up republished on dev.to [17] the lists behave this way because their data feeds are paid and they will not serve free bulk lookups riding in on a public resolver's IP [7]. Browser-based tools and serverless functions egress DNS that way, as do most cloud runtimes [9]. The stakes are what make the misread expensive: a single listing on a heavily consulted list can quietly kill a large share of mail, including password resets and receipts [2], so "you are on Spamhaus" gets acted on before anyone inspects the octets [10].
A verdict assembled from a public vantage point is a verdict about the lists that actually replied, and nothing more. SpamCop, PSBL and Mailspike are among those that do answer such queries for real [13]. The rule the source proposes is to report listed only when a genuine code came back, clean only when at least one list gave a definitive answer and nothing was listed, and inconclusive when every lookup errored or was blocked [12]. A tool that renders a clean result next to Spamhaus while querying from 8.8.8.8 is asserting something it never received an answer to [6].
There is a cheap way to know which case you are in. The documented test entries are the check: 127.0.0.2 should come back listed and 127.0.0.1 should come back NXDOMAIN, and if both look the same, the list is not really answering you [14]. Two lookups settle whether the vantage point is usable before any per-list result is worth reading. Skipping them shifts the cost onto the sender, because the lookups that decide whether mail is rejected or filed to spam happen in real time at the receiving server [1], and paperwork filed against a listing that was never issued does not change what those lookups return [11].
Ranked by verification strength, evidence, and original report placement.
Mail servers consult DNS blocklists in real time; if the connecting IP is listed, the message is usually rejected outright or filed to spam.
A single listing on a widely consulted list such as Spamhaus, SpamCop, Barracuda or UCEPROTECT can quietly kill a large share of a sender's mail, including transactional mail such as password resets, receipts and alerts.
A DNSBL is not an API but a specially shaped DNS zone: to ask whether 192.0.2.10 is listed on bl.spamcop.net you reverse the octets, append the zone and resolve an A record for 10.2.0.192.bl.spamcop.net.
An A-record answer inside 127.0.0.0/8 means listed, and the exact 127.0.0.x value is a reason code indicating which sub-list and why.
NXDOMAIN means not listed and is a definitive clean answer, while a timeout or SERVFAIL means inconclusive, which is not the same as clean.
Several of the largest blocklists refuse queries that arrive through a big shared or public resolver such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8; Spamhaus and Barracuda both do this.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and checkable, but single-source and self-published
One publisher (a dev.to republication of the author's own blog) carries the entire cluster. The technical core is unusually concrete for a single source — named zones, the reversed-octet query form, the 127.255.255.0/24 sentinel and the documented 127.255.255.254 meaning, plus a probe/canary test anyone can reproduce — which raises evidentiary value above bare assertion. But nothing is corroborated by list operators, RFCs, tool audits or independent measurement, and the motive claim behind refusals is unsupported.
No adoption signal supplied
The cluster contains no release, deployment, benchmark, usage-disclosure, pricing or incident data. The source names blocklists and tool categories but provides no counts of affected checkers, no query volumes and no user impact measurements, so adoption cannot be scored without inventing facts.
Mechanism sound, prevalence rhetoric slightly ahead of evidence
The central technical claim is modestly framed and reproducible, so this is closer to a debunking piece than a hype piece. The mild overstatement is in scope rather than mechanism: 'almost no free blacklist check page tells you' and the implied ubiquity of naive 127.x handling are unquantified, and the piece resolves toward the author's own checker as the honest alternative without showing it was tested against the failure mode.
Vendor-authored explainer that ends at its own product
The single source is a company blog post republished under the company's dev.to handle, and it closes by describing that company's free blacklist/DNSBL checker — a direct commercial interest in convincing readers that rival free checkers return false positives. A second incentive layer is described within the story itself: the refusing blocklists are said to monetise paid data feeds, giving them reason to withhold answers from free public-resolver lookups. No independent publisher is present to offset either incentive.
Moderate on mechanics, low on scope
Confidence is held up by the reproducibility of the protocol claims and held down by single-publisher sourcing, a clear vendor incentive, and the complete absence of adoption or prevalence evidence. A reader can trust the described DNS behaviour enough to test it directly; they cannot yet trust claims about how widespread the mishandling is.
build
The server that never sent mail: how an SMTP verifier earned a Spamhaus CSS listing1 distinct publisher
build
SPF and DMARC records that pass every free checker and stop nothing1 distinct publisher
build
A Green Link Report Says Nothing About Whether Your HTTPS Page Renders1 distinct publisher
build
Uptime monitoring cannot see the way remote MCP servers actually break1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 24, 2026