The Domain Name System, or DNS, gives applications a stable naming system for network resources. A name such as api.example.com is easier for people and software to work with than an IP address, and its owner can change the infrastructure behind it without changing the name.

DNS is often described as the Internet's phone book, but that analogy hides its most important design choice: DNS is not one giant directory stored on one server. It is a distributed, hierarchical database. Responsibility begins at the root and is delegated through progressively smaller parts of the namespace.

This structure allows different organizations to manage their own names while remaining part of one globally consistent naming system. It also explains why a DNS failure can affect one hostname, an entire domain, or a whole branch of domains depending on where the hierarchy breaks.

The global DNS namespace is organized as an inverted tree. Its root sits at the top, and each level below it adds a label to the left of the name.

Consider the fully qualified name:

Read from right to left, its hierarchy is:

The components between dots are called labels:

Each label identifies a node below its parent. com is below the root, example is below com, and store is below example.com.

The empty label after the final dot represents the root. DNS software usually allows people to omit that dot, so these commonly refer to the same global name:

The second form is explicit: the name is complete and ends at the DNS root.

A fully qualified domain name, or FQDN, identifies a node by its complete path to the root. The trailing dot is the unambiguous textual form:

A name without a trailing dot may be treated as relative in some tools and configuration files. A system configured with the search domain corp.example.com might expand:

into:

It might also try more than one search suffix. This is why a short name can work on an office laptop but fail from a production server: the two systems may be expanding it differently.

Web browsers and many application APIs usually accept names without a trailing dot and treat familiar multi-label names as global names. DNS configuration files and diagnostic tools are more sensitive to the distinction. When precision matters, the final dot makes the intent explicit.

DNS compares ordinary names without regard to letter case. For lookup purposes, API.Example.COM and api.example.com identify the same DNS name. Applications may preserve the spelling they were given, but they must not depend on case to distinguish DNS names.

Each label can contain at most 63 octets in the DNS wire format. A complete encoded name can occupy at most 255 octets, including label-length fields and the root label. In everyday use, the practical lesson is simple: dots separate bounded labels; they are not arbitrary characters inside one long name.

The dots in a domain name express DNS hierarchy. The slashes in a URL path do not.

For this URL:

DNS is concerned with:

The application server interprets:

DNS reads the name hierarchy from right to left, starting at the root. The web application normally reads the path from left to right after the request has reached the service.

The label www has no special meaning to DNS either. www.example.com, api.example.com, and payments.example.com are simply different names under example.com. Any special role comes from how the domain owner configures and uses those names.

A DNS name also does not necessarily identify one physical computer. It can name a service, a group of endpoints, a mail destination, or another piece of published information. The hierarchy organizes names and authority; it does not require a one-to-one relationship between names and machines.

The public DNS hierarchy is commonly described using four levels.

The Root

The root is the top of the DNS namespace. It is written as a single dot:

The root does not contain the address of every host on the Internet. Its main job is to identify where responsibility for top-level domains begins.

DNS resolvers must know how to reach the root without first asking DNS where the root is. They are therefore configured with root hints: a bootstrap list containing the names and addresses of the root server system.

There are 13 logical root server identifiers, named from A through M. This does not mean the world depends on only 13 physical machines. Each identifier is provided by distributed infrastructure with many server instances. From the hierarchy's perspective, however, they serve the same root zone.

Top-Level Domains

A top-level domain, or TLD, is directly below the root. Examples include:

Some TLDs are generic, such as .com, while others are country-code TLDs, such as .in and .uk. The DNS hierarchy treats both as children of the root.

The root delegates responsibility for each TLD to that TLD's authoritative name servers. The .com servers know about delegations beneath .com; they still do not store the final data for every hostname ending in .com.

Registered Domains

Organizations and individuals commonly register names beneath a registry-controlled suffix:

People often call example in example.com the second-level domain because it is one level below .com. That terminology describes label position, but it does not always identify the registrable boundary.

For example:

Here, .uk is the TLD, but registrations are commonly made under co.uk. Registration policy and DNS hierarchy are related but not identical. Counting labels alone cannot reliably tell which organization controls a name.

Subdomains and Names

The owner of a domain can create more names beneath it:

Every node below a domain belongs to its DNS subtree. In that broad sense, both api.example.com and payments.internal.example.com are subdomains of example.com.

An organization can manage these names together or delegate part of the subtree to another team or DNS provider. That administrative boundary is expressed through zones.

A domain is a node in the namespace together with the branch beneath it. A zone is the portion of that namespace managed as one authoritative unit.

The distinction appears when responsibility is delegated.

Suppose the example.com organization manages most names itself but delegates dev.example.com to its development platform team:

dev.example.com is still part of the example.com domain tree, but it is no longer part of the example.com zone's authoritative data. It begins a separate zone controlled by a different authority.

The point where a child zone separates from its parent is called a zone cut. The top of a zone is its zone apex. In this example:

A zone can therefore look like a subtree with delegated branches removed. The example.com zone contains www.example.com and api.example.com, but the detailed data below dev.example.com belongs to the child zone.

This separation makes DNS administration scalable. The organization controlling .com does not need to edit api.example.com, and the team controlling example.com does not need to edit build.dev.example.com. Each authority manages its own zone.

A parent zone connects a child into the hierarchy through delegation. It publishes the names of the authoritative servers responsible for the child zone. DNS represents this delegation using name server, or NS, records.

For example, the .com zone might delegate example.com to:

The parent does not normally copy all of example.com into .com. It keeps only enough information to direct a lookup toward the child's authority.

The child zone also publishes its own authoritative server information. Parent-side and child-side configuration should agree. If the parent points to obsolete servers or the listed servers are not authoritative for the child, the delegation is broken even if the child zone's other data is correct.

Delegation can occur at any suitable boundary:

It is not necessary to create a separate zone for every label. api.example.com can simply be a name inside the example.com zone. A new zone is needed only when the operator wants a distinct administrative and authoritative boundary.

Delegation creates a potential circular dependency when a child zone's authoritative server name is inside that same child zone.

Suppose .com delegates example.com to:

To ask ns1.example.com about example.com, a resolver first needs the IP address of ns1.example.com. But obtaining that address appears to require asking the example.com server that the resolver is still trying to find.

The parent avoids this loop by including glue: address information for the in-domain name server alongside the delegation.

Conceptually, the referral contains:

Glue is bootstrap information. The authoritative address data still belongs to the child zone, and the corresponding child data should be kept consistent with the glue held by the parent.

Glue is not required merely because a delegation exists. If example.com uses ns1.dns-provider.net, the resolver can find that server's address through the separate dns-provider.net branch of the hierarchy.

Suppose a resolver needs information about:

The DNS hierarchy provides a chain of authority:

This is a progression from broad authority to specific authority:

A response that points toward another authority is a referral. A response from a server responsible for the requested zone is an authoritative answer.

The chain describes where the data is governed. It does not mean a user's laptop must contact every authority directly for every lookup. Applications usually ask a resolver service, which performs or arranges the necessary work on their behalf.

The hierarchy also does not require every level in the name to be a separate zone. If store.example.com has not been delegated, the example.com authority can answer directly about api.store.example.com. The four labels describe namespace depth; they do not prove that four independently managed DNS zones exist.

The DNS hierarchy solves several problems at once.

Distributed Administration

No central operator needs to approve every hostname. The root delegates TLDs, registries delegate registered domains, and domain owners can delegate internal branches. Each operator changes only the zone it controls.

Smaller Authoritative Datasets

An authoritative server needs the data for its zones, not a copy of the entire global namespace. Root servers focus on the top of the hierarchy, TLD servers focus on delegations below their TLDs, and domain authorities focus on their own zones.

Replication Within Each Zone

A zone is normally served by multiple authoritative servers. They expose the same logical zone data from more than one endpoint, reducing dependence on a single machine or network location.

Failure Containment

An incorrect record for one hostname may affect only that name. A failure at a zone's authoritative servers can affect the entire zone. A broken parent delegation can make the child unreachable even when the child servers themselves are healthy.

The blast radius follows the authority boundary. This is one reason the difference between a name, a domain, and a zone matters operationally.

When a domain fails to resolve, the hierarchy helps identify which organization or configuration owns the problem.

Consider api.dev.example.com:

These are scope deductions, not guarantees. Local overrides, cached information, split internal and public DNS views, and application behavior can change what a particular client observes. Still, mapping the failing name to its zone boundaries is the right starting point.

The hierarchy also explains a common deployment mistake. Creating data for api.dev.example.com in the parent example.com zone has no effect if dev.example.com is delegated. Once the zone cut exists, authoritative control for names beneath it belongs to the child zone.

The root is not a database of every Internet hostname. It primarily directs lookups toward top-level-domain authorities.

Thirteen root server identifiers do not mean thirteen physical servers. The logical identities are delivered by much larger distributed infrastructure.

Every dot does not represent a separate DNS server or zone. Labels define the namespace; delegation defines authority boundaries.

A domain and a zone are not always the same set of names. A domain includes its descendants, while a zone excludes descendants delegated to child zones.

“Second-level domain” does not always mean “registrable domain.” Registry policy can place registrations beneath suffixes containing more than one label.

The trailing dot is meaningful. It explicitly marks a name as complete through the DNS root.

www is not a special DNS keyword. It is an ordinary label whose behavior comes from configuration.

A DNS name is not necessarily one server. It names a node in the DNS namespace and can represent different kinds of network information.

The parent usually points to the child rather than storing the child's contents. Delegation distributes authority instead of duplicating the complete child zone.

Healthy child servers cannot repair a broken parent delegation. Clients first need a valid path through the hierarchy to discover those servers.

DNS organizes its namespace as a tree from the root through top-level domains, registered domains, and more specific names. An FQDN describes a complete path to the root, made explicit by a trailing dot. Labels show namespace structure but do not necessarily mark administrative boundaries.

A domain is a branch of the tree; a zone is a portion managed as one authoritative unit. Delegation creates a zone cut and points from a parent to a child's authoritative servers. Glue provides bootstrap addresses when a delegated server's name lies inside the child zone.

Root, TLD, and domain authorities hold progressively narrower responsibility rather than copies of the entire database. A failure's position in this hierarchy often reveals its owner and blast radius.

DNS scales through delegated authority: each level knows enough to direct a lookup toward the next responsible level.