The DNS Resolution Process, Step by Step, and the Part Most Diagrams Get Wrong

The DNS resolution process is the sequence that turns a name you typed into an address your computer can open a connection to. It is usually drawn as a single chain: your resolver asks a root server, which passes the question to a TLD server, which passes it to the domain's own server, and the answer comes back down the same line.

That diagram is on almost every page about this subject, and its first step has been wrong for years. A modern resolver does not send the name you typed to a root server. It sends one label. There is a Standards Track RFC that says so, and once you know it, the trace you get from your own machine finally makes sense.

So this guide gives you the process in order, with a diagram drawn the way it actually happens, and the sources for each claim. Where a step is commonly described wrongly, it says so and quotes the specification instead.

Author: Robert Harrison OSINT & Network Utility Expert

My position is that this topic is explained from memory rather than from the specification, and the copies have drifted. Three claims in the inherited summary are contradicted by Standards Track documents: that your resolver sends the whole name you typed to a root server, that recursion is the mandatory mode, and that TCP on port 53 is there for zone transfers. Anyone who had opened RFC 9156, RFC 1034 or RFC 7766 would not still write them.

The honest limit is that I cannot tell you what your particular resolver does, because behavior varies by implementation and by configuration. What I can do is give you the specification, tell you where implementations commonly differ from it, and hand you the commands that report what your own resolver is doing instead of what a diagram claims. That is better than a picture you have to take on trust.

What the DNS Resolution Process Actually Is

Domain names exist in a tree. Reading a name right to left gives you the path down it: the root, then com, then example, then www. Nothing holds the whole tree, because each level only knows who is responsible for the level beneath it, and delegating it that way means a domain's owner publishes their own records without anybody upstream being told. Resolution is the act of walking that chain.

So "how does DNS resolve domain names to IP addresses" has a structural answer before it has a procedural one. It resolves them by asking a sequence of servers that each know one thing only, which is who is responsible next.

DNS is the protocol that translates a domain name into an IP address, and the domain name resolution process is the name for the walk it performs. Next, who takes part in that walk and what each of them can actually tell you.

Who Takes Part, and What Each One Can Actually Answer

Five kinds of participant appear in a full DNS name resolution process, and the useful way to tell them apart is by what each one can answer rather than by name. Only one of the five holds the record you asked for. The other four either refer the question onward or hand you a copy of somebody else's answer.

Your own machine runs a stub resolver, the small piece of the operating system that takes a name from an application and hands back an address. It asks one configured server and waits, which is why a single wrong entry in your network settings breaks name resolution for every application at once.

The distinction that matters most is the last one. Only the authoritative server holds the record itself; everything else you receive is a reproduction with a remaining lifetime attached. That includes the answer that a name does not exist, which most explanations get wrong: RFC 2308 requires a server answering from a cached negative to attach the stored SOA record "with the TTL decremented by the amount of time it was stored in the cache", so a no-such-name is served from cache exactly as an address is.

A resolver also has to start somewhere, and RFC 1034 calls that starting point the safety belt. The RFC 1034 description of that starting file is plain: "when the resolver has no idea what servers to ask, it should use information from a configuration file that lists several servers which are expected to be helpful", and in 1987 "the usual choice is two of the root servers and two of the servers for the host's domain." A modern root hints file is that idea with the local half dropped, and it is still the only part of DNS not discovered through DNS.

The DNS Resolution Process Step by Step

These are the DNS resolution steps for a name your resolver has never seen before, in the order they occur. Read the line in each box that says what that server receives, because the query is the part the usual diagram gets wrong.

Every blue arrow is a question the recursive resolver sends and every green arrow is what came back to it. No server in the chain speaks to the next one: the resolver returns to its own place after each reply and asks the next server itself, which is what a single top-to-bottom chain gets wrong.

The recursive resolver is where most of the speed comes from. One serving thousands of users already holds the referrals for com and for every popular domain, so most lookups skip the root and the TLD altogether and begin at the domain's own servers. A full walk from the root is the uncommon case rather than the normal one.

Five record types account for almost everything you will meet in a trace.

A browser asking for a name typically requests the A and AAAA records together rather than in sequence, which is why a site can be reachable over one address family and not the other without anything appearing to fail. The structural differences between them are in IPv4 vs IPv6 headers. The CNAME row is routinely overstated: RFC 1034 has the server "change QNAME to the canonical name in the CNAME RR, and go back to step 1", which restarts the lookup for the new name, not the walk from the root, and the target is usually already in cache.

The authoritative server also returns more than an address. It returns the record with a time to live, the publisher's instruction for how long anyone may keep the answer, and that number decides when a change of yours becomes visible. DNS propagation delay and TTL is where that side of it belongs. Next, the step in the diagram that almost every other version draws incorrectly.

The Step Most Diagrams Get Wrong

Search for a DNS diagram and you will find the same picture repeated in different colors. Compare any of them with what the root server receives in ours. The resolver sends com. to the root, not www.example.com, and the full-name version has not been accurate for years.

The technique is QNAME minimization, specified in RFC 9156, DNS Query Name Minimisation to Improve Privacy, November 2021, by Bortzmeyer, Dolmans and Hoffman. It is a Standards Track document and it obsoletes RFC 7816. Its abstract states the change directly: the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server.

The reasoning is privacy rather than performance. A root server has no business knowing the whole name you asked for; it needs the top-level domain only, in order to refer you onward. The RFC puts the rule as obscuring the query "in queries directed to an authoritative name server that is not known to be responsible for the original QNAME", which means each server gets one label more than the longest name it is already known to be authoritative for.

Two parts of that get dropped in the retellings. The resolver substitutes the record type as well as the name: "The A or AAAA QTYPEs are always good candidates to use because these are the least likely to raise issues in DNS software and middleboxes." So the root may be asked for a record type you never requested. And one label at a time is a default, not a guarantee: a resolver "MAY" reduce its query count "by appending more than one label per iteration for QNAMEs with a large number of labels."

One practical consequence is worth holding on to. Minimization means more queries per lookup rather than fewer, because each level gets its own question, and the RFC requires resolvers supporting it to "implement a mechanism to limit the number of outgoing queries per user request." Which resolver you use therefore changes the shape of your traffic, and Google's public DNS at 8.8.8.8 is where most readers are pointed by default.

Recursive or Iterative: The Specification Has It the Other Way Round

Ask how DNS resolution works and the answer is almost always about recursion, framed as though recursive resolution were the normal mode and iterative a variation on it. RFC 1034 has it the other way about, and the difference tells you which server to blame when a lookup fails.

Section 2.3 defines the pair precisely: one is "recursive, in which the first server pursues the query for the client at another server", the other "iterative, in which the server refers the client to another server and lets the client pursue the query." The distinction is about who does the walking, not about the questions asked.

Then comes the part that gets left out. Section 4.3.1 opens with the non-recursive case and states flatly that "All name servers must implement non-recursive queries." A paragraph later it reaches recursion: "This service is optional in a name server, and the name server may also choose to restrict the clients which can use recursive mode." So the mandatory behavior is the iterative one, and recursion is the optional extra your device happens to depend on.

The same paragraph of Section 2.3 then settles it in one line: "The domain system requires implementation of the iterative approach, but allows the recursive approach as an option." Required and optional, in that order, in the document that defines the system.

The sentence immediately before it gives the 1987 reasoning — "the iterative approach is preferred for the datagram style of access" — which is an argument about the cost of datagrams rather than about anything operators decide today. The reasoning is nearly forty years old. The requirement beside it has not been changed since.

What the Root Servers Actually Are

There are thirteen root server identities, lettered A through M, run by twelve organizations, because Verisign operates both A and J. The two names people reach for as shorthand are both wrong: on IANA's published list ICANN operates L and NASA's Ames Research Center operates E. Neither of them is the root, and there is no single organization you can call the root authority.

And the letters are not machines. Each identity is announced from many locations at once using anycast, so a query addressed to one letter reaches whichever instance is closest to you on the network. The published count on 1 October 2026 was 2,045 operational instances across those twelve operators, which the root server operators report live on their own site.

That is also why a root query is fast from anywhere: the resolver reaches an instance that may be in the same city, serving the same zone data as every other instance of that letter. Next, the transport carrying all of this, and the line about it that has been wrong for a decade.

Port 53, and Why TCP Is Not a Fallback

DNS uses port 53. The line that usually follows, that UDP is for speed and TCP only for bulk transfers like zone transfers, is the third inherited claim on this subject that a Standards Track document has overruled. RFC 7766, DNS Transport over TCP — Implementation Requirements, March 2016, is unambiguous: the RFC 7766 transport requirement reads "All general-purpose DNS implementations MUST support both UDP and TCP transport", and it applies that to authoritative servers, recursive servers and stub resolvers alike.

It also names the belief it is correcting, and it is not the one you would expect. What RFC 7766 quotes is RFC 1123, which said resolvers and recursive servers "MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries", and it then observes that "some implementors have taken the text quoted above to mean that TCP support is an optional feature of the DNS protocol." The correction is optional to required, and TCP "ought to be considered a valid alternative transport to UDP, not purely a retry option."

Two details worth carrying away. The RFC does not treat zone transfers as history: in its own present tense, TCP "is always used for full zone transfers (using AXFR) and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit." The error is reading that as the whole of TCP's job. And none of this is new, because RFC 7766 obsoletes RFC 5966, which carried the same requirement in 2010.

Treating TCP on port 53 as exotic is how a firewall quietly breaks resolution for larger answers, and the RFC names what makes them larger: "The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP." Next, how to find out which of these behaviors your own resolver gives you.

Watch the Resolution Happen on Your Own Machine

The DNS lookup process is checkable from a terminal in under a minute. The point is not to confirm that DNS works, but to find out which of the behaviors above your own resolver gives you, because the specification permits more than one answer on each of them.

One correction first, because it is in most tutorials: a trace does not show you your resolver working. BIND's documentation states that "When tracing is enabled, dig makes iterative queries to resolve the name being looked up", and that "Recursion is automatically disabled when the +nssearch or +trace query option is used." ISC adds that dig uses your configured nameserver only "for the initial discovery of the root nameservers." The walk you see belongs to dig, not to your resolver.

There is one thing none of these commands can tell you. nslookup -type=NS example.com returns the NS records your recursive resolver holds, which is the zone's own copy and possibly a cached one. The delegation is the NS set the parent zone publishes, the two are allowed to disagree, and that disagreement is a failure mode in its own right. What the registrar has on file sits in the domain's WHOIS record, which is the closest you get to what the owner intended.

For turning one name into one address at the command line, including the syntax differences between platforms, find a website's IP from the command line covers it. Once you can read your own resolver's behavior rather than guess at it, the failure modes stop being mysterious.

Where the Resolution Process Breaks

Name resolution in DNS fails in a small number of distinct ways, and they are worth separating because the repairs do not overlap. The useful question is never "is DNS broken" but "which party stopped answering, and what did it say".

The first case is a definite negative: a server authoritative for the name replied that it does not exist. Where that reply came from decides what to do about it, because negatives are cached too, and RFC 2308 sets their lifetime at "the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself." So if the record was created after your resolver stored the negative, flushing is exactly the fix. If the name genuinely does not exist, nothing local changes the answer.

The second is silence. Your configured resolver does not reply within its timeout, so the walk never starts and everything downstream is irrelevant. The repair path for that one is in when a DNS server stops responding.

The third is staleness. The chain answered correctly and the answer is out of date, because a cached record has not reached the end of its TTL. People misread this as a broken lookup when it is the system doing what it was told.

The fourth is a broken delegation, which produces symptoms that do not resemble a name lookup failing at all. A referral points at servers that are not serving the zone, so the walk reaches the bottom and finds nobody home. The name appears to half-exist: resolvers still holding a cached answer from before the delegation broke keep working, while others fail outright.

The response code behind a definite negative, and how long resolvers may remember it, is in what NXDOMAIN actually means. It is the most misdiagnosed outcome in the whole process.

The Short Version

The DNS resolution process is a walk down a delegated tree, and the most useful thing to carry away is that the walk is the exception rather than the rule. Caching is the normal case, which is why most lookups never reach a root server, and why a change you publish can be invisible to you and visible to somebody else at the same moment.

The three claims in the inherited version of that story are settled by specification rather than opinion, and they are the same three the author note opened with. A modern resolver sends one label to the root, not the name you typed, per RFC 9156. Iterative resolution is what every name server must implement and recursion is the option, per RFC 1034. And TCP on port 53 is a required transport rather than a fallback for zone transfers, per RFC 7766.

If the next question is how to stop the chain being tampered with, DNS security solutions and DNSSEC is the right place. And if a name is failing right now rather than interesting you in theory, IP address errors, identified sorts the symptom before you start repairing anything. Run the minimization test once; the diagram stops being something you have to take on trust.