Whitelists: What They Are, Why They Change, and What Splitting Them Means

A whitelist lists addresses, not services. That is why subnet neighbours inherit its protection — and why splitting those addresses into separate subnets changes so much.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#whitelist#network#regulation

Whitelists: What They Are, Why They Change, and What Splitting Them Means

When restrictions tighten, some services keep working. Not because they went unnoticed, but because they are on a whitelist — a set of addresses to which restrictions are not applied. How those lists work explains why some services survive a tightening, and why neighbours sharing an address inherit protection nobody ever granted them.

The mechanism looks simple: a list of what is permitted, everything else restricted. In practice it has one property that determines a great deal — and that property is what is now being changed.

A list of what, exactly?#

The point most often misunderstood: a whitelist operates on IP addresses and subnets, not on service names. That distinction decides almost everything that follows.

The distinction matters because addresses are handed out by hosting providers in blocks. A provider receives a range and assigns addresses from it to its customers — all of them, without regard for which ones are on the whitelist and which are not.

provider subnet
├── an approved resource   ← the reason this subnet is whitelisted
├── an online shop         ← inherits the protection
├── somebody's blog        ← inherits the protection
└── anything else          ← inherits the protection

So being on a whitelist is a property of adjacency, not a property of the service. The list’s granularity is coarser than the granularity of hosting: the list works in subnets, hosting works in individual addresses inside them.

This is not anyone’s design. It is arithmetic: negotiating every address separately costs more than entering a range wholesale.

Why the lists keep changing#

Three reasons, all mundane:

Providers reassign addresses. A customer leaves, the address goes to somebody else. The range on the list is unchanged; its contents are not.

Approvals get revisited. An organisation gains status, loses it, changes legal entity.

Infrastructure moves. A service changes hosting and its address is no longer the one that was entered.

Hence the practical consequence many people notice: it works today, not tomorrow, and again the day after, with no action on your part. That is not a fault. It is the boundaries of the list moving.

What splitting by subnet changes#

In late August 2026, per an RBC report citing a letter from the Ministry of Digital Development, hosting providers, CDN providers and web-protection services were asked to move whitelisted resource addresses into separate subnets.

The stated goal is to exclude from the whitelist organisations that have not obtained the corresponding approvals, VPN services among them.

Mechanically that means:

before:
subnet /24 ── everything mixed, the whole range whitelisted

after:
subnet A ── approved only, whitelisted
subnet B ── everyone else, not whitelisted

Inheritance of protection through adjacency ends. Being on a whitelist stops being a property of adjacency and becomes a property of approval.

The difference between the two is that adjacency can be bought with hosting. Approval cannot.

What this does not mean#

Three clarifications, because the news is easy to overread.

Whitelists are not going away. They are becoming more precise. The mechanism stays; its granularity changes.

This is not instant. The report itself notes the change “will take time” and will draw complaints from customers, since many have services tied to those addresses. Migrating addresses is work providers do not finish in a day.

A request was reported, not a state of the network. This is a ministry letter, not a description of an already-operating mechanism. Until there are direct observations, treating it as a direction rather than a fact is the reasonable posture.

Walkthrough: what this looks like on one range#

Take a notional 256-address range and watch what happens to it.

BEFORE THE SPLIT
198.51.100.0/24  ← the whole range is whitelisted
├── .10   government portal          approved     ← the reason for the listing
├── .11   a bank                     approved
├── .47   an online shop             never asked  ← inherits
├── .88   a gardening forum          never asked  ← inherits
├── .143  somebody's VPS             never asked  ← inherits
└── .200  250 more customers         never asked  ← inherit

AFTER THE SPLIT
198.51.100.0/26  ← whitelisted
├── .10   government portal          approved
└── .11   a bank                     approved

198.51.100.64/26 ← not whitelisted
├── .47   an online shop             moved, address changed
├── .88   a gardening forum          moved
└── .143  somebody's VPS             moved

Note the cost: to split, you must relocate. Customers in the second group receive new addresses — not because they did anything wrong, but because they landed in the wrong half of a range.

That is precisely where the remark about customer complaints comes from.

A numeric example: how much breaks when an address changes#

“Just change the IP” sounds like one operation. Here is what trails behind it for an average service:

What is bound to the address Who fixes it Delay
A records in DNS the owner minutes plus TTL
Allow rules in other people’s firewalls counterparties days, over email
Allowlists at payment providers counterparty days
Webhook bindings in integrations each integration separately days
Certificates issued against the address the owner hours
DNS caches on user devices nobody, you wait up to a day

The rows in bold are the expensive ones: they are fixed not by the service owner but by a third party with its own schedule and priorities.

Hence the pattern people observe: the service “moved in one evening”, and individual integrations keep surfacing failures for another two weeks.

A side effect that will hit ordinary services#

Worth calling out separately, because the report says it plainly: many customers have services tied to those addresses.

Changing an IP address is painful. An address drags along DNS records, settings inside third-party integrations, allow rules in other people’s firewalls, TLS certificates, bindings in payment systems. Migrating “just an address” turns out in practice to be migrating everything that knows about it.

So the effect an ordinary user is most likely to observe is not “the VPN stopped working” but a wave of small failures in services that have nothing to do with circumvention: an integration stops responding, a webhook does not arrive, a certificate fails validation.

What a user should do about it#

The practical conclusions are few but durable.

Do not depend on a single channel. The property that makes a service work today may belong to its subnet neighbour rather than to the service itself. Such a property is revoked by a third party’s decision, not by a malfunction.

Keep a way to receive a configuration update that does not run through the channel itself. The worst state is one where restoring access requires the access you do not have.

Do not draw conclusions from a single day. List boundaries move constantly and in both directions. One failure does not mean a channel is gone for good.

Conclusion#

A whitelist is a list of addresses, and all of its practical mechanics follow from that fact. Subnet adjacency granted protection to parties that never requested it; splitting by subnet ends that.

For a user the main consequence is not technical but this: an advantage inherited from a neighbour is not your own property and can be withdrawn without your involvement. Building anything long-term on it means planning with an unknown expiry date.

Terms#

  • Whitelist - a set of addresses and subnets to which restrictions are not applied.
  • Adjacency inheritance - the effect where an unrelated resource is protected because it shares a subnet with a permitted one.
  • Subnet segregation - moving permitted resources into separate ranges, which ends adjacency inheritance.

FAQ#

Why does a listed service sometimes break anyway?#

The list keys on addresses, not names. When a provider changes an address, the service leaves the list until the entry is updated.

What does splitting by subnet change?#

It removes the accidental protection of neighbours. A resource that survived by sitting next to a permitted address loses it.

Can a whitelist be relied on as a strategy?#

No. The contents and boundaries of these lists change without notice, and the decision is not yours to make.

Further reading#