Table of Contents
The Idea of a Hierarchy in DNS
Domain hierarchy describes how the Domain Name System is organized into levels. Instead of having one huge flat list of names, DNS arranges names in a tree. This tree structure makes it possible to delegate control, distribute data, and scale to billions of names across the entire internet.
In a domain hierarchy, each label in a domain name represents a level in the tree. The labels are read from right to left, from the highest level to the lowest. For example, in www.example.com, the rightmost part, com, is higher in the hierarchy than example, and example is higher than www.
The Root of the DNS Tree
At the very top of the DNS hierarchy is the root. The root represents the starting point of all domain names. Conceptually, every fully qualified domain name ends with a dot, such as www.example.com.. That final dot is the root.
In practice, users and most tools do not show the trailing dot, but DNS resolvers know that the name www.example.com actually belongs in the hierarchy under the root. The root has a special set of servers, called root servers, that know where to find information about the level directly below it, which is the Top Level Domains.
You do not register a name directly under the root unless you are operating a top level domain. For normal users and organizations the root is invisible infrastructure, but it is essential for starting the chain of lookups in the hierarchy.
Top Level Domains (TLDs)
Just below the root are the Top Level Domains, or TLDs. These are the highest visible layer for typical users, and they are the rightmost label in usual domain names, such as com in example.com or org in wikipedia.org.
There are two broad types of TLDs that are useful to distinguish in the hierarchy.
| Type of TLD | Examples | Typical Use |
|---|---|---|
| Generic TLDs (gTLDs) | com, org, net, info | General purpose, often global or brand focused |
| Country code TLDs (ccTLDs) | uk, de, jp, br | Tied to specific countries or territories |
There are also specialized or restricted TLDs such as gov or edu that follow particular rules about who can register them. From a hierarchy point of view they are still TLDs, just with policy limitations.
Each TLD is operated by a registry organization. That registry maintains the authoritative list of second level domains that exist directly under that TLD, for example example.com or example.org.
Second Level Domains
Under each TLD you find second level domains. These are the domains that individuals, companies, or organizations usually register. In example.com, the label example is the second level domain under the TLD com.
The second level domain often represents the main identity or brand of the owner in that TLD. Once you control a second level domain, such as example.com, you can create many more names under it by creating lower level domains or hostnames.
From the hierarchy perspective, the second level domain marks the point where control is usually delegated from the TLD registry to the domain owner. The domain owner then becomes responsible for managing DNS records under that second level domain.
Subdomains and Lower Levels
Below the second level domain, you can create subdomains. Subdomains are simply additional labels appended on the left side, further down the hierarchy. For instance, in mail.example.com the label mail is a subdomain of example.com. You can go deeper, such as eu.mail.example.com, where eu is a subdomain of mail.example.com.
The hierarchy is not limited to any fixed number of levels. You can have several nested subdomains as long as you stay within practical length limits. The important idea is that each dot separates levels, with each label to the left representing a lower level in the tree.
Subdomains can be used to organize services, locations, or departments. Even though they usually share the same second level domain, they can be managed by different teams or point to different servers, depending on how the owner chooses to use the hierarchy.
Fully Qualified Domain Names (FQDNs)
A fully qualified domain name is a complete name that includes all the labels from the host or service up to the root. In theory this ends with a dot, such as www.example.com.. In daily use people usually omit the final dot and simply write www.example.com.
The domain hierarchy is what makes a name “fully qualified”. If the name reaches all the way up to the root with each level defined, then it uniquely identifies a node in the DNS tree.
There is an important distinction between relative names and fully qualified names. A relative name might be just www inside a local configuration, which some software interprets relative to a default domain such as example.com. An FQDN removes this ambiguity because the hierarchy for that name is explicitly stated.
A fully qualified domain name (FQDN) specifies all labels from the specific host or service up to the root, for example www.example.com.. An FQDN uniquely identifies a single location in the DNS hierarchy.
Delegation in the Hierarchy
One of the most powerful aspects of the domain hierarchy is delegation. Delegation means that control over a part of the DNS tree is handed from one authority to another.
At the root level, the root zone contains records that delegate authority for each TLD to the correct TLD name servers. In turn, each TLD zone contains records that delegate authority for each second level domain to the name servers that the domain owner specifies. If the domain owner wishes, they can also delegate a subdomain to different name servers again.
You can imagine this as a chain of responsibility that moves downward. At each level, the current owner of a zone can decide who is in charge of specific parts below. The zones will be covered in more detail elsewhere, so here it is enough to link the idea of delegation directly to the hierarchical structure.
The hierarchy allows this delegation to be very flexible. A large organization can control example.com but delegate research.example.com to a separate team, and perhaps delegate lab.research.example.com to yet another group. The DNS system itself does not force any specific organizational pattern, it only provides the hierarchical structure that makes these choices possible.
Hierarchical Structure vs Flat Names
The hierarchical nature of DNS solves scaling and management problems that a flat list of names would create. In a flat system, each new name would compete for uniqueness in one giant pool, and a single authority would need to track everything. In the DNS hierarchy, uniqueness is only required within each level under a given parent.
For example, example.com and example.org can both exist, because they live under different TLDs. Similarly, two completely unrelated organizations can both have a subdomain called mail, as long as they are under different second level domains, such as mail.example.com and mail.othercompany.net.
The hierarchy also simplifies human understanding. When you look at shop.uk.example.com, you can infer some structure. You might guess that example.com is the main domain, uk refers to a region, and shop refers to a particular service. None of this is enforced by DNS itself, but many administrators use the hierarchy to create meaningful patterns.
Relationship Between Levels
Each step in the domain hierarchy has a parent child relationship with the level below it. A parent domain contains information about which child domains exist directly underneath it. For instance, the com TLD knows about example.com, example2.com, and others. The example.com domain knows about www.example.com, mail.example.com, and any other subdomains that the owner has created.
From a hierarchy perspective, each child inherits part of its identity from its parent. The right side of the name tells you its place in the larger tree. This relationship is what lets resolvers walk down the tree from one level to the next when they try to find information about a domain.
Because each parent is only responsible for the labels directly beneath it, the overall system is distributed. No single name server has to know every name on the internet. Instead, each level only maintains a manageable piece of the full hierarchy.
Limits and Practical Considerations
Even though the DNS hierarchy can, in theory, support many nested levels, there are practical limits. The overall length of a domain name in DNS is limited, and there are also limits on the length of individual labels. These constraints are usually not reached in ordinary situations, but they exist to ensure that names stay workable and that DNS messages remain within reasonable sizes.
In practice, administrators choose a modest number of levels in their hierarchy. Too many levels can become hard for humans to manage and remember, even though the technical system can handle them. A clear and purposeful structure within the domain hierarchy helps keep networks understandable for both users and operators.