Infrastructure as control: what CDNs, DNS, and cloud really are

A site goes down in one country. The team checks. Hosting is fine. DNS resolves everywhere else. The build is green, the Cloudflare dashboard says healthy, the synthetic checks from Frankfurt pass. The site is up. It is just unreachable, specifically, from inside one country's BGP island, and there is no incident page that knows how to say that.

This is what the internet actually is when you take the marketing layer off — a stack of overlapping jurisdictions wearing the costume of a single network. The costume is convincing for most users, most of the time, which is why the people who chose your hosting, your CDN, your DNS, your certificate authority, and your cloud region were able to make a set of governance decisions on your behalf without ever being asked to frame them as such.

The stack the design review does not cover

Almost no design review I have ever sat in has covered the layer I am about to describe. The review covers brand, typography, accessibility, performance, content, sometimes motion. The review almost never covers the political geography of the infrastructure the site is being served from.

The political geography matters. It determines who can take your site down, who can serve a forged version of it, who can log every visit, who can issue a certificate impersonating you, who can pull your domain, who can read your data in transit, who can subpoena your backups, and who can do any of this without ever telling you.

Here is the layer cake, briefly, with the question each layer answers.

DNS. Who decides what your domain name resolves to. The registrar holds the keys. The TLD operator sits above the registrar. The country whose laws apply to the TLD operator sits above that. If your domain sits on a country-code TLD, the practical answer to “who can take this away from you” is “the government of that country, with a phone call to the right office.” Most teams choose the TLD because the URL looks good on a business card, without realizing they have also picked up the sovereignty that comes with it.

Certificate authority. Who can issue a certificate that says this is your site. There are roughly a hundred root CAs in the trust stores major browsers ship with, and a handful of them have a documented history of issuing certificates under government pressure (look up the DigiNotar episode, or what was found out about Trustwave a decade ago, or the various Kazakh root incidents). The chain of trust is only as strong as the weakest CA your readers' browsers will accept, which means a man-in-the-middle attack against your site, in a country whose government has leverage on the right CA, is somewhere between a monthly event and a regional baseline depending on the year.

CDN. Which edge nodes serve your content, and which governments have leverage on the CDN provider. Cloudflare's PoPs are political objects. They have addresses. Those addresses are in countries. Those countries have laws. The PoP that serves your reader in Country X is also a piece of corporate property that the government of Country X can seize, audit, or co-opt. When Cloudflare disconnects an entire country from its service — which has happened, and will happen again — every site behind it goes dark from that country's perspective, regardless of where the origin is.

Cloud region. Where your data physically sits and therefore which jurisdiction's law applies to it. AWS us-east-1 is not a neutral coordinate; it is a set of buildings in Virginia subject to the laws of Virginia, the United States, and any country whose mutual legal assistance treaties cover those buildings. The cloud region operates a bit like a passport for your data — your data has one whether you applied for it or not, and which one you end up holding affects who can ask questions about it later.

Network path. Which intermediate networks your reader's request traverses to reach you. The reader in Country X does not connect to your server. They connect to their ISP, which connects to a peering exchange, which connects to an IX, which connects to a tier-one carrier, which connects to your CDN, which connects to your origin. Every hop is an opportunity for inspection, modification, delay, or capture. The hop topology is decided by economic relationships between network operators that you do not see and cannot vote on.

Why this is invisible until it isn't

The internet works well enough, most of the time, for most people, that the layer cake is invisible. The site loads. The cert is valid. The DNS resolves. The cloud bills come in. The architecture under all of this is treated as ambient — like plumbing — and not as the set of political decisions it actually is.

The invisibility ends the moment one of the layers exerts its nature. A government pressures a registrar. A CA issues a forged cert. A cloud provider exits a market. A CDN's edge node is seized. A BGP route gets hijacked. Suddenly the invisible layer is the only thing happening, and the team that chose the architecture is staring at the consequences of decisions they made on price and convenience.

The team is not at fault for this. Almost nothing in their training prepared them to think about it. The vendor pages do not mention it. The bootcamp curriculum does not cover it. The design system does not have a token for it.

The audiences that pay the cost first

A product built on the median assumptions of the infrastructure stack works fine for the median user. The user in a stable country with a stable carrier and a stable phone and an uncontroversial reading habit. They will never hit the layer that breaks.

The user who breaks first is, almost without exception, the user who needed the product most. The journalist in a country where the regime has leverage on the cert authority. The activist whose ISP is owned by the interior ministry. The reader on a mobile network that the state can kill-switch when it decides things have gotten out of hand. The diaspora user whose connection home routes through three hostile jurisdictions before it reaches your origin in Frankfurt.

The default infrastructure choices route around all of these users. Not maliciously. Not consciously. Just as a function of optimizing for the median. The median is the user who does not need you to think about this. The user who needs you to think about it is, by definition, not the median.

What I do differently when the audience is in a contested environment

The first thing is that I name the constraint out loud. Where are the readers physically. What carriers do they use. What censorship infrastructure sits between them and the open internet. What is the worst case for them if our system leaks. Almost no project I have worked on with a “global” audience has had a serious answer to these questions when I asked. The questions are the work.

The second thing is that I pick infrastructure that survives both the censor and the sanctions regime. This is not always possible. When it is, it usually means: a TLD outside the contested jurisdiction; a CA with a clean record; multi-region failover not as a performance optimization but as a survivability one; a CDN whose corporate domicile is durable against the specific pressures the audience's government can exert; an origin that is reachable by tunnel even when the front door is blocked; mirror domains for when the primary is seized.

The third thing is that I write the failure modes down in a document the team is required to look at when the next feature is being scoped. The document is not long. It does not need to be. It just needs to exist, and it needs to interrupt the next conversation that would have ignored it.

What the field still needs

Designers are not usually in the room when infrastructure decisions get made, and infrastructure engineers are not usually in the room when design decisions get made. The two rooms talk through tickets, and the ticket template does not have a field for political consequence — so the consequence travels along with the work, unnamed, and surfaces later as something the incident retro frames as a vendor issue.

The fix here is not procedural. It is that more designers need to learn enough about the layer cake to argue with the infrastructure team in that team's own vocabulary, and more infrastructure engineers need to learn enough about the audience to push back on a design decision when the audience is going to pay for it in ways that show up in places no dashboard is watching.

Infrastructure is a design decision. The people who get to make it mostly don't think of themselves as designers, and that is also a design decision, made by the field about itself, a while ago, and never revisited. Until the field revisits it, the median user keeps being the one the system is optimised for, and the user who actually needed the product keeps paying the convenience cost of the team that built it. I don't think this gets fixed in one essay. I think it gets fixed in fifteen years of slow vocabulary change, of which this is one paragraph.