I sampled 360 IPs from 12 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: fine, but which VPS provider should I actually buy from? Those are the names people agonise over when picking a $20 box.
Fair. So this round sampled the providers people actually compare — 12 of them, 30 IPs each, 360 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:
- The announced prefix came from each AS's actual BGP announcements via RIPEstat, sampled at /24 granularity. Every IP in the sample really is advertised by that AS — I verified
360/360have a BGP origin ASN equal to the target. - rDNS is a live PTR lookup, not a cache.
- Blocklist status is 8 public DNSBLs.
- RDAP gives the registrant and abuse contacts.
Finding 1: default reverse DNS is a policy choice, not a probability
199 of 360 have rDNS — 55.3% overall. But the per-provider spread is the story:
| Provider | PTR present |
|---|---|
| BandwagonHost | 30/30 |
| DMIT | 29/30 |
| Hetzner | 29/30 |
| Contabo | 28/30 |
| RackNerd | 25/30 |
| OVH | 17/30 |
| Vultr | 16/30 |
| Linode | 14/30 |
| DigitalOcean | 5/30 |
| Oracle Cloud | 5/30 |
| Tencent Cloud | 1/30 |
| Alibaba Cloud | 0/30 |
Alibaba Cloud has zero PTR records across the entire sample. BandwagonHost has all 30. If you are planning to send email, that gap is the single most predictive number in this whole dataset — because a missing PTR is treated as a spam signal by most receivers, before any content check runs.
Finding 2: the blocklist number is misleading until you unpack it
47 of 360 hit at least one list — 13.1%. By provider:
| Provider | Blocklist hits |
|---|---|
| Contabo | 0/30 |
| BandwagonHost | 1/30 |
| DigitalOcean | 1/30 |
| Alibaba Cloud | 1/30 |
| Linode | 1/30 |
| Hetzner | 2/30 |
| Vultr | 2/30 |
| Oracle Cloud | 2/30 |
| DMIT | 3/30 |
| OVH | 3/30 |
| Tencent Cloud | 6/30 |
| RackNerd | 25/30 |
Here is the part that needs unpacking. Every single one of the 47 hits is on one list only. And 41 of the 47 — 87% — come from a single list: dnsbl.spfbl.net.
That matters because SPFBL is an aggressive, largely automated listing service with a low bar for inclusion. It is not the same signal as a Spamhaus listing. If I had reported only the headline "13.1% are blacklisted", a reader would picture something far worse than the underlying data supports.
And then there is RackNerd. 25 of 30 IPs listed, all on dnsbl.spfbl.net, spread across 25 different /24 blocks. When the hits scatter across many /24s like that, it is not a few dirty IPs — the whole network is being judged. Moving to another IP in the same range will not help you. At the other end, Contabo is 0/30.
Finding 3: the PTR name, the registrant, and the announcer can be three different companies
A RackNerd IP resolves to something ending quadranet.com. A Vultr IP resolves to constant.com. A handful of Oracle IPs point at unifiedlayer.com. Three names, three different companies.
The interesting ones are the third-party datacenter domains: quadranet.com shows up in RackNerd's sample and in Vultr's. Your reverse DNS can name a facility you have never heard of, run by a company you did not buy from — because the address space was assigned, reassigned, or sits inside a larger block someone else still administers.
Finding 4: you buy from the brand, someone else holds the addresses
RDAP tells you who is on record as holding the block. 235 of 360 — 65% — return no registrant organisation at all. Of the 125 that do return one, every one names the provider you bought from.
So the more common case is not misattribution, it is absence. Two thirds of VPS IPs have no registrant on record. If you have ever run an IP lookup and seen a blank organisation field, that is normal — not a broken query and not evidence the address is suspicious.
One metric I threw away
I had computed "share of IPs whose RDAP discloses an abuse role" and got a suspiciously high number. I rechecked ten of them with a strict test and the number collapsed. The gap: my first check was matching the string "abuse" anywhere in the RDAP payload — 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 fairest example of how this whole exercise can mislead you. Every other number here survived the same scrutiny; this one didn't.
What I did not measure
- A clean blocklist does not mean ChatGPT will load. AI services maintain their own IP reputation that public DNSBLs do not measure. That is a separate test.
- 30 IPs per provider is a sample of the ranges, not a census. A provider with a large network has far more space than 30 addresses can represent.
- Blocklists are dynamic. This snapshot is September 2026.
The 360 raw records and the sampler are public: data vps-audit-2026-09.json (CC BY 4.0), method and per-IP detail at the full audit page.
I built PureIP — an IP lookup and network diagnostics toolbox — these 360 records are a byproduct of it.
Top comments (2)
Finding 1 is the most actionable number here, and it has a precondition worth making explicit: PTR only matters for a box that sends mail directly. A provider that blocks outbound port 25 has removed itself from that axis , deliverability becomes the mail provider's problem, and theirs is the rDNS receivers check.
Worth a column in the next round: which of the twelve block 25 by default. For those, the PTR percentage measures something no customer will ever exercise.
That's the choice we made at Krova Cloud, port 25 blocked, mail out through a provider on 587 or 465. So I can't give you a PTR number and we don't publish one. The honest answer is that the metric doesn't apply, not that we score well on it.
Finding 3 is the one I'd push further. Shared address space means inheriting your neighbours' history, so the question isn't "is this provider clean" but "who else is in this block." Your RackNerd scatter across 25 different /24s is the clearest evidence in the dataset that moving IP within the same range isn't a reset.
Are you planning a round on port 25?
Keeping the abuse-contact metric in the post as the one that didn't survive is a nice touch, and splitting the 13.1% by list is what makes the RackNerd row readable.
One thing about what the sample represents, since the question was "which provider should I buy from". Sampling uniformly over an AS's announced /24s gives you a random address from the provider's whole network, not the address a new VPS customer gets. Big cloud ASNs announce space for load balancers, object storage, NAT gateways and other products alongside VM ranges, and those often have no PTR by design. Alibaba's 0/30 and DigitalOcean's 5/30 could partly be that rather than the VPS default. Spinning up two or three cheapest instances per provider and checking the PTR on the address you're actually assigned would separate "this provider doesn't set rDNS" from "most of this AS isn't customer VMs".
On the middle of the PTR table: with 30 per provider, OVH at 17/30 has a 95% interval of roughly 39% to 73%, and Linode at 14/30 roughly 30% to 64%, so OVH, Vultr and Linode aren't really distinguishable. The extremes (30/30, 0/30) are solid; the ordering in between is mostly noise.