Jan Mikoláš
Glossary
Domain name
A domain gives a service a memorable name. It is not itself a URL, web hosting or an IP address; those layers are connected only through DNS, the network and a web server.
Short definition
A hierarchical service name, not a ready-made website.
A domain name is a sequence of labels separated by dots in the DNS hierarchy. In api.shop.example.cz, cz is the top-level domain, example is the domain registered beneath it, and shop and api are further subdomains. The notation is usually read from right to left: the farther left a label appears, the more specific the name is within that branch.
DNS maps the name to records, but the name alone does not say which application will respond or where its code is stored. One domain can have multiple IP addresses, and one IP address can serve many domains. On the web, the name is also used to verify the HTTPS certificate and to route the request based on the HTTP Host header.
The problem it solves
It separates a readable service address from changing infrastructure
A domain allows a server, proxy or hosting provider to change without requiring people and integration clients to update the links they use.
- a public website at www.example.cz, an API at api.example.cz and a separate administration interface at admin.example.cz
- DNS records for the web, email, domain ownership verification and email security policies
- sensible separation of environments, such as test.example.cz from the production name
- an HTTPS certificate that the client verifies against the name in the URL
- predictable URLs for applications, documentation, OAuth callbacks and webhook endpoints
Practical example
Breaking down an e-commerce API name
The name api.shop.example.cz may belong to an e-commerce API. The name alone does not reveal whether the API runs on a single server, behind a load balancer or in the cloud. That is determined by the current DNS records and the infrastructure behind them.
The same organisation can use www.example.cz for its public website, admin.example.cz for administration and mail.example.cz for email infrastructure. Each name can point to a different technical destination and have a different operational owner.
Domain name breakdown
.cz doména nejvyšší úrovně
example.cz registrovaná doména
shop.example.cz poddoména pro konkrétní část
api.shop.example.cz hostname API službyHow it works
From registering a name to an available web service
A domain must first be registered and then correctly connected to DNS and the application environment.
- The registrant chooses and registers a name A registrar arranges registration with the registry for the relevant top-level domain. The registrant, registry, registrar, and DNS operator need not be the same organisation.
- Nameservers and the DNS zone are configured Delegation identifies the authoritative nameservers. Their zone contains records for the web, email and verification purposes.
- The client resolves the hostname A browser or API client asks a DNS resolver for the record for api.shop.example.cz and receives one or more IP addresses, for example.
- The client establishes a connection It connects to the HTTP service at the destination IP address and port. With HTTPS, it compares the name in the URL with the server certificate.
- The server selects the application Based on the hostname and path, a web server or reverse proxy forwards the request to the correct application. DNS neither performs HTTP redirects nor knows the URL path.
Important related concepts
A name, its management and its records play different roles.
A precise distinction prevents mistakes when migrating hosting, renewing a domain or diagnosing an outage.
TLD, registered domain and subdomain
A top-level domain such as cz sits immediately below the DNS root. Beneath it, example.cz can be registered, and the owner or zone administrator can usually create subdomains such as www or api.
Hostname and FQDN
Hostname commonly refers to the name of a machine or service. In strict DNS notation, a fully qualified domain name can end with a dot, as in api.example.cz.; the trailing dot is omitted in ordinary web use.
Registry, registrar and registrant
The registry maintains the rules and database for a TLD, the registrar provides the registration interface, and the registrant is the party entitled to manage the domain. Specific rules vary by TLD.
DNS zone and nameservers
A zone is an administratively managed part of the DNS namespace. Its authoritative nameservers provide records; a change at the registrar may not be made in the same place that actually serves the zone.
IDN
Internationalised domain names allow characters outside basic ASCII, but can create deceptively similar-looking names. The complete hostname should always be checked in sensitive links.
Benefits and limitations
A stable name makes change easier, but requires careful ownership and DNS management.
Benefits
- people and applications use a readable name instead of a changing IP address
- subdomains separate the website, API, administration and email
- DNS can point to multiple destinations or support a gradual infrastructure change
- the name forms part of HTTPS server verification and the public technical contract
Limitations and common mistakes
- failing to renew a registration can disconnect both the website and email
- registering a domain does not automatically create hosting or mailboxes
- DNS caching means that clients do not see a change immediately
- a subdomain is not a directory such as /admin and does not follow the same cookie or TLS rules
- similar Unicode names can facilitate fraudulent links
Practical boundaries
Treat a domain as a long-term public interface, not a hosting detail.
The name should be understandable, managed through an account accessible to the responsible organisation, and documented together with its renewal date, registrar and nameservers. When changing hosting, the team needs to know which DNS records support the website, API and email, and whether a certificate or an external integration callback depends on the domain.
Creating another subdomain merely as a substitute for a clear application structure is rarely helpful. A subdomain has network implications: DNS, TLS, cookies, CORS, monitoring and access rules are often configured separately. For a small website, one domain with clear paths may therefore be simpler than many technical names.
What to consider
Managing a name is both an operational and security responsibility.
A change to DNS or the domain registrant can have the same impact as a failed application deployment.
- keep a record of the registrant, registrar, renewal dates and access to DNS administration
- plan DNS changes for websites and APIs together with HTTPS certificates, the reverse proxy and monitoring
- separate production, test and internal names according to genuine operational needs
- know the TTL for critical changes, verify the authoritative answer and retain a rollback option
- do not treat the domain or knowledge of the URL as proof that a user is authorized to access the application
- verify the exact hostname in links, especially for IDNs or redirects to an external service
Common questions
Common misconceptions about domains
Is a domain name the same as a URL?
No. A domain is only the name in the host part. A URL also contains an https scheme, path, query string and optional fragment, for example.
Does registering a domain also give me web hosting?
Not automatically. Some providers sell both services, but name registration, DNS, hosting, email and application management are separate services.
Can a domain have multiple IP addresses?
Yes. DNS can return multiple A or AAAA records for redundancy, a CDN or a gradual infrastructure transition, for example.
Is a subdomain the same as a folder in a URL?
No. api.example.cz and example.cz/api are different addresses with different DNS, TLS and often operational rules.
How I handle application boundaries in production
I design the public name, HTTPS and infrastructure as one connected whole.
For APIs and web applications, I address service availability, safe infrastructure changes and a clear public entry point from DNS all the way to the application.