Domain Names

Names are organized as labels in a hierarchy

A domain name is a name in the Domain Name System's hierarchy. What a person sees as a dotted string is a sequence of labels. In library.example.edu, the labels are library, example, and edu. Reading from the right, edu is the top-level domain in this illustration; labels to its left name increasingly specific parts of the hierarchy. ICANN's domain-name overview uses the same pattern: in whois.icann.org, org is top-level, icann is second-level, and whois is third-level. The labels are not merely decoration. Authority to create names at a lower level can be managed below the relevant dot, subject to the rules governing that part of the hierarchy.

The informal word subdomain is useful when a name is created below another domain. For example, an organization that controls example.org might create events.example.org for an event area and help.example.org for documentation. A subdomain is a naming choice, not an automatic feature that appears with every domain registration. It also does not require a particular word such as www. www.example.org is a familiar convention, but a hostname can use other labels or none before the registered name. A developer should record the exact hostname a project uses rather than assuming that typing www will always refer to the intended site.

The hierarchy does not mean that every dotted string has the same business meaning. The final label is a top-level-domain label in the public DNS hierarchy, but registration policies and the ability to create names can differ by top-level domain. This lesson uses common public-web examples to explain names; the next DNS lesson covers the separate process by which a system looks up those names.

Registration involves several different roles

For a generic top-level domain, domain registration is a process with distinct participants. A registrant is the person or organization seeking to register a name. A registrar processes registrations for customers, and a registry operator maintains the registry for a particular top-level domain. ICANN explains that an entity seeking a generic-top-level-domain name can use an ICANN-accredited registrar, and that the registrant's relationship with that registrar is governed by a registration agreement. That relationship is important because renewal notices, contact details, transfers, and account security are usually handled through the registrar account or its authorized reseller.

A registrar is not the same thing as the registry operator. The registrar is the customer-facing registration channel; the registry operator maintains the relevant top-level-domain registry. Nor is either role automatically a web host. A provider may offer registration and hosting in one product, which can make the roles look identical, but they remain conceptually separate. Separating them helps when a team wants to keep a domain name while moving a website to another hosting provider, or when it wants to add an address without changing the site's files.

Registration also is not a claim that a name will work forever without maintenance. A registration is subject to the governing agreement and applicable policy, and it is normally time-limited. Treat the registrar account as an important administrative asset: keep its contact information current, understand renewal terms, and limit access to authorized people. Those practical safeguards concern the management of a name; they do not require this lesson to teach DNS records, which belong to a later topic.

A domain is one component of a URL, not the entire address

A URL identifies the location of a resource and has several components. In https://docs.example.org:8443/guides/start?mode=student#next, the scheme is https; the authority contains the host docs.example.org and the optional port 8443; /guides/start is a path; the query starts after ?; and the fragment starts after #. MDN describes the domain in the authority as indicating which web server is requested, while the path identifies the resource path handled by that server. The Internet standard for generic URI syntax likewise treats the host as a subcomponent of authority and describes DNS-oriented registered names as labels separated by dots.

This distinction prevents a common deployment error: registering example.org does not create every possible URL beginning with that name. Someone still has to arrange for an appropriate service to respond for the hostname and to handle paths such as /about or /courses. ICANN explicitly distinguishes a domain name from a website and a URL, noting that hosting or another service is still needed to make an Internet presence functional. A path is also not a subdomain: blog.example.org/articles has the hostname blog.example.org and the path /articles. Changing one may require a different kind of configuration from changing the other.

Domain names are useful because they give people stable, readable identifiers to use in web addresses and related systems. They are not promises about the page's content, security, ownership of an ordinary-language word, or the server currently behind the name. Treat the name as a precise identifier in a broader set of technical and administrative arrangements.

Choose names and boundaries deliberately

A small project may use one hostname, such as example.org, for its public pages. As it grows, a team may choose a subdomain to separate a responsibility: status.example.org for availability information, docs.example.org for documentation, or courses.example.org for course material. The choice should reflect the project's needs, not a superstition that subdomains are always more professional or more secure. A subdomain may clarify ownership and navigation, but it still needs deliberate configuration and maintenance.

When documenting a web project, write down the registered domain, the public hostnames, the registrar account owner or organizational procedure, and the hosting responsibility. Do not put account credentials in source code or in a public repository. A useful troubleshooting question is therefore specific: “Is the issue with the registration, the hostname being used, the DNS configuration, or the web host?” This lesson gives the vocabulary to separate the first two questions; later lessons address resolution and hosting mechanics. Clear names and clear responsibility boundaries make routine changes easier to review.