The layers above your server: domain, CDN, transit

Choosing where the server lives is one decision out of three, and it is rarely the one that decides the outcome. Above the server sits a name, operated by somebody else. In front of the server sits, for most sites, a reverse proxy operated by somebody else again. Neither is bound by your host’s policy, neither sits in your host’s jurisdiction, and both can be ordered to act by a court that has no reach over your host at all. This is the part of the stack that offshore hosting does not cover, and it is worth knowing exactly where it stops.

Three layers, three different owners

A site that is reachable at all depends on at least three separate businesses, and they fail independently.

The name. A registrar sold it to you; a registry operates the extension it lives under. Two companies, usually two countries, and the second one has never heard of you.

The front. If anything answers on your behalf — a CDN, a reverse proxy, an anycast edge — it terminates your visitors’ connections before your server sees them. It therefore knows your origin address by construction, and it receives the complaints.

The wire and the machine. Your host, its transit carriers, the facility, the address range your server sits inside. This is the layer people shop for, and it is the only one of the three that a hosting jurisdiction actually governs.

The habit worth breaking is thinking of these as one purchase. They are three, and putting all three in one hand — or in one legal system — is how a single order takes down everything at once.

The domain: the registrar, and the registry above it

Your registrar is the shop. The registry is the wholesaler that operates the extension, and it is the layer almost nobody checks before buying.

What moves a registrar

Since 5 April 2024, accredited registrars have carried a contractual duty to act on what ICANN calls DNS Abuse: when they hold actionable evidence, they must promptly take mitigation measures reasonably necessary to disrupt the name. The useful half of that rule is its definition. DNS Abuse means malware, botnets, phishing, pharming, and spam where spam is the delivery vector for one of the others. Website content is out of scope, and copyright is out of scope — explicitly.

Read that as a threshold rather than a comfort. It tells you the shape a complaint must take before your registrar is obliged to move; it also tells you that everything outside that list has to arrive as an order from a court or an authority, which is slower, checkable, and appealable. Both halves are worth knowing before you file the complaint you are about to receive.

What the registry can do, and where it sits

A registry has a single, absolute lever: it can set a status on your name that removes it from the zone. The name then resolves for nobody, anywhere, no matter what your registrar thinks and no matter where your server is. Nothing at the hosting layer mitigates this, because nothing at the hosting layer is involved.

It is not theoretical. In June 2026 a Texas district court issued a writ of attachment directing Verisign, which operates .com, to place motherless.com on registry hold. The operator was a Luxembourg company that had ignored a Texas judgment under the state’s age-verification statute; the order set a $9.14 million bond as the condition for getting the name back. The site was not hosted in Texas and the company was not in Texas. The name was in .com, and .com is operated by a United States company under United States jurisdiction. That was sufficient.

The generalisable lesson is not about that case. It is that the extension you choose is a jurisdiction choice, exactly like the country your server sits in, and most people make it by habit. Ask who operates the extension, under which law, and whether that legal system has a practice of ordering registries around. Then decide whether you want your only name there.

Privacy on the name is about publication, not knowledge

WHOIS and RDAP redaction stops the bulk scraper and the casual look-up. It does not make your registrar ignorant: accreditation obliges it to hold registration data, and it discloses that data under legal process like anyone else. A privacy service in front of the record is a publication setting, not a shield — and a registrar that never asked you for anything cannot disclose what it does not have, which is a different property entirely and the only one worth paying for.

The proxy in front: what it removes, what it forwards

A CDN is a caching intermediary. It does not durably store your site, so “take the file down” is usually not a thing it can do. What it can do is stop proxying you — which, for a site that depends on the proxy to stay reachable and to keep its origin quiet, is a takedown and a disclosure in one motion.

The more interesting behaviour is the everyday one, and the largest provider publishes it plainly. On receiving an abuse report about a site it merely proxies, it will forward your complaint to the website operator and the hosting provider, and it will provide the hosting provider with the origin IP address of the content at issue. Both of those are quoted from its own abuse policy, and they are the opposite of what buyers assume they are paying for.

So the proxy is not a buffer between you and your host’s abuse desk. It is a courier. It carries the complaint to your host, and it tells your host precisely which machine to look at. If you chose your host for how it handles complaints, that is fine — the complaint arrives where you wanted it to arrive. If you chose a proxy hoping the complaint would stop there, it does not.

The same provider’s documentation also imposes an obligation on you: keep an abuse contact address that is actively managed and monitored, and respond to any abuse report notification within twenty-four hours. Failing to respond in time may result in the reported content being removed or blocked, and in suspension or termination of the account. The intermediary that cannot remove your content has nonetheless written itself a removal clause, and a clock.

One exception matters. Where the same company also hosts — its object storage, its serverless platform, its media and pages products — it is a hosting provider for that content, it says so, and it removes content under a notice-and-takedown process with counter-notice, in the shape United States law prescribes. Two products of one vendor, two entirely different answers. Know which one you are actually using.

What a CDN does not hide, and how origins get found

Plenty of people put a proxy in front of a server for one reason: to keep the origin address off the public internet. It is worth knowing how well that works in practice, and the honest answer is that it works until one of five ordinary mistakes undoes it. None of these are exotic; the proxy vendors document them themselves.

The records you published before you moved. DNS is public and it is archived. Almost every site that moved behind a proxy has its pre-move address sitting in somebody’s historical dataset, permanently. The vendor’s own guidance is to rotate the origin address after onboarding — if you did not, the move was cosmetic.

The records you left unproxied. One subdomain pointing straight at the box is enough: mail, ftp, cpanel, dev, staging, vpn, the monitoring host you set up once. Audit every record in the zone, not just the ones you remember creating.

Mail leaving the machine. If the origin sends mail, its address travels in the headers. Send a message to an address that does not exist and the bounce arrives carrying it. Mail belongs on a different machine to the one you are trying to keep quiet.

Certificate transparency. Every publicly trusted certificate is logged with the names it covers. The logs do not hand over an address, but they hand over the complete list of subdomains to try, including the ones you thought were private.

Wholesale scanning. The whole address space is scanned continuously and indexed by what it answers. A distinctive page served from a bare address is a database lookup, not an investigation.

The fixes are well understood, and they are worth doing in order of strength rather than in order of convenience.

1. An outbound-only tunnel. The origin opens a connection to the edge and listens on nothing. There is no port to find, so the address stops being interesting even if it leaks. This is the only option on the list that does not depend on getting a rule right.
2. Mutual TLS from the edge. The origin serves only to a client that presents the proxy’s certificate. The address may leak; it will not answer. Strong, and it survives the address becoming public.
3. Firewall to the proxy’s published ranges. Better than nothing and easy to deploy, but the ranges change, and the vendor’s own comparison flags this approach as vulnerable to spoofing. Treat it as a floor, not a solution.
4. Housekeeping. Rotate the origin address once you are behind the edge, move mail off the box, and audit unproxied records after every change. Most exposures are one of these three, not a clever attack.

A proxy hides the origin from a stranger with a browser. It does not hide the origin from the proxy — which knows it by definition, and which, on receipt of a complaint, is committed to telling your hosting provider what it is.

Under the machine: transit, prefix, facility

Below your server there is one more set of parties, and they are the ones a host is usually least keen to discuss.

Transit carriers. Your host buys connectivity from somebody. Those carriers have abuse desks, contracts and risk appetites of their own, and a carrier that decides you are trouble can make your host’s decision for it. Ask how many carriers there are — one is a single point of policy as well as a single point of failure — and ask the sharper question: does your host accept carrier-side blocklists, quietly, on your traffic?

The prefix you share. Reputation systems work on address ranges, not on customers. You inherit your neighbours, and you inherit them without being told who they are. This is the concrete cost of a provider that advertises itself as a refuge for anything at all: the blocklists arrive at the range, and your mail and your API calls are inside it.

The facility and the hardware. Rented cabinets mean a landlord with its own abuse policy sitting above your host, invisibly, and every layer above your host is another party that can terminate you for reasons you will never see.

Since the point of this guide is to make each layer answerable, here is this one in the same terms. Two transit carriers, BGP-balanced, twenty gigabits blended, into Chișinău. Layer 3 and layer 4 filtering upstream of every port, for everyone, with nothing to buy. Carrier-side blocklists are not accepted on customer traffic: if something must be blocked, a court says so and we tell you. The hardware is owned rather than rented, in one country, by the company you buy from — the details are on the network page and the facility page.

And the gap, stated plainly: we do not sell domains, and we do not operate the proxy you put in front of your server. Those two layers are yours. Everything above about registries and about forwarded complaints applies to you exactly as written, and no hosting jurisdiction — ours included — changes a word of it.

Putting the three layers in three different hands

The whole guide reduces to a handful of decisions, and none of them cost anything.

1. Three layers, three suppliers, three legal families. Name, edge and server in one company’s hands is one order away from nothing. In three hands, an order against any one of them leaves the other two working and leaves you time.
2. Ask every layer the same three questions. What can you be made to forward, what can you be made to remove, and what can you be made to disclose? They fail independently, and a supplier that answers all three in one sentence has not understood the question.
3. Configure as though the proxy forwards, because it does. Assume every complaint reaches your host with your origin address attached. If that outcome is a problem, the fix is at the hosting layer or in what you publish — not in adding another intermediary.
4. Close the origin properly. Outbound-only tunnel or mutual TLS; mail on a different machine; rotate the address after onboarding; audit unproxied records. Four items, all boring, and they cover almost every real exposure.
5. Treat the name as your single point of failure, and plan for it. Know which registry operates your extension and under which law. Hold a second name, in a different extension, at a different registrar, and know in advance how you would tell people to use it.

None of this argues against putting a proxy in front of your server, and none of it argues against offshore hosting — we would be a strange source for either argument. It argues that the three layers are three separate purchases with three separate failure modes, and that the one most people scrutinise hardest is not the one most likely to end them. If you want the layer we do operate held to the same standard, the quarterly numbers and the law-enforcement page are where to check it.

Written by the engineers who run the platform, and re-read today. If something here is wrong or has gone out of date, say so from the panel — that is where about half of these came from.