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

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:

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

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:

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:

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:

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