The Public Suffix List and the Registrable Domain

Why the last two labels are the wrong answer

The registrable domain of a hostname cannot be worked out from the hostname. It has to be looked up against the Public Suffix List, because the line between the part a registry controls and the part a registrant controls is set by registry policy and appears nowhere in the string.

Take the last two labels and www.example.com gives example.com, which is right, while www.example.co.uk gives co.uk, which nobody registered. Take the last three and co.uk works while .com breaks. No third heuristic rescues both, because the same shape of string means different things under different registries:

• www.example.com has the public suffix com, so the registrable domain is example.com
• www.example.co.uk has the public suffix co.uk, so the registrable domain is example.co.uk
• www.example.com.au has the public suffix com.au, so the registrable domain is example.com.au
• www.test.ac.jp has the public suffix ac.jp, so the registrable domain is test.ac.jp
• whatwg.github.io has the public suffix github.io, so the registrable domain is whatwg.github.io

The maintainers state the constraint directly: since there was and remains no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain, the policies differing with each registry, the only method is to create a list. Every correct implementation is a lookup, and every regular expression is a guess that holds only for the extensions its author tested.

What the list is, and who keeps it

The Public Suffix List is a plain text file, public_suffix_list.dat, published at publicsuffix.org and maintained in a public repository on GitHub. The Mozilla Foundation created it for the security and privacy policies of Firefox and holds the copyright, but it runs as a community resource any software may use, with registries asked to maintain their own portions.

The format is deliberately dull. One rule per line, each line read only as far as the first whitespace, entire lines commented with a double slash, UTF-8 encoded, and written in Unicode rather than Punycode. The published copy is updated daily, and the site asks consumers to download it no more than once a day.

Comment markers divide the file into two sections. The ICANN section covers the top-level domains delegated by IANA and the structures registries operate beneath them. The private section covers domains that are not top-level domains at all, submitted by the organizations that hold them. An application may use either or both, and that choice changes the answer for a great many hostnames.

Public suffix, effective TLD, registrable domain

A public suffix is the part of a domain name not under the control of the individual registrant: one under which Internet users can, or historically could, directly register names. The cookie specification calls it a domain controlled by a public registry, giving com, co.uk and pvt.k12.wy.us as examples. Effective TLD, or eTLD, is the same idea under an implementer's name, used because co.uk behaves like a top-level domain without being one.

The registrable domain is the public suffix plus the one label immediately to its left. The URL Standard defines it exactly that way: a domain formed by the host's public suffix and the domain label preceding it, if any. eTLD+1 is the same value again, named for how it is computed; Go's library documents that the eTLD+1 for foo.bar.golang.org is golang.org. Three terms, one value.

The words if any carry weight. A hostname that is itself a public suffix has no registrable domain, and a correct implementation returns nothing rather than a string: for com the public suffix is com and the registrable domain is null, while www.example.com and sub.www.example.com both give example.com. Code that assumes a string always comes back breaks when someone enters a bare extension.

Wildcards, exceptions, and the rule that catches everything else

Most entries are literal, but two pieces of syntax do the difficult work. An asterisk wildcards an entire label and may appear only in the leftmost position. An exclamation mark at the start of a rule marks an exception to a wildcard, and an exception outranks every other matching rule.

The Cook Islands entry is the textbook case. The list carries *.ck, making every second-level name under .ck a public suffix, alongside !www.ck, which pulls one name back out. The list's own tests show the result: test.ck has no registrable domain, while b.test.ck and www.ck each resolve to themselves. Japan works the same way, with *.kawasaki.jp paired with !city.kawasaki.jp.

The matching algorithm resolves conflicts in a fixed order. Match the hostname against every rule, prefer an exception if one matches, otherwise take the rule with the most labels, and for an exception drop its leftmost label. The registrable domain is then that public suffix plus one more label.

The step that surprises people is the last resort. If nothing matches, the default rule is a bare asterisk, so the rightmost label becomes the public suffix. An extension the list has never heard of yields a confident, plausible, possibly wrong answer instead of an error. That is how a stale copy fails.

The cookie rule the list was built to enforce

The list exists because of a specific browser failure. Cookies may widen their own scope up the domain tree through the Domain attribute, and early browsers had no way to tell where that tree stopped being one owner's property. A site under .co.uk could set a cookie for co.uk, and it would be sent to every other site under .co.uk.

The cookie specification encodes the defense rather than solving it: many user agents are configured to reject Domain attributes that correspond to public suffixes, and one so configured ignores such a cookie outright. The same document spells out the neighbor problem, noting that a server at foo.example.com can set a cookie with a Domain attribute of example.com, after which the browser sends it to bar.example.com as well. Sharing across your own subdomains is a feature; sharing across a registry's is an attack, and only a lookup separates the two. The storage model is in RFC 6265.

Browsers now use the same boundary wherever they need a concept of a site rather than a host: grouping cookies and history entries, deciding what counts as same-site, and choosing which part of a hostname to show as the identity of the page.

The private section, and why two people get two answers

The ICANN section derives from delegations and registry structure. The private section is different in kind: it holds domains submitted by their own holders to express a security policy, which in browser terms means asking to be treated as a boundary rather than as a site. Submissions come only from authorized representatives, proved with a _psl TXT record in the zone pointing at the pull request.

This is where the answer becomes contested. Because github.io sits in the private section, the URL Standard's example table gives the public suffix of whatwg.github.io as github.io and its registrable domain as whatwg.github.io, while github.io alone has no registrable domain. For cookie isolation that is exactly right: one project's pages should not write cookies another project's pages can read.

For almost every other question it is wrong, or at least not what the person asking had in mind. If you are grouping traffic by the organization behind a name, counting customers, or deciding who to contact about abuse, the useful answer is the platform's domain rather than the subdomain an account occupies. The list does not resolve that tension; it exposes it, and hands the decision to whoever configures the library. The URL Standard definition is worth reading before you choose.

Libraries, defaults, and the stale copy that returns the wrong domain

Every major language has an implementation, and using one is the right move. The differences that matter are how each obtains the list and what it does with the private section.

• Go: golang.org/x/net/publicsuffix, which compiles a snapshot into the library and flags whether a suffix is ICANN managed
• Python: tldextract, which fetches the current list on first use and caches it, with a bundled snapshot as fallback
• JavaScript: psl, which bundles the rules and refreshes them with a script that pulls from publicsuffix.org
• Ruby: publicsuffix-ruby, which ships a bundled list and makes no HTTP requests at parse time
• Java: Guava's InternetDomainName, with publicSuffix and topPrivateDomain
• PHP: php-domain-parser, which bundles no static copy and offers cache-backed storage for the list and the IANA top-level domain file

Defaults diverge, which produces silent disagreement between services inside one company. tldextract excludes private suffixes unless you ask for them; publicsuffix-ruby includes them unless you turn them off. Feed both the same hosted-platform hostname and you get two different registrable domains, each library behaving as documented.

The more common failure is age. ICANN's Security and Stability Advisory Committee found that many third-party libraries have no dynamic update capability and may keep an outdated copy indefinitely unless the software is updated by hand, called that missing upgrade path the largest problem it identified, and observed wide variation in how long a change takes to reach applications, with a best case of roughly twelve weeks. ICANN's guidance to registry operators says the same from the other end: some software fetches the current list, and some compiles a static one in and updates rarely or never.

A wrong answer usually traces to the vintage of the data rather than to the code. Pin the library, but do not pin the list: refresh it on a schedule, record which version produced a result, and resist using it as a validity check, a practice the maintainers call dangerous because extensions change and a static copy does not.

What the boundary decides for the owner of a domain

This is not only a developer's concern. The boundary determines where a cookie may be set, which is the difference between a sign-on session that works across your subdomains and one the browser silently discards. If your site lives on a platform whose domain is in the private section, your pages are their own cookie island by design, and moving to a domain you register yourself changes that.

Certificates use the same line. The CA/Browser Forum's Baseline Requirements define a base domain name as the first node to the left of a registry-controlled or public suffix plus that suffix, and wildcard validation is performed against the name below the boundary. A wildcard covers names you can prove control of; it cannot span a public suffix.

Analytics and reputation systems group by registrable domain rather than by hostname, which is why traffic from a dozen subdomains rolls up into one property, and why per-site rate limits apply to a whole domain rather than to each host.

For a registry or platform operator, keep the entry current: a missing or outdated one surfaces as broken logins, misgrouped analytics, and certificates that cannot be issued as expected. For everyone else the advice is shorter. Do not compute this value yourself, choose a library that refreshes its data, decide explicitly whether the private section applies, and treat a null result as an answer rather than a bug.