Jan Mikoláš
Glossary
DNS
DNS translates human-readable names into information needed for a network connection. It is hierarchical, distributed and cached, so a record change does not take effect everywhere immediately.
Short definition
The internet's phone book, not a web server or a URL.
DNS stores domain records in a tree of zones. A browser, application or email server first asks its resolver about a name such as shop.example.cz. The resolver can return a cached answer or progressively locate the authoritative nameserver for the zone, which is the source of the current record.
DNS handles a name and record type, not a URL path, HTTP method or API content. An A or AAAA record gives the client an address to connect to; only the URL then specifies the scheme and path, and the web server selects the application. DNS does not issue a TLS certificate or authenticate a user either.
What it is used for
Routing websites, APIs, email and verification records
A single domain can have different DNS records for the web, APIs, email and technical ownership verification.
- A and AAAA records for the IPv4 and IPv6 address of a website, API or other service
- a CNAME alias for a subdomain that should follow another canonical name
- MX records identifying the servers that receive email for the domain
- TXT records for SPF, DKIM, DMARC, domain verification or security policies
- delegation of a subdomain and separate management of its DNS zone by another team or provider
Practical example
A website, API and email on one domain
The example.cz domain hosts its website at www, its API at api and routes email through MX records. The API and website may have different A or AAAA records, but both services still need a valid TLS certificate and the correct virtual host after a connection is established. An SPF TXT record helps recipients determine which sources may send email on behalf of the domain.
Moving the API to a new load balancer begins by lowering the TTL in advance and verifying the new destination. After the change, the authoritative answer and a real HTTP call are checked, along with whether the old destination remains available long enough for resolvers with a previously cached address.
api.example.cz. 300 IN A 203.0.113.20
www.example.cz. 300 IN CNAME web.example.net.
example.cz. 300 IN MX 10 mail.example.cz.
example.cz. 300 IN TXT "v=spf1 include:mail.example.net -all"How it works
From a hostname to an authoritative answer
A resolver assembles the answer from the DNS hierarchy and caches it according to its TTL.
- The client asks a resolver The operating system or application asks the configured recursive resolver for a record, such as the A record for api.example.cz.
- A valid cache entry is used The resolver can return an answer obtained earlier until its TTL expires. This reduces latency and the load on authoritative servers.
- Root, TLD and delegation On a cache miss, the resolver progressively discovers the nameservers for the top-level domain and then the relevant zone. It does not search the entire internet; it follows the delegated authorities.
- The authoritative server responds The zone server returns a valid record and its TTL, or an answer stating that the name does not exist. The resolver stores it for a limited time.
- The client connects to the service With an IP address, the client can establish HTTP, SMTP or another protocol connection. The subsequent TLS handshake, Host header and application are separate layers.
Important records
The record type determines what information DNS returns.
Records should not be replaced with arbitrary aliases. Each type has a different purpose and operational impact.
A and AAAA
An A record contains an IPv4 address and an AAAA record an IPv6 address. The record does not say which website or application will respond; that depends on the service listening at the address.
CNAME
A CNAME makes an entire name an alias for another canonical name. It is not a general HTTP redirect mechanism, and a CNAME cannot be freely combined with other data records at the same name.
MX
An MX record lists email delivery targets and their priorities. Configuring a website through an A record does not automatically configure incoming or outgoing email.
TXT
A TXT record carries text data used for SPF, DKIM, DMARC or domain verification, for example. Its content follows a precise format defined by the relevant standard; it is not a free-form note.
TTL and propagation
A TTL says how long a resolver may cache an answer. A change to an authoritative record takes effect immediately at the authority, but clients may retain the old answer until their cache expires.
Benefits and limitations
Distribution improves resilience, while caching slows down change.
Benefits
- human-readable names independent of a specific IP address
- delegation allows separate management of zones and services
- TTL reduces resolver load and speeds up repeated lookups
- different record types connect the web, email and verification processes
Risks and mistakes
- a high TTL prolongs a move to new infrastructure or the correction of an error
- an unnecessarily low TTL increases reliance on resolvers and creates operational noise
- CNAME is not an HTTP redirect and cannot handle a change to a URL path
- incorrect nameserver delegation can disconnect an entire domain
- an unverified change to an MX or TXT record can disrupt email deliverability
Where to draw the line
Plan DNS as part of an infrastructure change, not as an afterthought.
Before moving an application to a new IP address or proxy, it is important to know the current TTL, keep the old destination available during the transition and verify the answer from the authoritative nameservers. Changing a record in one administration interface does not mean that every user immediately receives the new address. A critical change plan should include monitoring, a rollback and verification of both the website and email.
DNS is not the right place for application logic. It should not select a specific customer, conceal a broken API or replace authorization. Geographic traffic distribution, health checks or release strategies usually require a load balancer, reverse proxy or application with its own rules.
What to consider
Verify changes at the authority and from the perspective of a real client.
DNS is a shared operational dependency, so its configuration should be as traceable as an application change.
- record who manages the domain registration, nameservers and individual zones
- adjust the TTL well before a migration and retain the option to return to the original destination
- verify A, AAAA, CNAME, MX and TXT records with the correct query type rather than merely loading the website in a browser
- separate public DNS from internal service naming and restrict access to DNS administration
- change SPF, DKIM and DMARC with current senders in mind and monitor email deliverability
- do not infer application health from a DNS answer alone; also check TLS, the HTTP status and service logs
Common questions
How DNS affects service availability
Is DNS the same as a URL?
No. DNS resolves a hostname to records. A URL also contains a scheme, path, query and other parts needed to address a specific resource.
Why does a DNS change not take effect immediately?
A resolver or client may use an earlier cached answer until its TTL expires. The immediate change at the authoritative server must be distinguished from the gradual expiration of caches across the network.
Is CNAME a website redirect?
No. A CNAME is a DNS alias for a name. Redirecting one HTTP URL to another path or domain is handled by the web server through an HTTP redirect.
Is an A record enough for email?
No. Incoming email uses MX records, and reliable delivery of outgoing email commonly requires correctly configured SPF, DKIM and DMARC.
How I handle application boundaries in production
I treat domains, DNS, email and HTTP configuration as one connected operational whole.
For backends and integration services, I address availability, safe infrastructure changes and traceable problems across both public and internal networks.