You type theunderstructures.com into a browser. The page arrives almost immediately. It feels as though the name itself belongs to the website and the browser simply knows where it lives.
It does not.
The browser begins with a human-readable label. Somewhere else, a set of machines holds records that point toward the current destination. Other machines know which operators are authoritative for parts of the naming tree. A registrar maintains the customer relationship. A registry maintains the master list for the top-level domain. The root zone points resolvers toward that registry. Hosting systems deliver the actual site.
The name works because these separate layers agree on how to refer the question onward.
The short answer
No single company, government or organisation controls the Internet’s entire address book. The public Domain Name System is globally coordinated but operationally distributed.
The Internet Assigned Numbers Authority functions maintain the root-zone delegation data. Independent root-server operators publish that data around the world. Each top-level domain has a registry. Registrars sell and manage registrations for customers. Registrants hold time-limited contractual rights to names. DNS operators publish records. Recursive resolvers find and cache answers. Networks route packets, and hosting providers serve content.
A domain name is not a place. It is a delegated label inside a shared naming system.
Read a domain name from right to left
Select each label to see what it means in the hierarchy.
understructures
This is the label registered under .com. It is not the website, server or content; it is a name whose zone can contain DNS records.
DNS was built because one list could not scale
The early Internet used a centrally maintained file called HOSTS.TXT. Machines copied the file so they could translate names into network addresses. That model became harder to maintain as the network grew: updates collided, distribution consumed resources and no single flat list could comfortably represent a rapidly expanding system.
RFC 1034, published in 1987, described the design that became the Domain Name System. Its key move was to turn the namespace into a tree and divide the database into zones. Each authoritative name server would hold only a portion of the whole. Resolvers could follow referrals from one zone to another.
This was more than a technical optimisation. Delegation allowed administrative responsibility to be distributed. The root did not need to know every website. It only needed to know where the next level’s authoritative information could be found.
Six roles, six different kinds of control
Select a participant. None can perform every other participant’s job.
IANA functions
Maintain the authoritative delegation details for top-level domains and coordinate changes under established policies and procedures.
Controls: which operator is delegated each TLD in the public root—not the content beneath every name.The root is an index, not a master list of websites
The DNS root zone sits at the top of the hierarchy. Its essential contents are referrals: records that tell a resolver which name servers are authoritative for top-level domains such as .com, .org, .my or an internationalised equivalent.
IANA’s official top-level-domain list dated 2 August 2026 contains 1,438 delegated TLDs. The root does not contain all 392.5 million domain registrations reported across TLDs at the end of the first quarter of 2026. That detail belongs lower in the tree.
Nor is “the root server” one machine in one building. Thirteen root identities are run by twelve independent organisations. Through anycast and many sites, those identities represent more than 1,500 server instances around the world. They answer with the same root-zone information.
The root is both small and widely replicated
Three scale figures describe different layers of the same system.
Delegation is the hidden organising principle
Suppose a resolver needs the address for www.example.com and has nothing useful cached. It can ask a root server. The root replies with a referral to the servers for .com. The resolver asks a .com server. That server replies with a referral to the authoritative servers for example.com. The resolver asks one of those servers for the record it needs.
Each parent zone delegates authority over a branch to the next zone. A registry operator for a generic TLD maintains the master database of registrations in that TLD and generates the zone file that allows those names to be found. The registrant, often through its registrar, chooses the authoritative name servers for the registered domain. The operator of those name servers publishes the domain’s individual records.
Follow one delegation
Advance through the three zones that cooperate to answer one cold lookup.
Registry, registrar and registrant are not synonyms
The domain market adds contracts to the technical hierarchy.
A registry operates the authoritative registration database for a TLD. For .com, that operator is Verisign. A registrar is the retail-facing organisation that accepts registrations, manages customer accounts and submits the necessary information to the registry. A registrant is the person or entity recorded as the registered name holder.
A reseller may sit between the customer and the accredited registrar. A DNS-hosting provider may be separate again. The web host can be another company. Paying one bundled invoice can make these roles look like a single service, but they remain different points of control and failure.
What your registration payment actually connects
The customer relationship and the technical chain overlap without becoming identical.
A registration agreement sets the holder’s rights, responsibilities, renewal terms and applicable policies.
The registrar provisions the name and maintains registration data in the TLD’s central database.
Generic-TLD registries and accredited registrars operate under agreements and consensus policies.
The authoritative service publishes A, AAAA, MX and other records for the domain’s zone.
You do not buy a domain forever
Everyday language says people “own” domains. ICANN’s registrant guidance is more precise: registration is closer to a renewable contractual right than permanent property. The registered name holder controls the registration for its term, subject to the agreement, applicable law and policies.
That difference becomes visible at expiry. A registrar must send prescribed reminders for generic TLD registrations. Depending on the registrar’s terms, there may be an auto-renew grace period. If a registration is deleted, generic TLD registries generally must provide a 30-day Redemption Grace Period during which the former holder can restore it through the registrar, usually for a fee. After the applicable stages end, the name can return to availability.
The website and email may stop long before the final release. A single missed renewal can therefore break identity, communication and trust even when the underlying servers still exist.
A registration has a lifecycle
Select a stage. Exact timing and options depend on the TLD, registrar and applicable policy.
Active term
The registrant controls the name through the registrar and can direct its name-server delegation, subject to locks, policies and the registration agreement.
The resolver does most of the walking
Your browser usually does not ask the root, TLD and authoritative servers itself. It asks a recursive resolver, often operated by an internet provider, enterprise or public DNS service. The resolver finds the answer and returns it to the device.
The resolver also caches what it learns. DNS records carry a time-to-live value telling caches how long an answer may be reused. If a valid answer is already cached, the resolver can reply without repeating the full chain. This is why a DNS change is not experienced everywhere at exactly the same moment: old answers remain usable until their caching periods expire.
Caching makes the system faster and reduces load. It also means “the DNS” is not one live database consulted from scratch for every click.
Compare a cold lookup with a cached answer
Toggle the cache, then run the simplified resolution.
DNS records are instructions, not content
An authoritative zone contains resource records. An A record maps a name to an IPv4 address. An AAAA record does the equivalent for IPv6. MX records identify mail exchangers. NS records identify authoritative name servers. A CNAME makes one name an alias of another. TXT records carry text used for many purposes, including email authentication and domain verification.
These records help applications find services. They do not contain the web page, mailbox or database. DNS can point a browser toward a hosting platform, but the hosting platform must still answer and serve the content.
Open the common record types
Select a record to see the instruction it gives.
An A record maps a name to a 32-bit IPv4 address. The example address comes from a range reserved for documentation.
DNSSEC adds proof, not secrecy
Ordinary DNS was designed to return answers, not to provide strong cryptographic proof that an answer is authentic. DNS Security Extensions allow zones to sign their data. A validating resolver can check a chain of trust from the root through the parent zone to the domain.
DNSSEC does not encrypt the query or hide which name is being requested. Its central promise is integrity and origin authentication: if signed data has been altered or cannot be validated, the resolver can refuse to return it.
The chain begins with a root trust anchor configured in validating resolvers. IANA is in the middle of a carefully staged root Key Signing Key rollover. The successor key was published in January 2025 and is scheduled to begin signing the root zone on 11 October 2026. Operators of validating resolvers must have the updated trust material.
A chain of signatures
Each signed parent vouches for the information needed to validate the child.
“The domain is down” can mean five different things
Because control is layered, a name can fail in several distinct ways.
A registrar may apply a client hold or lock under its agreement or an abuse process. A registry may apply a server-level status that overrides registrar changes. An authoritative DNS provider can suffer an outage or publish bad records. A resolver can block or rewrite answers under local policy. The DNS may work perfectly while the web host is offline.
Those failures have different scopes and remedies. Changing hosting does not cure an expired registration. Moving registrars does not automatically repair a broken zone. A resolver-level block may affect one network while the authoritative DNS remains unchanged for everyone else.
Where did the name break?
Select a failure to see the layer, reach and likely remedy.
The right to use the name lapsed
The registrar may interrupt resolution after expiry and the name may move through renewal, redemption and deletion stages.
Likely route: contact the registrar and use the available renewal or restoration process.A domain dispute is not an ownership search
Trademark owners sometimes face names registered to exploit their marks. For generic TLDs, the Uniform Domain Name Dispute Resolution Policy provides an administrative route alongside settlement and court proceedings.
A complainant under the UDRP must establish all three required elements: the disputed name is identical or confusingly similar to a mark in which the complainant has rights; the registrant has no rights or legitimate interests in the name; and the name was registered and is being used in bad faith. A strong trademark alone does not automatically win every domain.
WIPO administered 6,282 domain-name cases in 2025, its busiest year since the service began. By January 2026 it reported more than 80,000 cases over 25 years. The scale shows that domain registrations are not merely technical entries; they sit at the meeting point of identity, commerce, speech, fraud and law.
Build a UDRP complaint
Turn on the facts the complainant can prove. All three elements are required.
Country-code domains add national choices
The familiar ICANN contracts apply most directly to generic TLDs. Country-code domains such as .my, .uk or .jp are delegated to managers connected to their countries or territories and can use different eligibility, data, dispute and enforcement rules.
That means the global namespace is technically unified without being legally uniform. The public root can point to every delegated TLD while policies below those delegations vary. WIPO, for example, provides dispute-resolution services for participating country-code domains, but not every ccTLD uses the UDRP in the same form.
Governments can also regulate registrants, registrars, hosting providers and network operators within their jurisdiction. That legal power does not turn a government into the sole operator of the global DNS. It gives the government leverage over particular actors and layers.
So who controls the address book?
The answer depends on the question.
Who decides which operator manages .com in the public root? That is a root-zone delegation and policy question. Who holds example.com? The registry database records a registrant through a sponsoring registrar. Who decides where www.example.com points? The operator of the domain’s authoritative zone, acting for the registrant, publishes that record. Who supplies the answer to your laptop? Usually a recursive resolver. Who decides whether the web page appears? The hosting and application stack.
This separation is the source of both resilience and friction. No single machine contains the whole answer. No single institution can perform every role. But each layer has a narrow kind of authority, and the system works because those authorities interlock.
The Internet’s address book is not centrally owned. It is centrally coordinated where uniqueness is essential, then delegated wherever responsibility can be distributed.
Can you separate the layers?
Five quick questions. The point is not trivia; it is knowing who can actually fix a problem.
Sources and further reading
This explainer uses primary technical standards, official coordination material and current institutional data. Statistics were checked on 3 August 2026.
Follow the system to its source
Technical architecture, operational coordination, contracts, lifecycle, security and disputes.