Summary

  • The DNS records delegation, not the administrative or security boundary between unrelated users. The Public Suffix List fills that gap by telling consuming software that names such as co.uk and github.io should be treated as boundaries beneath which different parties may operate.
  • The list is not controlled by ICANN, IANA or the IETF. It is maintained by volunteers through a public repository, with validation rules for registry and private-domain changes. Its practical authority comes from adoption in browsers, standards and libraries, not from a claim to govern the DNS.
  • A correct merge does not produce one instant global result. Applications embed different snapshots, update at different speeds, include different sections and sometimes add their own rules. The list is therefore an important coordination record, but not a universal or self-executing security perimeter.
  • The defensible model is thin and observable: authenticate the party requesting a boundary change, preserve a public decision trail, publish machine-readable releases, let each implementer decide how to consume them, measure propagation, and avoid turning list maintenance into a licence to regulate hosting businesses or domain holders.

Analysis

The missing fact in a domain name

Consider three names: com, co.uk and github.io. They occupy different positions in the DNS tree. com is a top-level domain. co.uk is below the country-code top-level domain uk. github.io is a privately registered domain used to provide subdomains to many users. Yet software can have the same practical question about all three: where does one independently controlled site stop and another begin?

The DNS does not answer that question. It can return records, follow delegations and prove data origin with DNSSEC where deployed. It does not carry a universal flag meaning “the labels below this point belong to mutually untrusting parties.” The IETF’s Domain Boundaries working-group charter stated the problem plainly: administrative relationships are not evident from names or from the DNS’s public operational representation, and the right answer is not always to compare the two rightmost labels.

That absence matters because a browser has to make decisions before a human can investigate corporate control. When a server asks a browser to store a cookie for a parent domain, the browser must decide whether the request stays within one site or crosses into a shared namespace. If every tenant below github.io were treated as part of one registrable site, a tenant could try to set state at a level shared with other tenants.

If co.uk were treated as the registrable organisation, unrelated British registrants could be collapsed into one policy realm. Conversely, if every subdomain boundary were assumed to separate organisations, ordinary sites would lose legitimate ways to share cookies and policy across their own hosts.

The Public Suffix List, or PSL, supplies the missing classification. Its own definition describes a public suffix as a domain beneath which Internet users can, or historically could, register names. The WHATWG URL Standard gives a concrete example: github.io is a public suffix, while whatwg.github.io is a registrable domain. This classification is not a new DNS delegation. It is application knowledge about how a delegated name is used.

That distinction is the first control boundary. IANA’s root-zone records answer which top-level domains exist and who is listed for their operation. A registry’s records answer what has been registered beneath its zone. The PSL answers a different question for consuming software: at which label should an application presume that unrelated administrative control may begin? Mixing those functions would create false authority. A public-suffix entry does not transfer the domain, change its name servers, create a registration or confer property. It changes how participating software interprets a boundary.

A cookie rule made the list operational

The list’s most intelligible use is cookie isolation. RFC 6265, the 2011 HTTP State Management Mechanism, says that a user agent configured to reject public suffixes should refuse a cookie whose Domain attribute is a public suffix, subject to a narrow host-equality case. The reason is concrete: without the check, an attacker operating beneath a shared suffix could interfere with the integrity of another registrant by setting a cookie too high in the tree. The RFC recommends an up-to-date list and points to the Mozilla-maintained resource.

The current RFC 6265bis draft keeps the same operational lesson and makes the risk more explicit. Cookie boundaries depend on a site’s registrable domain, which depends on the public suffix. A stale list can allow malicious or sensitive cookies to leak between registrable domains. The text also confronts time: a cookie may have been accepted when a name was not classified as a public suffix and later become ineligible after the list changes.

That is governance with observable consequences. A line in a data file can affect whether a browser accepts, returns or withholds state. The consequence is neither symbolic nor equivalent to a law. It is a product decision executed by code. The standard supplies a rule and a security rationale. The list supplies current boundary data. The browser or library supplies enforcement. The site operator supplies the cookie. Each actor controls a different step.

This division helps resist two exaggerated accounts. The first says that the PSL maintainers “control domains.” They do not control DNS delegation, registration or authoritative resolution. The second says that the list is merely documentation. It is more than documentation when widely deployed applications use it in cookie, same-site, interface, mail or certificate logic. Its practical force lies between those claims: it is a coordination record whose entries become consequential only when downstream software adopts and ships them.

The same pattern appears beyond cookies. ICANN’s Office of the Chief Technology Officer documented uses in browser process and scripting boundaries, domain interpretation, interface highlighting and DMARC organisational-domain discovery. The public PSL site lists supercookie prevention, address-bar emphasis and history sorting among its original purposes. Libraries use the data for still other decisions. These uses are related, but they are not identical. A boundary suitable for cookie isolation may be only an approximation for corporate identity, email policy, certificate limits, analytics or rate limiting.

That difference is why one list should not be described as a complete map of organisational truth. It records a useful presumption for specified uses. Every consumer remains responsible for proving that the presumption is safe for its own decision.

The ICANN section and the private section describe different evidence

The PSL’s file contains two main sections. The section labelled “ICANN” covers names tied to the IANA root and registry policies beneath them. The private section covers domains whose holders provide subdomains to mutually untrusting parties, including hosting and platform patterns that do not appear as top-level delegations.

The label “ICANN” can mislead if read as ownership. The PSL format documentation itself notes that “IANA” might have been a more accurate label but that changing it could break integrations. ICANN’s own technical guide is clearer: the PSL began as a Mozilla initiative and is maintained by external volunteers, outside the direct management or control of ICANN, the IANA functions and the IETF. The list adheres to the unique-root model and uses authoritative material from those institutions, but evidence dependence is not institutional subordination.

Mozilla is the institutional subject here in two bounded capacities: as the initiative’s originator and, through Firefox, as one consequential downstream implementer. This article examines the responsibilities those roles create when a shared record becomes running code. They do not make Mozilla the present owner of the community list or give it authority over other consumers.

The private section makes the separation even clearer. A platform operator can control a domain such as github.io while providing many subdomains to parties who do not trust one another. The DNS correctly shows the platform’s control of the parent. The application still needs to know that tenant isolation should occur one label lower. A private-section entry expresses the operator’s deployment and security model; it does not pretend that the parent is a top-level domain.

This is a useful example of localised decision within a thin common format. The common rule says how an entry is represented and how longest-match and exception rules work. The domain holder supplies the local fact that it operates a shared namespace. Maintainers authenticate that claim and review whether the request fits the list’s purpose. Consumers voluntarily decide whether to include the private section and which uses to attach to it.

The arrangement resembles a registry only in the narrowest sense: it records unique, machine-readable assertions about boundary treatment. It should not be inflated into sovereignty. Maintainers do not need authority over a platform’s pricing, content rules, customer eligibility or commercial model to decide whether mutually untrusting users receive subdomains. They need enough evidence to decide whether the requested boundary statement is authentic, accurate and suitable for the list.

Participation is open; acceptance is still a controlled act

Anyone can open a pull request. That fact makes the maintenance record inspectable and allows outsiders to identify errors. It does not mean that every participant holds equal authority to alter the distributed list. A change is accepted only after maintainers apply format, purpose and authentication rules.

The current guidelines require a requester to explain the change, place it correctly, provide expected behaviour and demonstrate authority. For ICANN-section changes, authoritative registry material or confirmation from the relevant administrator matters. For private entries, an authorised representative of the domain holder is required. The guidance places particular weight on a DNS TXT record connecting the domain to the pull-request number. Certain sensitive namespaces may receive additional scrutiny.

This is an important distinction between attendance and mandate. Public comments can improve a decision. A contributor can supply facts, identify an error or challenge an assumption. None of that alone proves authority to speak for the domain holder. Authentication answers a narrower question: does the requester control, or have authority from the party controlling, the name whose operational boundary is being described?

The procedure is not flawless simply because it is public. The repository warns that volunteer capacity is thin, that there is no customer-service operation, and that malformed entries can damage cookies.

The 6 May 2026 notice requires the standardised request form and explains that its attestations form part of the public and consistent review record. The 27 May 2025 notice rejects attempts to use the PSL as a workaround for an unrelated Cloudflare product limitation. These notices show active boundary defence: maintainers are trying to prevent a security coordination list from becoming a general-purpose entitlement system for platform features, advertising rules or certificate limits.

That restraint is healthy. A list becomes vulnerable to mission expansion when inclusion produces side benefits. Once advertising systems, certificate authorities, analytics tools or cloud products use the PSL for their own limits, applicants have incentives to seek entries for reasons unrelated to tenant isolation. The maintainer then faces pressure to adjudicate commercial claims that the list was never designed to settle.

The correct response is not to pretend those external effects do not exist. It is to separate them. The requester must establish that the boundary fits the PSL’s published purpose. A downstream vendor must justify any product rule it attaches to PSL status. If a cloud provider makes a feature available only to listed suffixes, responsibility for that eligibility rule remains with the provider. The PSL should not distort its acceptance criteria to repair a vendor’s commercial design.

Authenticating the change does not prove every downstream consequence

A DNS TXT record is powerful evidence because it is placed under the name being discussed. It can connect a pull request to control of the relevant zone. It does not prove that every subdomain is assigned to an unrelated party, that the requester’s business model will remain stable, or that every software consumer should interpret the entry identically.

Documentation and operational examples therefore matter. A private-domain applicant should explain who receives subdomains, whether tenants are mutually untrusting, what cookies or same-site treatment should result and what will happen if the service closes or changes its allocation model. A registry-section change should identify the authoritative policy that makes a second- or third-level label a registration boundary. Maintainers can then decide the list question without pretending to audit the whole enterprise.

This evidence discipline should also apply to removal. A stale private entry may keep isolating names after a platform no longer offers independent tenancy. Removing it too early may collapse users into a shared site boundary while old accounts, redirects or cookies still exist. The decision needs an observable decommissioning story: domain control, tenant state, remaining users, supported clients, intended dates and rollback limits.

The public repository provides an unusually good decision trail compared with a private vendor record system. Pull requests, review comments and commits can show who asked, what evidence was supplied and what was merged. Yet the public record is only the source decision. It does not establish where or when the change became effective. That requires a second ledger: downstream adoption.

Sources

  1. Lu Heng, “Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design”
  2. Public Suffix List project overview
  3. Public Suffix List source repository and current maintainer notices
  4. Public Suffix List submission and validation guidelines
  5. Public Suffix List file format and section semantics
  6. ICANN OCTO-011, “The Public Suffix List: A Guide for TLD Administrators”
  7. RFC 6265, HTTP State Management Mechanism
  8. IETF HTTPbis draft, Cookies: HTTP State Management Mechanism
  9. WHATWG URL Standard
  10. IETF DBOUND working-group charter
  11. RFC 8499, DNS Terminology
  12. Firefox source snapshot of effective_tld_names.dat
  13. Public Suffix List maintainer notice of 6 May 2026: standardised request form and attestations
  14. Public Suffix List maintainer notice of 27 May 2025: Cloudflare restrictions are outside the list’s purpose