RFC 1034 · November 1987 · P. Mockapetris
Domain names - concepts and facilities
Index fetched 2026-10-19 from rfc-editor.org
How it works
Built by hand from RFC 1034. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a maintainer. Help verify this visual
RFC 1034 §5.3.3 The top level algorithm has four steps:
1. Resolver → Name servers: queries
The resolver has no answer in local information, so it finds the best servers to ask (its SLIST) and sends them queries until one responds.
RFC 1034 §5.3.33. Send them queries until one returns a response.
2. Name servers → Resolver: better delegation
A response may be a referral: a better delegation to other servers. The resolver caches it and goes back to choosing the best servers to ask.
RFC 1034 §5.3.3b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2.
3. Resolver → Name servers: queries
The resolver now queries the servers from the delegation, which are closer to the answer.
RFC 1034 §5.3.33. Send them queries until one returns a response.
4. Name servers → Resolver: answers the question
When a response answers the question, or says the name does not exist, the resolver caches the data and returns it to the client.
RFC 1034 §5.3.3a. if the response answers the question or contains a name error, cache the data as well as returning it back to the client.
Quoted text consists of unmodified excerpts from RFC 1034, published by the IETF (line breaks reflowed). Copyright in the RFC text belongs to the IETF Trust and the persons identified as the document authors, as stated in the RFC. The diagrams and plain-English explanations are rfc-visual's own and do not replace the RFC.
Not shown: Step 4c: following a CNAME by restarting the search at the canonical name (§5.3.3); Step 4d: deleting a failed or bizarre server from SLIST and retrying (§5.3.3); How SLIST is built, sorted and initialised from SBELT, and retransmission timeouts (§5.3.3); Name server side lookup algorithm, wildcards and negative caching (§4.3); Zone transfers and zone maintenance (§4.3.5); Other example resolutions, e.g. PTR lookup (§6.3.2, §6.3.3).
Lineage
Updated by (19)
- RFC 9471 — DNS Glue Requirements in Referral Responses
- RFC 8767 — Serving Stale Data to Improve DNS Resiliency
- RFC 8482 — Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
- RFC 8020 — NXDOMAIN: There Really Is Nothing Underneath
- RFC 5936 — DNS Zone Transfer Protocol (AXFR)
- RFC 4592 — The Role of Wildcards in the Domain Name System
- RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification
- RFC 4035 — Protocol Modifications for the DNS Security Extensions
- RFC 4034 — Resource Records for the DNS Security Extensions
- RFC 4033 — DNS Security Introduction and Requirements
- RFC 2535 — Domain Name System Security Extensions
- RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE)
- RFC 2181 — Clarifications to the DNS Specification
- RFC 2065 — Domain Name System Security Extensions
- RFC 1982 — Serial Number Arithmetic
- RFC 1876 — A Means for Expressing Location Information in the Domain Name System
- RFC 1348 — DNS NSAP RRs
- RFC 1183 — New DNS RR Definitions
- RFC 1101 — DNS encoding of network names and other types
Text
Loading the RFC text…