How DNS Resolution Works

Start with the question being asked

DNS maps a name and a record type to resource records. Asking for an IPv4 address is different from asking for a mail exchanger or a TXT value. The same name can have several kinds of records, so “the DNS entry” is often too vague to describe a problem.

An application usually asks a local resolver rather than contacting every authority itself. That resolver may rely on a recursive service operated by an organization, an ISP, or another provider. The recursive service can answer from cache or seek an answer through the hierarchy. These roles and the distributed namespace are introduced in RFC 1034.

Delegation makes the hierarchy scalable

The namespace is a tree, but its administration is divided into zones. A parent zone can delegate a child to another set of authoritative servers. A resolver following referrals moves toward the authority for the requested name rather than downloading the entire database.

For an illustrative app.example.com lookup, the path can involve root information, the .com delegation, and the servers responsible for example.com. Cached information can skip much of that work. This is a conceptual sequence, not a promise that every lookup sends the same packets.

The practical consequence is that a fault can occur at several layers. A correct address on one authoritative server is insufficient if the public delegation points somewhere else. Compare the question, the authority, and the delegation before changing an address repeatedly.

Records and response codes carry different meanings

An A record contains an IPv4 address; AAAA contains an IPv6 address. A CNAME identifies an alias target. DNS messages have a header and sections for questions, answers, authority information, and additional records. Their wire representation is described in RFC 1035.

An empty answer is not always an error. The name may exist without the requested type. An NXDOMAIN response means the queried name does not exist in the relevant response context, while a server failure indicates that resolution could not be completed successfully. These differences matter when a deployment has an A record but an incorrect or missing AAAA record. Inspect both families instead of assuming that one successful query covers every client.

Caching is part of the design

A positive answer has a time-to-live that controls ordinary caching. Editing an authoritative record does not instantly remove earlier copies from every recursive cache. Lowering a TTL shortly before an urgent change also cannot shorten the lifetime of an answer already cached with the older value.

Negative answers can be cached too. RFC 2308 defines negative caching behavior and the role of authority information in it. This explains a common deployment surprise: a name queried before it existed may continue to appear missing for a while after it is created.

Plan changes around both kinds of cache. A change log should include the old TTL, the update time, and the exact answer observed from the authoritative service.

Inspect an answer without guessing

The following are read-only examples using BIND's dig. They query public documentation names and do not alter local DNS settings.

dig example.com A
dig example.com AAAA
dig example.com NS
dig +trace example.com A

The first queries show ordinary results through the configured resolver. The trace form follows delegation to help explain the hierarchy. Its traffic differs from an application's normal lookup and can be blocked on restricted networks. The BIND manual pages describe output fields, query options, and limitations.

Read the status, answering server, flags, record type, and TTL together. Saving only the returned address loses evidence that distinguishes a cached result from an authoritative one. When comparing two resolvers, send the same fully qualified question to each.

Encrypted DNS changes the transport

DNS over TLS protects the exchange between a client and its selected resolver using TLS, as specified in RFC 7858. DNS over HTTPS carries DNS queries and responses over HTTPS, specified in RFC 8484.

These transports protect that hop; they do not make the resolver disappear from the trust model. They also do not by themselves repair an incorrect authoritative record. A browser using its own encrypted resolver can receive a different answer from a command-line tool using the operating system's configured resolver.

That difference is a diagnostic variable. Record which resolver each application uses before treating conflicting answers as evidence that the entire network is broken.

A useful troubleshooting sequence

First reproduce the exact failing name and type. Then query the configured resolver, check the public delegation, and compare the authoritative answer. Finally, inspect whether the application is using a separate cache or resolver.

Keep DNS and connection tests separate. A correct name lookup says nothing about whether a firewall permits the resulting address or whether the server presents a valid certificate. Conversely, a direct connection to an IP address does not establish that a hostname resolves correctly.

The best incident note records each layer explicitly: the requested name, the returned addresses, the resolver, the response status, and the time. Those details turn “DNS sometimes fails” into a question that another person can reproduce.