Start with labels and the DNS hierarchy
A domain name consists of labels separated by dots. In www.example.com, the labels are www, example, and com. DNS organizes them as a hierarchy: com is under the root, example.com is under com, and www.example.com is under example.com. Reading from right to left helps you see which part of the name is being narrowed down.
The root is the top of that hierarchy. It has an empty label, represented in written DNS names by a final dot. Thus, www.example.com. explicitly includes the root, even though people usually leave that last dot off when typing a name in a browser. The dots within the name separate ordinary labels; the final dot represents the boundary at the root.
A label is not necessarily a server or a separate website. For example, mail.example.com might identify a mail service, while shop.example.com might identify a website. A name can also exist to organize other names without directly pointing to a web server. Its meaning depends on the DNS records associated with it and how an application uses those records.
How hostnames relate to domain names
A hostname is a domain name used to identify a host or service endpoint, such as www.example.com. People sometimes use “hostname” loosely for any name they enter into an application. In stricter contexts, hostname rules can be narrower than the rules for DNS labels in general. For instance, an underscore may appear in a DNS name used for a service record, but it is not normally part of a conventional hostname.
The leftmost label does not have a fixed meaning. www is a common convention for a website, not a DNS requirement. A site can use example.com, www.example.com, both, or another name. Similarly, mail in mail.example.com is only a label; it does not, by itself, create a working email service. The appropriate records and service configuration must also exist.
It also helps to separate a hostname from a URL. In https://www.example.com/help, the hostname is www.example.com. The https scheme and /help path are not DNS labels. DNS can help an application find an address for a name, but it does not define the page path on a website.
What “fully qualified” means
A fully qualified domain name, or FQDN, specifies a name all the way to the DNS root. Written explicitly, it ends with a dot: www.example.com. By contrast, www might be a short name whose full meaning depends on context. Inside the example.com domain, someone may intend www to mean www.example.com, but DNS cannot infer that from the word alone without a rule for completing it.
In everyday writing, www.example.com is commonly treated as a complete domain name even without its trailing dot. Many tools and applications can resolve it as expected. The distinction matters most where software may append another domain or where a configuration format gives special meaning to the final dot. In those settings, www.example.com. makes the intended root-anchored name explicit.
“Fully qualified” does not mean that the name has a working website, an address record, or any record at all. It describes how completely the name is specified, not whether a service is available.
Why a trailing dot matters in zone files and lookups
DNS zone files often interpret names without a trailing dot relative to the zone’s origin. If the origin is example.com., an entry named www may represent www.example.com. In many zone-file formats, writing www.example.com without the final dot can instead produce www.example.com.example.com. The exact behavior depends on the format and DNS management tool, so check how a particular interface handles relative names.
A similar issue can arise during troubleshooting. Some operating systems or DNS lookup tools apply a search domain to a name that is not explicitly root-anchored. A short query for printer might be tried as printer.example.com, for example. A trailing dot can help indicate that you want to test a specific full name rather than a name completed using local search settings. Tool behavior and resolver configuration can vary.
When reading a DNS control panel, do not assume that its “Name” field requires the entire domain. Some interfaces expect only a label such as www; others accept a full name and show a preview of the resulting record. Before saving, confirm the complete name the interface will create.
A simple way to check which name you mean
Work backward from the right. For api.example.com., the final dot marks the root, com is the top-level domain, example is the domain beneath it, and api is a label beneath example.com. If someone asks for a record at the “apex” of example.com, they mean example.com itself, without an additional label such as api or www.
When a DNS entry behaves unexpectedly, write out the full name you intended and compare it with the full name shown by your DNS provider or lookup tool. Check whether a relative name gained an unwanted suffix and whether you entered a URL where only a hostname was requested. Those small distinctions often explain why a record exists, yet an application is looking somewhere else.
