TLD vs Public Suffix: Why google.abc.br Has Two Correct Answers

A domain like google.abc.br creates a surprisingly good question: is its TLD .br, or is it .abc.br?

The short answer is that both answers can be useful, but they answer different questions. In strict DNS terms, the TLD is .br. In public suffix terms, the boundary that matters for registration and browser behavior is .abc.br.

DNS names are hierarchical. The rightmost label sits closest to the root zone. In google.abc.br, the root-zone TLD is .br. The label abc sits under .br, and google sits under abc.br.

That is why the IANA Root Zone Database lists .br as a country-code top-level domain. If your task is root-zone classification, the TLD answer is .br.

DNS hierarchy and registration policy are related, but they are not the same thing. Many country-code namespaces use fixed second-level categories such as .com.br, .org.br, .gov.br, .co.uk, or .ac.uk.

These categories exist because registries often use them for policy, eligibility, history, and administration. A company may register under .com.br, while a government body may belong under .gov.br. The important question becomes: where does registrant control begin?

A public suffix is the public registration boundary. It is the suffix under which separate people or organizations can register their own names.

Public suffixes are not only country-code categories. A gTLD like .com can be a public suffix. A ccTLD like .uk can be a public suffix. A category like .co.uk or .com.br can also be a public suffix. Private platform suffixes such as github.io and appspot.com can appear in the private section of the Public Suffix List as well.

For google.abc.br, the public suffix is .abc.br. That does not make .abc.br a root-zone TLD. It means .abc.br is the relevant public boundary for this domain.

The label abc can be confusing because .abc is also a delegated gTLD in the root zone. But in google.abc.br, the label abc is not acting as the TLD. Its position under .br changes the role it plays.

IANA / PTI maintains root zone records and TLD delegation data. gTLDs are managed by registry operators, often under contract with ICANN. For example, .com is operated by Verisign.

ccTLDs are managed by country-code managers, and their policies vary by country, local law, language, history, and governance model. For example, .br is associated with Registro.br / NIC.br, while .uk is associated with Nominet.

Public suffix entries are maintained through the Public Suffix List project. That list helps browsers, libraries, security tools, and data products understand where public registration boundaries sit.

If you register example.com, you usually control example.com and can create names such as a.example.com or a.b.example.com.

If you register example.com.br, the same idea applies below that registered name. You usually control example.com.br and can create names such as a.example.com.br or a.b.example.com.br.

The public suffix does not limit you to one subdomain level. It tells systems where public registration ends and registrant control begins.

Browsers care because cookies, storage, and site boundaries need a safe ownership model. A site should be able to share a cookie across its own subdomains, but it must not be able to set a cookie for an entire public suffix.

For example, a server under example.com.br may be allowed to set a cookie scoped to example.com.br. It should not be allowed to set a cookie scoped to com.br, because that would cross into unrelated registrants under the same public suffix.

A practical parser should separate the original name from the different boundaries inside it. Take api.shop.example.com.br as an example.

This is why tld alone is not enough for domain parsing. It tells you the root-zone category, but it does not tell you the public suffix, the registrable domain, or the subdomain labels.

A domain dataset can correctly group files by root-zone TLD. In that context, placing google.abc.br under a .br dataset is reasonable.

But a parser, search tool, analytics product, or security system should expose more than one field. Clear fields prevent users from confusing root-zone classification with ownership boundaries.

On DomainDataset, this distinction shows up across the main tools: the domain dataset page groups downloadable lists by root-zone TLD, the domain search page helps inspect individual names, and the new domain list and removed domain list pages make daily changes easier to review.

• TLD and public suffix are not always the same. They are the same in many simple cases, but not in every namespace.
• Everything after the last dot is not enough. That gives you the TLD label, not the full registration boundary.
• Public suffixes are not only ccTLD categories. gTLDs and private platform suffixes can also appear.
• Owning example.com.br does not limit subdomains. You usually control names below the registrable domain.
• Simple string splitting is unreliable. Use the Public Suffix List for domain parsing.

Use tld for root-zone classification. Use public_suffix for ownership, browser, and registration boundaries. Use registrable_domain for site-level grouping.

For google.abc.br, that means the TLD is .br, the public suffix is .abc.br, and the registrable domain is google.abc.br.

The lesson is not that one answer is right and the other is wrong. The lesson is that domain data needs precise vocabulary.

If the question is about DNS root-zone classification, .br is the right answer. If the question is about registration boundaries, browser behavior, cookies, or domain parsing, .abc.br is the important public suffix.