DEV Community: zihuama

I sampled 330 IPs from 11 VPS providers. Reverse DNS ranged from 0% to 100%, and the blocklist number needs unpacking.

zihuama — Mon, 28 Sep 2026 10:16:02 +0000

After my last post on cloud provider IP ranges, a few people asked the obvious follow-up: what about the VPS companies you actually buy from?

Fair. Those are the names people agonize over when picking a $20 box. So this round I changed the sample frame: instead of cloud providers' published ranges, I sampled the IPv4 space each provider's AS actually announces.

11 providers, 30 IPs each, 330 total. Same seed (20260928), reproducible.

The method, because this round had more traps than the last one

For the provider → ASN mapping I didn't trust memory. Every row has evidence:

Provider	ASN	Evidence
BandwagonHost	AS25820	their site footer reads "© 2026 IT7 Networks Inc." = the AS holder name
RackNerd	AS36352	`lg-lax03/lg-ny/lg-dal/lg-sea/lg-atl.racknerd.com` all resolve inside this AS
Vultr	AS20473	vultr.com itself resolves there; abuse@constant.com
DigitalOcean	AS14061	abuse@digitalocean.com; also registered in PeeringDB
Linode	AS63949	speedtest.newark.linode.com is in this AS; abuse@linode.com
Hetzner	AS24940	hetzner.com resolves there; abuse@hetzner.com
OVH	AS16276	ovh.com resolves there; abuse@ovh.net
Contabo	AS51167	PeeringDB entry; abuse@contabo.de
Oracle Cloud	AS31898	abuse@oracle* contacts
Alibaba Cloud	AS45102	abuse@alibaba-inc.com
Tencent Cloud	AS132203	abuse@tencent.com

I initially assumed RackNerd sat downstream of MultaCOM (AS35916). Checking their looking glass showed all five regional jump hosts landing in AS36352 ColoCrossing instead. That's exactly why this step gets checked and not remembered.

Sampling: build a /24 candidate pool from each AS's announced prefixes (large prefixes sampled by arithmetic spacing rather than expanded), pick /24s at random, then one random host address inside each.

Then a sanity check on my own work: 330/330 sampled IPs had a BGP origin ASN equal to the target ASN. The sample frame was correct.

Two limitations I have to state up front:

I sampled announced space, not customer machines. It includes blocks not yet handed to anyone. So these reverse-DNS rates are strictly "how much of this AS's space carries rDNS", not "your odds of getting rDNS when you buy".
/24 is an approximation of the granularity customers actually get, not the real thing.

Four measurements: reverse DNS (PTR), eight public blocklists (all.s5h.net, bl.spamcop.net, dnsbl-1.uceprotect.net, dnsbl.dronebl.org, dnsbl.spfbl.net, hostkarma.junkemailfilter.com, psbl.surriel.com, bl.blocklist.de), RDAP registration, and BGP origin from RIPEstat. zen.spamhaus.org is again excluded — it refuses queries from public resolvers.

Finding 1: default reverse DNS is a policy choice, not a probability

Provider	Sample	Has PTR	PTR rate
BandwagonHost	30	30	100%
Hetzner	30	29	96.7%
Contabo	30	29	96.7%
RackNerd	30	23	76.7%
Vultr	30	18	60%
Linode	30	16	53.3%
OVH	30	11	36.7%
Oracle Cloud	30	4	13.3%
DigitalOcean	30	3	10%
Alibaba Cloud	30	0	0%
Tencent Cloud	30	0	0%

163 of 330 have rDNS — 49.4% overall.

But the percentage isn't the interesting part. The naming is:

All 30 BandwagonHost IPs are X.Y.Z.W.16clouds.com. Every single one — 16clouds is IT7's own brand.
24 of Contabo's 29 are vmiNNNNNNN.contaboserver.net / contabo.net; five are customer-overridden.
25 of Hetzner's 29 are static.X.Y.Z.W.clients.your-server.de.
And DigitalOcean's three? hub.operio.work, dev.sightmap.com, mail.sndb.se — customer domains, none of them DigitalOcean's own. DO doesn't set rDNS by default; those three are user-configured.

One group says "we template the whole space"; the other says "if the customer doesn't set it, there isn't one." Two deliberate policies, not luck.

The practical takeaway: if you want reverse DNS for mail, don't expect the provider to hand it to you. Set it in the control panel yourself, with your own domain. BandwagonHost-style blanket coverage is rare, and what you get is their template, not yours.

Finding 2: the blocklist number is misleading until you unpack it

40 of 330 hit at least one list — 12.1%. By provider:

Provider	Hits	Which lists
RackNerd	24/30	`dnsbl.spfbl.net` ×24, `all.s5h.net` ×1
Tencent Cloud	5/30	`dnsbl.spfbl.net` ×5
DigitalOcean	4/30	`dnsbl.spfbl.net` ×3, `all.s5h.net` ×1, `dnsbl.dronebl.org` ×1
Vultr	2/30	`dnsbl.spfbl.net` ×2
Oracle Cloud	2/30	`hostkarma.junkemailfilter.com` ×1, `all.s5h.net` ×1
BandwagonHost / Hetzner	1/30 each	`dnsbl.spfbl.net`
Alibaba Cloud	1/30	`dnsbl.dronebl.org`
Linode / OVH / Contabo	0/30	—

RackNerd: 24/30. Ugly, right?

Then I looked at where those 24 sit: 24 hits spread across 24 different /24 blocks, one each. Suspiciously even. And 36 of the 40 total hits across all providers come from a single list, dnsbl.spfbl.net.

That pattern doesn't describe 24 spammy machines. It describes a list making a blanket judgement about AS36352's space — wherever you sample, it's listed. That's a property of the list's policy, not of individual hosts. Whether the policy is defensible is not something I can determine from outside.

So "80% listed" and "ColoCrossing is dirty" are separated by one unpacking step. In my previous post, 12 of the 13 hits were also spfbl — same structure.

One inverse observation: Tencent Cloud has 0% reverse DNS but 5/30 listed. No rDNS plus a listing is the combination that actually hurts.

Finding 3: the PTR name, the registrant, and the announcer can be three different companies

Three concrete IPs from the sample:

173.44.54.180    BGP origin AS20473 (Vultr)
                 RDAP registrant = West Coast Internet Provider LLC (block name CC-173-44-54-0-24)
                 PTR = unassigned.quadranet.com

198.20.246.214   BGP origin AS31898 (Oracle)
                 RDAP registrant = HostGator.com LLC (netname HGBLOCK-7)
                 PTR = 198-20-246-214.unifiedlayer.com

204.44.82.41     BGP origin AS36352 (RackNerd/ColoCrossing)
                 PTR = 204.44.82.41.static.quadranet.com

Three names, three different companies. Six of my 330 sample IPs have rDNS pointing at a third-party datacenter domain (quadranet.com shows up once in RackNerd's sample and once in Vultr's; unifiedlayer.com and hostgator.com.br show up in Oracle's space).

The most reasonable explanation is stale rDNS from a previous owner — unassigned.quadranet.com says as much in the name. I can't prove from outside that a customer didn't set it. But one conclusion holds, and it matters more than any number above:

PTR is not ownership evidence. Anyone deciding "whose IP is this" from the reverse name would get burned by this data.

Finding 4: you buy from the brand, someone else holds the addresses

The RDAP registrant distribution says a lot. Within a single provider's 30 sampled IPs:

Provider	Registrant distribution
RackNerd	HostPapa ×16, RackNerd LLC ×9, GCHAO LLC ×1, no registrant ×1
Contabo	MNT-CONTABO ×25, Cogent Communications, LLC ×2, LRTC-MNT ×2
Oracle Cloud	Oracle Corporation ×17, HostGator.com LLC ×2, ORCL-MNT ×7
Vultr	Vultr Holdings ×9, The Constant Company ×3, VULTR-MEXICO ×2, no registrant ×4
BandwagonHost	IT7 Networks Inc ×24, Cluster Logic Inc ×4, Fiber Logic Inc. ×1
DigitalOcean	DigitalOcean, LLC ×28, digitalocean ×2
Linode	Linode ×25, Akamai Technologies ×1, linode-mnt ×4
OVH	OVH SAS ×12, OVH Hosting ×4, OVH-MNT ×2, netutils-mnt ×3
Alibaba Cloud	Alibaba Cloud (Singapore) ×12, Alibaba Cloud LLC ×9, Alibaba Cloud HK ×5
Tencent Cloud	27/30 have no registrant entity (APNIC objects carry IRT/technical contacts with individual names)

Look at RackNerd again: 16 blocks registered to HostPapa, only 9 to RackNerd LLC — consistent with the BGP layer, where AS36352's holder is HostPapa's ColoCrossing.

Not a defect. It's how this business works: small providers rent rack space and address space, and handle sales and support themselves. Two practical consequences:

The abuse escalation path is one layer longer. Before disputing a misclassified IP, check RDAP to see whether the abuse contact is the provider or the upstream datacenter.
Who held this block previously shapes its reputation. The Oracle space still carrying HostGator registrations is the live example: they didn't acquire a clean block, they acquired a block with history.

Tencent's 27 unparsed records turned out to have no registrant entity at all — APNIC-style objects list administrative/technical contacts with individual people's names (James Tian, Jimmy Xiao). Abuse lookup goes through the IRT object. I can only record the structure; I can't verify the names.

One metric I threw away

I had computed "share of IPs whose RDAP discloses an abuse role" and got 330/330 — 100%.

Too clean. I rechecked ten of them with a strict test: 0/10.

The gap: my first check was "does the string abuse appear anywhere in the JSON". It does — in remarks, in email addresses, in IRT reference names. It does not mean "an entity is labelled with the abuse role". The number was fabricated by my own parser, so the metric is gone.

I'm keeping this in the post because it's the failure mode most likely to slip through in work like this: when a ratio comes out exactly 100% or exactly 0%, suspect your check before you write your conclusion.

What I did not measure

Actual mail delivery. No blocklist hit proves mail bounces; no clean result proves inbox placement. That needs a live send test — a different post.
Real machine experience. I sampled announced space, not the box in your hands. Blocks differ by datacenter and batch.
zen.spamhaus.org. No data this round either. It's one of the highest-weighted lists in mail filtering, so its absence leaves a genuine gap — I won't pad it with other lists and pretend it's covered.

The 330 raw records and the sampler are public: data vps-audit-2026-09.json (CC BY 4.0). The sampler and the same dataset are on GitHub: mazihua-lgtm/vps-ip-audit-2026-09. The seed is in the script; re-running reproduces the same sample.

I normally run these checks in my own tool: pureip.app/ip — IP reputation lookup with PTR, blocklists, ASN and registration on one page. This 330-IP sample is a byproduct of it.

Disclosure: I build and maintain pureip.app, an IP lookup and network diagnostics toolbox — these 330 records are a byproduct of it. The data is real and the tool is mine; saying so up front seemed better than letting you find out.

I checked 288 cloud provider IPs against public records. A few numbers surprised me.

zihuama — Mon, 28 Sep 2026 09:55:56 +0000

Someone asked me to pick a VPS for them and then asked the obvious question: is this IP clean? I didn't know, so I looked it up. And while looking, I noticed something: everyone publishes how to check one IP, nobody publishes what the distribution actually looks like when you grab a bunch of IPs at random from AWS, GCP and Cloudflare ranges.

So I grabbed a bunch. 288 IPs, all sampled from the ranges the providers publish themselves (AWS ip-ranges.json filtered to service=EC2, GCP cloud.json, Cloudflare ips-v4), randomized per region, seed hardcoded in the script so anyone can reproduce the exact same list.

Four things measured, all from public sources, no accounts, no API keys: reverse DNS (PTR), eight public mail blocklists, who actually announces the IP in BGP, and the RDAP registration record.

1. Reverse DNS: three providers, three completely different attitudes

Group	Sample	Has PTR
GCP us-central1	50	100%
GCP asia-southeast1	43	100%
GCP asia-east1	30	100%
AWS ap-northeast-1	50	52%
AWS ap-southeast-1	50	48%
AWS us-east-1	50	42%
Cloudflare	15	6.7%

All 123 GCP IPs had one, uniformly formatted as xxx.xxx.xxx.xxx.bc.googleusercontent.com.

About half of AWS did, looking like ec2-15-181-82-64.compute-1.amazonaws.com. The rest are customer-configured — I hit EC2 addresses whose PTR points at nywebpage.net, mrsparkman.com, panoag.com, and one where somebody set it to ip-99-77-244-82.ec2.ap-northeast-1.vc.chime.aws.

Of the 15 Cloudflare IPs, exactly one had a PTR, and it was gina.ns.cloudflare.com — an anycast authoritative DNS node. Fifteen samples is too few to call it a conclusion, but the intent is pretty clear: those ranges are for proxying and origin pull, not for hosting.

Why this matters in practice: Google's bulk sender guidelines require sending domains or IPs to have valid forward and reverse DNS. Microsoft is blunter — mail from an IP with no PTR frequently just gets refused. If you're sending from an IP with no reverse DNS, getting blocked isn't bad luck.

2. 4.5% hit a blocklist, and nearly all of them on the same list

13 of 288 IPs showed up on at least one list — 4.5%. Twelve of those were on dnsbl.spfbl.net, one on all.s5h.net.

By group: 3 in AWS Singapore, 5 across the three GCP regions, 5 in Cloudflare (5 of 15, 33% — again, small sample).

One limitation I have to state: Spamhaus' zen refuses queries from public resolvers, so I could not query it over DoH at all. The most authoritative list is therefore not in these numbers. The real hit rate can only be higher than 4.5%.

My read: the big providers' ranges are mostly clean. 4.5% means "I bought a cloud IP and it turned out to be blocklisted" is not the norm. If you do get listed, it's usually your own doing — bulk mail, an open proxy someone scanned, a crawler that got you reported.

3. Some IPs inside cloud ranges belong to somebody else

RIPEstat found a BGP announcement for 96.5% of the IPs. The ones it couldn't find were concentrated in AWS us-east-1 — most likely because AWS announces at a coarser granularity than the /24 I queried and RIPEstat aligns the result to a less-specific prefix. That does not mean the range is unannounced.

The interesting ones are these:

155.146.3.47      AWS us-east-1   → AS6167  Verizon Business
155.146.227.88    AWS us-east-1   → AS6167  Verizon Business
192.157.36.235    AWS us-east-1   → ASN-BYO-DEMO (Amazon's own BYOIP demo)
34.0.225.187      GCP us-central1 → AS43515 YOUTUBE, Google Ireland
35.206.64.222     GCP us-central1 → AS43515 YOUTUBE, Google Ireland

"Inside an AWS published range" does not mean "inside AWS's AS". Once a large customer brings its own IP space (BYOIP), the announcement belongs to them. If your heuristic for IP ownership is the ASN, this is where it breaks.

4. The registration record is not what you think it is

286 of 288 had an RDAP handle and 285 disclosed an abuse role — essentially all of them. Registrants were entirely these:

Google LLC                          123
Amazon.com, Inc.                     59
Amazon Technologies Inc.             37
Amazon Data Services Northern Va.    24
Amazon Data Services Japan           12
Amazon Data Services Singapore        8
Cloudflare, Inc.                      7

A lot of people read the RDAP country field as "where this IP is located". It isn't. It's where the registrant registered. The AWS Japan ranges say Amazon Data Services Japan, which at least tracks reality; check a small European host and RDAP will usually just hand you the registrant's headquarters address.

Do not judge location from registration data alone.

Data and method

Sample: 288 IPs. AWS 150 (us-east-1 / ap-northeast-1 / ap-southeast-1, 50 each), GCP 123 (us-central1 50, asia-southeast1 43, asia-east1 30), Cloudflare 15
Sampling: random within the published ranges, per region, seed 20260928
PTR and blocklists: queried over DoH (dns.google) against <reversed-ip>.in-addr.arpa and eight lists; six samples re-checked against Cloudflare DoH, all matching
Blocklists were self-tested first: queried each with the guaranteed-hit address 127.0.0.2 and kept only those that actually answer. Final eight: all.s5h.net, dnsbl-1.uceprotect.net, bl.spamcop.net, dnsbl.dronebl.org, dnsbl.spfbl.net, hostkarma.junkemailfilter.com, psbl.surriel.com, bl.blocklist.de (zen.spamhaus.org refuses public resolvers and was dropped)
BGP: RIPEstat prefix-overview
Registration: RDAP (rdap.org first, then the RIR endpoints directly once it rate-limited me)

Raw 288 records: https://pureip.app/ip-audit-2026-09.json (CC BY 4.0). Data and sampler also on GitHub: https://github.com/mazihua-lgtm/ip-audit-2026-09 — reproducible, corrections welcome, mail agent@pureip.app if you want another provider's ranges covered (Alibaba Cloud, Oracle, Vultr).

One thing I did not measure

This post does not tell you which IPs can access ChatGPT or Claude. Not because I'm holding back — I don't have a method I can publish and have anyone reproduce, since it depends on each vendor's own risk controls. A number I can't reproduce is worse than no number.

What the public data does tell you: whether an IP has reverse DNS, whether it's on a blocklist, who actually announces it, and who registered it. The rest is your call.

Disclosure: I build and maintain pureip.app, an IP lookup and network diagnostics toolbox — these 288 records are a byproduct of it. The data is real and the tool is mine; saying so up front seemed better than letting you find out.