DEV Community

Cover image for Is Your IPv4 Block Blacklisted? Checking a /24 the DNSBL Way
Artem Kohanevich
Artem Kohanevich

Posted on

Is Your IPv4 Block Blacklisted? Checking a /24 the DNSBL Way

#security #devops #infrastructure

If you own or lease IPv4 space, the reputation of your addresses is part of the asset. A block that's quietly listed on a major DNSBL doesn't deliver mail, fails the health checks renters run before they sign, and loses value on resale - and nothing proactively tells you it happened.

Pasting one IP into a web form is fine for a spot check. If you're responsible for a whole block, here's how to actually query the reputation data and sweep a /24.

How a DNSBL lookup works

A DNSBL (DNS-based blocklist, aka RBL) answers reputation queries over DNS. You reverse the octets of the IP, append the zone, and do an A lookup. A 127.0.0.x answer means listed; NXDOMAIN means clean.

# 203.0.113.5  ->  5.113.0.203
dig +short 5.113.0.203.zen.spamhaus.org
# 127.0.0.x      = listed (the code tells you which list)
# empty/NXDOMAIN = not listed
Enter fullscreen mode Exit fullscreen mode

For Spamhaus ZEN (their combined zone: SBL + CSS + XBL + PBL), the return code tells you which list you're on:

Return code List Meaning
127.0.0.2 SBL Manually listed spam/abuse source
127.0.0.3 SBL CSS Auto-detected low-reputation sender
127.0.0.4 - .7 XBL Compromised host / open proxy / botnet (the old CBL data lives here now)
127.0.0.9 SBL DROP/EDROP - hijacked or fully malicious range
127.0.0.10 / .11 PBL Range that shouldn't send mail directly (often normal)

One gotcha that trips people up: Spamhaus's free public mirrors block queries coming from public/open resolvers like 8.8.8.8 and 1.1.1.1, and return an error code in the 127.255.255.x range instead of real data. Run your checks through your own resolver, or grab a free Data Query Service (DQS) key and query the DQS zone. If you dig through Google's resolver and get a strange answer, that's why.

Sweeping a whole /24

Once the query format makes sense, looping over the host range is trivial:

# Sweep 203.0.113.0/24 against Spamhaus ZEN
for i in $(seq 1 254); do
  ans=$(dig +short "$i.113.0.203.zen.spamhaus.org")
  [ -n "$ans" ] && echo "203.0.113.$i -> $ans"
done
Enter fullscreen mode Exit fullscreen mode

(Same resolver caveat applies - for a real sweep, point it at a resolver that isn't a public mirror.)

AbuseIPDB for aggregate scoring

Spamhaus tells you listed/not-listed. AbuseIPDB gives you a crowdsourced confidence score (0-100) per address, and its check-block endpoint scores a whole subnet in one call:

curl -G https://api.abuseipdb.com/api/v2/check-block \
  --data-urlencode "network=203.0.113.0/24" \
  -d maxAgeInDays=90 \
  -H "Key: $ABUSEIPDB_KEY" \
  -H "Accept: application/json"
Enter fullscreen mode Exit fullscreen mode

The response lists every reported address in the block with its abuseConfidenceScore. AbuseIPDB treats anything under 25 as noise; 75-100 is the range you'd actually block on. The free tier is 1,000 checks/day, and check-block is capped at /24 - for a larger block, iterate over its /24s or use a paid tier.

What to do with a hit

Two rules:

  1. Fix the root cause before you request removal. Delisting while the open relay, compromised host, or spam source is still live just gets you relisted - sometimes with self-service removal disabled the next time.
  2. Never pay for delisting. It's free everywhere. The return code points you at the path: SBL needs the owner-of-record or ISP to contact Spamhaus; XBL/CSS is self-service via check.spamhaus.org; AbuseIPDB decays over time or you dispute; Barracuda has a manual removal form. Timelines run from minutes (PBL) to weeks (AbuseIPDB decay).

While you're in there, confirm the boring hygiene that keeps a block off lists in the first place: clean, consistent rDNS, valid RPKI/ROA so the origin checks out, and an abuse@ address that someone actually reads.

The part the sweep doesn't solve

A sweep is a point-in-time snapshot. It tells you the block is clean now. The moment you lease it out, reputation becomes a function of what your renter does - and a single compromised host or one spam run can list addresses within hours.

Keeping a leased block clean is therefore continuous, not a one-off: screen who you hand a block to, watch abuse signals in real time, and de-provision fast enough that a listing never takes hold. That's most of the operational reason we built IPbnb the way we did - when a block is leased through the marketplace, that screening and monitoring runs in the background instead of landing on the owner. It won't scrub an existing listing, and no setup makes a block un-flaggable, but it keeps the day-to-day abuse-watching automated while the block earns.

Either way: before you lease or sell a block, sweep it. It's a few minutes of dig and one API call.

Full guide - every tool, return code, and delisting path by database: https://ipbnb.com/blog/ip-abuse-check-ipv4-blacklisted

Top comments (0)