Here is a question DNS cannot answer: is co.uk a website?
You know it isn’t — it’s where British companies register their own names, one level down. But nothing in the DNS protocol says so. co.uk is a perfectly ordinary node in the name tree, structurally identical to google.com. Both have records, both resolve, both sit two labels deep. If you tried to tell them apart by counting dots, you’d get example.com (one dot, registrable), example.co.uk (two dots, registrable), and example.pvt.k12.wy.us (four dots, also registrable) all giving different answers. There is no rule in the protocol, no flag in a record, no bit anywhere in DNS that marks the boundary between “a registry runs this” and “a person owns this.”
And yet that boundary is one of the most security-critical facts on the web. Your browser needs it every time it decides whether a cookie is allowed to be shared. A certificate authority needs it every time someone asks for a wildcard. The URL bar needs it to decide which part of the hostname to show you in bold. All of them are asking the same question — where does the public part of this name end? — and DNS refuses to tell them.
So the web went and built the answer by hand. It’s a text file.
The cookie monster
The reason this got solved at all is a bug with a great name: the supercookie.
Cookies carry a Domain attribute that says who’s allowed to read them back. Set Domain=example.com and every host under example.com gets the cookie. Reasonable. But the early rules for policing that attribute — the ones in the old cookie specs — were a heuristic so crude it’s almost funny: to stop a site from setting a cookie for a whole top-level domain, browsers required the domain to contain at least a couple of dots. com has no dots, so Domain=com was refused. Good.
Except co.uk has a dot. Under a dot-counting rule, co.uk looked exactly like a normal registrable domain, so a site sitting at evil.co.uk could set a cookie scoped to .co.uk — and every bank, shop, and government service under co.uk would then hand that cookie back. One site could plant state readable across an entire country’s worth of unrelated websites. The dots lied, because the number of dots before the registrable part is different in .com and .co.uk and .pvt.k12.wy.us, and there is no formula that gets it right.
In 2007, Mozilla stopped trying to find a formula and just wrote down the answer. The file was called effective_tld_names.dat — the effective TLDs, the suffixes that behave like top-level domains for registration purposes even when they have dots in them. It grew into the Public Suffix List, and it’s now a community project living on GitHub as a flat text file that anyone can read and anyone can submit a change to.
RFC 6265, the cookie spec that replaced the dot-counting era in 2011, made it semi-official. Its instruction to browsers is unusually candid about outsourcing the problem: user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at publicsuffix.org. The spec even names the attack it’s preventing — stopping attacker.com from setting a Domain=com cookie to disrupt example.com. The standard for how cookies stay isolated points at a URL and says, essentially, go look it up over there.
Public suffix plus one
The vocabulary is worth getting straight, because it’s everywhere once you see it. A public suffix is a name under which the public can register: com, co.uk, github.io. The thing you actually own is the public suffix plus one more label — eTLD+1, the registrable domain. For mybank.co.uk, the public suffix is co.uk and the +1 makes mybank.co.uk the boundary. Cookies, same-site checks, and “are these two hosts the same owner” decisions all pivot on eTLD+1. It’s the closest thing the web has to a definition of a site, and it is defined entirely by that list.
The list has three kinds of rule, and the third is where you feel how manual this all is. A normal line like co.uk means what it says. A wildcard line like *.ck means every label under the Cook Islands’ .ck is a public suffix — register example.co.ck, not example.ck. And then an exception, !www.ck, carves www.ck back out as an ordinary registrable name, because at some point www.ck actually resolved to a real site and the wildcard would have broken it. Somebody found that, and somebody added a line with an exclamation mark to fix it. That is the texture of the whole file: edge cases, discovered in the wild, patched by hand.
It stopped being about cookies
If the list only governed cookies, it would still be load-bearing. But it leaked into everything that needs to know where ownership begins.
Certificate authorities consult it before issuing wildcard certificates. The CA/Browser Forum’s Baseline Requirements are blunt: a CA must not issue *.co.uk or *.local, but may issue *.example.com. The difference is exactly the public-suffix boundary — a wildcard one label to the right of a registry-controlled suffix would let its holder impersonate every site in the registry, so it’s forbidden. And then the Requirements say the quiet part out loud. Determining what’s registry-controlled, they note, “is not standardized… and is not a property of the DNS itself.” The people writing the rules for global TLS issuance know the fact they depend on isn’t in the protocol. They lean on the list too.
Then there’s the private section. The file is split into an ICANN part (the real registry suffixes) and a PRIVATE part, where companies add their own domains: github.io, herokuapp.com, vercel.app, blogspot.com. The reason is subtle and important. On github.io, alice.github.io and bob.github.io belong to two strangers who should not be able to read each other’s cookies or get a certificate covering each other’s subdomain. Without a list entry, the browser would treat github.io as the registrable domain and the two users as the same site. By adding github.io to the PRIVATE section, GitHub tells every browser and CA on earth: treat each subdomain here as its own island. Multi-tenant platforms opt into isolation by getting a line in a text file.
A text file is holding this together
I want to be fair to the list: it works. It has quietly prevented a whole category of cross-site attacks for nearly two decades, and the alternative — a formula — provably cannot exist, because registry policy is a human artifact with no pattern to extract. Writing it down was the right call.
But look at what we’ve built on. A security boundary that gates cookies, certificate issuance, and same-origin-ish decisions across the entire web is a hand-curated text file, maintained by volunteers, changed by pull request, and shipped to users baked inside browser and library releases. That last part is the sharp edge. When a new suffix is added — a new TLD, or a SaaS platform that finally wants its subdomains isolated — the change doesn’t take effect when it’s merged. It takes effect months later, as it rides out inside software updates and old cached copies age out. A new platform asking for subdomain isolation is asking the whole world to update, and then waiting.
It gets worse in the places that don’t use the list at all. The dot-counting bug never really died; it just moved into a thousand naive URL parsers that “extract the domain” by stripping the last two labels. That code is wrong for co.uk, wildly wrong for .ck, and its authors usually don’t know the Public Suffix List exists. Every analytics pipeline and cookie library and phishing filter that rolls its own domain logic is quietly re-deriving a boundary that only the list actually knows.
The deep truth here is that DNS gives you a tree of names but says nothing about who administers which parts of it. Ownership boundaries are a real, load-bearing, security-critical property that the protocol simply doesn’t encode — and rather than fix the protocol, the web patched the gap out of band, with a file. Every time your browser lets a cookie through, or a CA signs a wildcard, or a URL bar bolds two labels instead of three, it’s consulting a list a handful of people keep by hand.
The internet runs on more of these than anyone is comfortable saying. This is one of the ones holding weight.