Read a DNS name from right to left
A domain name is made of labels separated by dots. In www.example.com, the rightmost label, com, sits higher in the DNS hierarchy than example, and www sits below example. Reading from right to left shows the path from a broad part of the namespace to a more specific name. This structure lets DNS distribute responsibility instead of keeping every name in one central list.
At the top is the DNS root, written as a final dot in a fully qualified name: www.example.com. Everyday writing and most browser interfaces leave that dot off. The root is not a website or a domain someone registers. It is the starting point of the naming hierarchy, above top-level domains such as com and org.
From top-level domains to registered domains
A top-level domain, or TLD, is the label directly beneath the root. In example.com, com is the TLD and example.com is the domain name registered under it. Registries and registrars have different roles in managing registration, but registration alone does not tell a browser which server to contact. DNS records and delegation are also needed for the name to be useful.
Not every registration follows a simple two-label pattern. In some parts of the DNS namespace, registrations occur beneath an additional label. For that reason, counting dots is not a reliable way to identify what a person can register. The consistent rule is hierarchical: each label narrows the name beneath its parent, and the parent can direct DNS queries toward the servers responsible for a child.
Subdomains and hostnames add detail
Once an organization controls a domain such as example.com, it can use names beneath it. The familiar www.example.com is one possibility; support.example.com or shop.example.com are others. These names are often called subdomains or hostnames, depending on context. A label such as www does not have a special built-in meaning to DNS. It works because the domain’s DNS configuration supplies an answer for that name.
A hostname does not necessarily identify one physical machine. An address record can point a name toward an IPv4 or IPv6 address, while an alias record can direct lookup to another name. The service behind a name may also use several servers. DNS organizes and resolves the name; it does not, by itself, describe everything about the system that ultimately responds.
Names can have further levels, such as app.team.example.com. An organization may manage those names in the same DNS zone as example.com, or it may delegate a child zone, such as team.example.com, to another set of authoritative name servers. The visible dots show the name’s position in the hierarchy, but they do not reveal every administrative boundary.
Delegation connects the levels
DNS works because a parent can point a resolver toward the authoritative name servers for a child zone. In a simplified lookup for www.example.com, a recursive resolver may start with information about the root. The root directs it toward servers for com; the com servers direct it toward servers responsible for example.com; those servers can then answer for www.example.com or provide another referral where appropriate. The resolver returns the result to the application that asked.
These referrals are not the same as the final address answer. They tell the resolver where to ask next. The records that name authoritative servers are called NS records. Sometimes a parent also supplies address information needed to reach a named server; this is commonly called glue. Resolvers normally cache information they receive, so a later lookup often skips some of these steps until cached information expires.
Use the hierarchy to understand problems
When a name does not resolve as expected, consider which level controls the missing piece. If every name under a domain fails, check whether its delegation points to the intended authoritative servers and whether those servers can answer. If only www.example.com fails while other names work, focus on that specific name and its records. If a newly changed answer differs between users, cached records may be part of the explanation.
It also helps to separate a DNS name from the service using it. DNS may return an address for www.example.com even when the website itself is unavailable. Conversely, a working server does not help visitors if the name has no suitable DNS answer. Thinking in levels—from root to TLD to domain to individual name—provides a practical map for finding where to investigate.
