Introduction

In a prior article on the anatomy of domains, I briefly mentioned an effective TLD (eTLD) with the following example:

When someone registers example.co.uk, they are registering example under the .co.uk structure. In this context, .co.uk acts like an "effective TLD" (eTLD) or a public suffix. You don't register .co.uk itself; you register a name within the .co.uk public suffix.

A few sentences do not do justice to the nuance and importance of eTLDs. They are a fundamental concept for browser security and privacy. In research and investigations, they are critical for correctly identifying who is responsible for a the particular domain. This article will dive deeper into these concepts.

First, A Quick Review to Establish Terminology

To understand why eTLDs are a special case, let's quickly recap the standard domain hierarchy:

• At the top, you have Top-Level Domains (TLDs) like .com, .org, or .uk.
• Directly under a TLD, you register a Second-Level Domain (SLD). This is the part you "own" or, more accurately, license (e.g., example in example.com).
• You can then create subdomains under your SLD, like blog.example.com.

This simple model works perfectly for example.com, but it breaks down with example.co.uk. Is .uk the TLD and .co the SLD? Technically, yes, but that would imply the end of possible registrations and we know that is not true. As it is possible to register example.co.uk, we know the registrable boundary is one level deeper. This is where the concept of an eTLD becomes necessary.

The Key Concept: eTLD+1

The term eTLD+1 is by and large the most effective way to describe the part of a domain name that a single entity controls. It is the effective TLD plus the one label directly in front of it.

• For diggingdns.com, the eTLD is com, and the "+1" is diggingdns.
• For example.co.uk, the eTLD is co.uk, and the "+1" is example.
• For chad.ytmnd.com, the eTLD is ytmnd.com, and the "+1" is chad.

Why is this distinction so important? Because it forces you to think about where organizational boundaries lie and who is responsible for what.

Let's go back to example.co.uk. For any issue with this domain, you'd likely work with Nominet (the registry for .uk TLDs, including .co.uk) and the specific registrar where example.co.uk was registered (let's call it Simple Registrar).

But what if Example Co., the owner of example.co.uk, sets up a service where the public can create their own websites, like foo.example.co.uk and bar.example.co.uk? The eTLD+1 for these new sites is now foo + example.co.uk and bar + example.co.uk. If you have an issue with content on foo.example.co.uk, you now have to work with Example Co. first, before you even think about bothering Simple Registrar or Nominet.

In fact, when a domain shifts from being just a simple website into a platform offering subdomains to others (effectively turning itself into an eTLD), many issues that a registrar or registry might normally handle will get "punted" to that platform owner to mitigate.

The Master Resource: The Public Suffix List (PSL)

The Public Suffix List, hosted at publicsuffix.org, is a project initiated and maintained by the Mozilla community. It is a simple text file that maintains a list of all known public suffixes (eTLDs) in use on the Internet. It includes all official gTLDs and ccTLDs, as well as privately-owned domains that function as public suffixes (like blogspot.com or github.io).

The project's goal was initially to help browser creators solve the "supercookie" problem described above, by giving them a definitive list to enforce security boundaries. However, its purpose has since expanded, and not entirely by the PSL's choice. In the ongoing privacy wars between browsers and ad-tech, the PSL became one of many tools in the arsenal. When Apple introduced Intelligent Tracking Prevention (ITP) to limit third-party cookies, some tracking companies (including Facebook) began using a technique called "CNAME cloaking". This involved having a first-party subdomain (e.g., analytics.some-brand.com) use a CNAME record to point to a third-party tracking domain. Because the initial request was to a first-party subdomain, it could bypass some privacy rules. In response, some browsers and privacy tools began using lists like the PSL (and other sources) to identify known tracking domains, allowing them to treat the cloaked CNAME as a third-party tracker and apply stricter privacy rules.

You can view the full list here.

Why eTLDs Really Matter

Understanding the eTLD+1 concept isn't just an academic exercise. It has critical, real-world implications for security, privacy, and investigations.

1. For Browser Security: Preventing "Supercookies"

This was the original and most important reason for creating a list of eTLDs. Web browsers have a security policy that prevents a website from one domain (e.g., site-a.com) from accessing cookies set by another domain (e.g., site-b.com). However, a script on a subdomain (e.g., sub.example.com) can set a cookie for its parent domain (.example.com), which can then be read by other subdomains (like another.example.com).

Now, consider a service like github.io, where many different, unrelated users can create their own sites (user-a.github.io, user-b.github.io). If your browser only saw .io as the TLD, a malicious script on bad-guy.github.io could set a "supercookie" for the parent domain .github.io. This cookie could then potentially be used to track or interfere with your activity on your-repo.github.io—a massive security and privacy breach!

Because browsers know from the Public Suffix List that github.io is an eTLD, they treat bad-guy.github.io and your-repo.github.io as two completely separate websites, blocking this type of cross-domain cookie attack.

2. For Investigators: Identifying the Right Point of Contact

As our foo.example.co.uk example showed, knowing the eTLD is crucial for directing abuse reports correctly. If you find a phishing page on big-bank-phish.netlify.app, an investigator knows that .netlify.app is the eTLD for the Netlify platform. You don't (or, rather, shouldn't) contact the registrar of netlify.app; you report the abuse directly to Netlify's abuse team, as they are the ones who can take action against that specific customer site.

3. For Developers: Programmatically Understanding Domains

Developers building tools for domain analysis, website provisioning, or security scanning can't just find the registrable part of a domain by "splitting the string on the dots" (see: example.co.uk). A program needs a reliable way to know that the eTLD+1 of diggingdns.com is diggingdns.com but the eTLD+1 of diggingdns.co.uk is diggingdns.co.uk. Many open source libraries across major programming languages implment The Public Suffix List to provide the authoritative data to perform this logic correctly.

4. For Understanding Challenges: Governance and Abuse

As I ranted about here, registrars and registries for gTLDs have a contractual obligation with ICANN to mitigate DNS abuse (phishing, malware, botnets, etc.). Their decision to act often involves balancing the harm a domain is causing against factors like its age, function, and the potential for collateral damage.

However, this responsibility model gets complicated when the abuse originates from a domain operating under an eTLD. The challenges typically fall into two distinct categories.

Category 1: Service-Based eTLDs (The Responsibility "Hot Potato")

This is the most common scenario, involving eTLDs that are platforms offering a service, such as dynamic DNS, URL shortening, or free website hosting (e.g., your-site.blogspot.com or my-home.some-dynamic-dns-provider.net).

When abuse occurs on a subdomain provided by one of these platforms, the registrar and registry of the base domain (e.g., the registrar for blogspot.com) will almost always defer to the registrant, who, in this case, is the platform operator: Google. The responsibility for handling the abuse gets "punted" to the entity that has the direct relationship with the end user.

While the upstream registrar/registry retains the right to suspend the entire platform domain (e.g., blogspot.com), doing so is an extreme measure. The potential for massive collateral damage (harming thousands or millions of legitimate users) and the likelihood of legal action from the platform operator mean this only happens in the most egregious cases where the platform itself has become a systemic source of unmitigated abuse.

Category 2: "Registry-Like" eTLDs (A Governance Gray Area)

There is an additional, growing category of eTLDs that are not tied to a specific service but instead function like TLD registries themselves, selling domains to the public. At the time of this writing, examples include .it.com, .sa.com, ru.com and .za.com. These are domains registered within an existing TLD (like .com), but their operators have set up the infrastructure to sell "third-level" domains (e.g., your-company.it.com) through standard registrars like GoDaddy, often using major backend providers like CentralNic.

This model introduces several significant challenges from a governance and abuse perspective:

• The ICANN Governance Gap: The operator of .it.com is not a TLD Registry in the eyes of ICANN. They are simply the registrant of the it.com domain. Therefore, they are not required to sign the ICANN Registry Agreement, which binds official gTLD registries to a host of stringent policies regarding fair access, pricing, data escrow, and DNS abuse mitigation. They operate in a policy gray area, without the same contractual obligations as the operator of .biz or .info.

• Conflict in Abuse Handling: The operator of these eTLDs must police their own zones. When abuse occurs on phishing.it.com, the operator of .it.com is the entity responsible for taking action. Ideally, the operator will follow what their registrar or registry does. However, knowing that there is some cover because taking action against the domain will cause a significant business impact, the rules which apply to everyone else through contractual means may not be applied as judiciously as desired in these cases.

• Anti-Competitive Potential: These "registry-like" eTLDs can be registered at any participating registrar. This includes registrars that may be owned by or affiliated with the same entity that operates the eTLD itself. Without the non-discrimination rules that bind ICANN-contracted registries, these operators could potentially favor their own registrar with preferential pricing or faster integration, creating an unlevel playing field for competing registrars.

In essence, these entities can enjoy the economic benefits of acting like a TLD registry without being subject to the same comprehensive governance, oversight, and responsibilities that ICANN requires of official TLD operators. This makes them a complex and challenging space when abuse occurs.

Try It!

Conclusion

At first glance, an "effective TLD" seems like an obscure piece of internet trivia. But in practice, it's a critical concept that underpins browser security, user privacy, and effective domain investigation. Understanding the difference between a simple domain and a platform that acts as a public suffix is a key step in moving from a basic to an advanced understanding of the internet's structure. The next time you see a domain like my-site.blogspot.com, you'll know exactly what you're looking at: an eTLD+1 of my-site + blogspot.com.