DNS: How Name Resolution Works

What DNS is

DNS is the distributed, hierarchical system that lets applications use names instead of hard-coding addresses. It stores many kinds of data, not just “hostname to IPv4 address” mappings.

A user may type a domain name, but the final answer can involve recursive resolvers, delegations, authoritative servers, cache entries, aliases, and multiple record types before the application obtains usable data.

DNS is therefore both a naming system and a dependency for almost every modern service. A network can have perfect IP reachability and still feel broken if name resolution fails.

Hierarchy

The DNS namespace is hierarchical. The root sits at the top, followed by top-level domains and progressively more specific labels. Authority can be delegated at boundaries so different organizations or teams manage different parts of the namespace.

A fully qualified domain name identifies a location in that hierarchy. The resolver does not need one server that knows everything; it follows referrals until it reaches a server authoritative for the requested data.

This design scales globally because responsibility is distributed. It also means a delegation error can break one branch even while the parent and unrelated domains continue working normally.

Recursive and authoritative

A recursive resolver accepts a client query and works to obtain the answer, using its cache whenever possible. An authoritative server answers for zones for which it has authority.

The distinction matters during troubleshooting. If a local resolver is unreachable, clients fail even though authoritative servers are healthy. If the authoritative data is wrong, switching to another recursive resolver may not solve the underlying problem.

Ask which component produced the response, whether recursion was requested or available, and whether the answer is authoritative or cached. Tools such as dig make these details visible.

Main record types

Common records include A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail routing, NS for authoritative name servers, TXT for arbitrary text, SRV for service discovery, and PTR for reverse lookups.

Each record type has its own semantics. An MX record points to a hostname rather than directly to an IP address, while a CNAME makes one owner name an alias of another canonical name. PTR records live in reverse-mapping zones rather than being a magical inverse of every A record.

When diagnosing an application, query the record type the application actually needs instead of relying on a generic lookup.

Zones and delegation

A DNS zone is an administrative portion of the namespace served authoritatively. A zone is not necessarily identical to a domain subtree because parts of that subtree can be delegated to other authoritative servers.

Delegation uses NS records at the parent, and glue records may be required when a delegated server name would otherwise create a circular dependency. Incorrect NS sets, missing glue, or lame delegations can create failures that look inconsistent across resolvers.

Always verify both the parent delegation and the child zone. Looking only at the child server can miss a problem in how clients are referred to it.

Cache and TTL

Resolvers cache answers to reduce latency and load. The TTL tells a cache how long a record may normally be retained before it must be refreshed.

This explains why DNS changes are not necessarily visible everywhere at the same moment. A resolver that cached the previous value can legitimately keep serving it until expiry. Negative answers can also be cached.

Plan changes with TTL in mind. Lowering TTL shortly before a migration can reduce the lifetime of old answers, but lowering it after resolvers already cached a longer TTL does not retroactively invalidate those entries.

UDP and TCP 53

Traditional DNS uses port 53 over both UDP and TCP. UDP is common for ordinary queries, while TCP is used when the protocol or response requires it and for mechanisms such as zone transfers.

Modern DNS can also be carried over encrypted transports such as DNS over TLS or DNS over HTTPS, but that does not change the underlying DNS data model.

A firewall policy that permits UDP/53 but blocks required TCP/53 can create selective failures. Do not assume one successful small query proves every DNS path is valid.

DNSSEC

DNSSEC adds cryptographic signatures so a validating resolver can verify the authenticity and integrity of DNS data within a chain of trust. It does not encrypt ordinary DNS queries.

Validation depends on correctly published keys, signatures, delegation signer information, and time. An expired signature or broken chain can make a zone fail for validating resolvers even if non-validating queries appear to work.

Troubleshooting DNSSEC therefore requires checking both ordinary record data and validation state. Treat “record exists” and “record validates” as separate questions.

Split DNS

Some organizations intentionally return different DNS answers depending on where the query originates. Internal clients may resolve private service addresses while external clients receive public addresses or no record at all.

This can be useful, but it increases operational complexity. A laptop using a public resolver while connected to an internal network may see different data from a managed corporate endpoint.

Document the views, resolver policies, and expected answers. Otherwise an intentional split can be mistaken for cache corruption or propagation delay.

Troubleshooting

Start by separating name resolution from IP connectivity. Query a known resolver directly, then query the authoritative path if necessary. Record the response code, record type, TTL, and server that answered.

Check NXDOMAIN, SERVFAIL, timeouts, delegation, authoritative data, DNSSEC validation, and cache behavior. Compare a failing resolver with another resolver only to narrow the scope—not as proof that the zone is correct.

Use packet captures when transport is suspect. They can reveal retransmissions, truncation, TCP fallback, or queries being sent to an unexpected server.

Relationship with DHCP

DHCP commonly tells clients which DNS resolvers to use and may also deliver domain or search-suffix information. A DHCP issue can therefore present to the user as “DNS is broken” even when the DNS servers themselves are healthy.

When a newly connected host resolves nothing, inspect both its address configuration and its resolver configuration. Compare the received DHCP options with a working client on the same network.

Dynamic DNS integrations may also update records when DHCP leases change, but that behavior depends on the environment and should be documented explicitly.

References

RFC 1034 and RFC 1035 define the core DNS concepts and implementation model. Later RFCs extend record types, EDNS, DNSSEC, negative caching, internationalized names, and encrypted transports.

For operational work, combine protocol references with the documentation of your recursive resolver, authoritative server, and DNS hosting platform.

How to continue

Continue with NTP. If client resolver settings arrive through DHCP, revisit the DHCP guide. For path problems between clients and resolvers, return to routing.

Practice by querying A, AAAA, MX, NS, TXT, SRV, and PTR records and comparing recursive and authoritative responses.

Operational example

Users can reach a web server by IP address but not by name. The recursive resolver responds, but the application hostname returns NXDOMAIN. Querying the authoritative server shows that a recent zone edit accidentally removed the record.

Because IP connectivity and the resolver transport were both proven first, the investigation stays focused on DNS data rather than switching or routing. Restoring the record fixes the service, while cache TTL explains why some clients recover sooner than others.

The key habit is to identify which layer produced the failure: client configuration, resolver, delegation, authoritative zone, validation, or cache.