This article is part of a larger series on the Public Suffix List. A more detailed, long-form piece is available here.

The Public Suffix List (PSL) is a security liability limping along as a vestigial artifact from a bygone age. Downstream consumers such as browsers, certificate authorities and RFC7489 DMARC receivers¹, to name a few, all read from this nearly 20-year-old text file for calculating domain boundaries. Each PSL consumer interprets the file differently and applies the boundaries inconsistently. File version skew across consumers is notorious, rollbacks are next to impossible, and the process for adding a domain to the PSL is arbitrary and onerous. Modern browsers depend upon it for the full array of site-isolation protections, and yet small platforms below an arbitrary user-count floor are ineligible for enrollment. It is well past time that the industry consider the harmful implications of the PSL and work towards its eventual deprecation. The internet would be well served by a replacement that satisfies modern security and automation objectives through joint collaboration with all stakeholders in an open and transparent way.

A Brief Overview of The Public Suffix List

The PSL is a simple text file, each line containing either a TLD or a private registry suffix. In practice, there is an ICANN section and a PRIVATE section. The ICANN section contains entries such as “co.uk,” “com,” “net,” etc. The PRIVATE section contains multi-tenant suffixes issued under regular domains like “github.io,” where subdomains represent untrusted user-owned content, i.e., “alice.github.io.” Mozilla originally conceived of this idea in the mid-2000s as an easy way for Firefox to delineate boundaries between domains for the purposes of cookie isolation. As the web matured, the PSL started to become intertwined in other browsers and eventually became the de facto source of record for all manner of domain boundary lookups. Over the years, the PSL became a best-effort, volunteer-maintained enterprise. The PSL is distributed as a file that is incorporated into the browser release executable at build time. This means that different browser versions ship with different PSL snapshots.

Due to the lack of a suitable alternative, anyone needing to parse domain boundaries was forced to use the PSL. Certificate Authorities like Let’s Encrypt began to consult it for calculating rate limits, RFC7489 DMARC-enabled mail receivers depend upon it for determining the organizational domain, WebAuthn passkeys validate Relying Party Identifiers against it; and browsers expanded its original scope to cover various state and storage partitions. There are numerous other use cases that have been excluded for brevity. A core database used by a diverse base of consumers hinges upon a decades old text file maintained by volunteers, who by their own admissions state^{2 3} it was not built for the use cases it now supports and they do not possess the resources to adequately oversee it^{4 5}.

Permissioned Security With No Equivalent

It is difficult to imagine anyone needing to obtain permission to use DNSSEC, ACME or configure a Content-Security-Policy header, but this is precisely how the PSL operates. Certain browser security features are locked away behind a PSL lookup. If a domain is absent, the browser will apply a more relaxed security policy towards the hostname. This may be desirable in certain circumstances, but it is certainly harmful when untrusted users share a common parent domain. Absent the PSL, operators have no ability to mandate these enhanced isolation features.

Owing to the scarcity of volunteer time and an intransigent stance against automation, anyone attempting to include a domain in the PSL must successfully petition the maintainers and lobby for their use case in accordance with shifting and arbitrary acceptance criteria. The volunteers themselves have taken an overly zealous position on the matter and only permit domains whose platforms can demonstrate^{6 7} user bases exceeding many thousands of unique users. The effect of this policy deprives small projects and startups of robust protections for their users. It is useful to compare this stance to the certificate authority Let’s Encrypt. Let’s Encrypt helped pave the way for universal HTTPS adoption. Operators are not required to reach a certain scale or provide a compelling enough use case in order to be eligible for a certificate. The resulting ubiquity of HTTPS allowed browsers to further harden themselves by only enabling certain features when HTTPS was present with a valid certificate. There would rightly be a very public and outrageous scandal if Let’s Encrypt were to mandate eligibility criteria for certificates based on the size of a user base. In fact, Let’s Encrypt previously attempted to gate issuance in accordance with third-party abuse signals and ultimately concluded it was infeasible^{8 9}.

Existing DNS records and HTTP headers that define domain security properties are already controlled by the owner, such as CAA, TLSA, DS, HSTS, CSP and others, but in the case of the PSL there is no equivalent. By its nature, the PSL cripples the authority of the owner by shifting boundary definitions to an external source that operators have no control or influence over. The PSL is unique in this regard.

The very notion of permissioned security should be concerning for anyone interested in domain security. With the increasing adoption of DNSSEC and its associated automation tooling making it easier than ever to deploy, there is a strong precedent to do the same with the PSL and the functionality it provides. Proponents of the current status quo will wax poetic about the need for oversight and the necessity of exclusion, but these are tired tropes that do more harm than good. Any critique of how the PSL rations security is met with vague retorts that an included domain could facilitate abuse. The same unconvincing arguments were made in the 1990s during the so-called crypto wars, where the US Federal Government attempted to control the availability of strong cryptography under the guise of protection.

In the end, the PSL harms the users that its proponents claim to protect through its own admissions process. The permissioned curation of the PSL is a textbook example of moral hazard: the maintainers don’t have to deal with the problems that they help create, leaving operators and end users in an uncomfortable position.

Browsers Are Largely Responsible

Browsers have been complicit and willing accomplices to the harms imposed by the PSL. Every major browser ships with some version of the PSL, but few beyond Mozilla contribute anything meaningful aside from some basic tooling. Browsers have built immense security features around it, many of them opaque and not well documented, leaving operators and developers in the dark about whether they need the PSL and what it actually provides. The PSL is a classic public goods dilemma. As long as it exists as a stable artifact, browsers have no incentive to improve or replace it. Browsers have long resisted alternative DNS-based suggestions citing latency concerns¹⁰ and integrity¹¹ as primary reasons. DBOUND¹² has been proposed as a potential solution for the domain boundaries question but never achieved the necessary consensus to graduate from the working group¹³. John Levine, a co-editor of RFC9989 and author of two DBOUND drafts, unequivocally states: “An even more important point was that the people who wrote web browsers made it quite clear that they have no interest in adding another DNS lookup to find the cookie boundaries, and bundling a static copy of the PSL into each browser release works for them.”¹⁴

Because the PSL itself is delivered as a static text file, PSL volunteers have stated that browsers have a preference to keep the file as small as possible¹⁵. This desire leads to restrictive curation practices, attempting to filter out domains that are not considered viable enough for PSL inclusion through user/subdomain floor requirements. As a result, browsers bias their own isolation features towards larger platforms at the expense of smaller ones. The insistence upon file size modesty insulates browsers from experiencing the pain of shipping a file that is too large, therefore removing the pressure to develop an alternative. One inconvenient aspect of the purported sensitivity to file size is the HSTS preload list shipped with most browsers. For comparison, the preload list sits roughly between 95k-172k entries¹⁶ depending upon the browser as opposed to the ~10k present in the PSL. Additionally, Chrome now fetches a multi-gigabyte Gemini model file on eligible installations¹⁷. Browsers apparently lack interest in modernizing the PSL, preferring instead to offer nebulous reasoning delivered by volunteer proxy for rationing it.

Conclusion

The Public Suffix List has diligently served the web for close to two decades but has since outlived its usefulness. The inability to scale, the medium of distribution, and the deprivation of domain owner control all compound into a security aberration that is no longer fit for purpose in 2026. There is an arduous journey ahead to replace it, but there are beacons of hope that can provide inspiration for the task at hand, namely RFC 9989¹⁸, the latest iteration of DMARC, which no longer requires the PSL. DMARC anticipated the eventual retirement of the PSL for its own usage in the appendix of RFC7489, referring to the dependency as “far from perfect” and “If a method is created to do so that is more reliable and secure than the use of a public suffix list, DMARC should be amended to use that method as soon as it is generally available”¹⁹.

The difficulty in replacing the PSL lies not necessarily with technical feasibility but with organizational alignment and tribal conflicts between stakeholders and consumers. As it stands today, no single standards body is uniquely equipped to coordinate efforts with the assorted browser vendor, CA, and DNS factions that depend upon the PSL. Browsers appear to remain content with the PSL in its current form. Until the problem is acknowledged, web security will only continue to deteriorate. The PSL as it exists must be abolished in favor of self-service primitives within the control of the domain operator.