rfc-visual
GitHub

RFC 1034 · November 1987 · P. Mockapetris

Domain names - concepts and facilities

INTERNET STANDARDLegacy stream
10 verified errata8 held for document update

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

100%

RFC 1034 §5.3.3 The top level algorithm has four steps:

  1. 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.3 3. Send them queries until one returns a response.
  2. 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.3 b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2.
  3. 3. Resolver → Name servers: queries

    The resolver now queries the servers from the delegation, which are closer to the answer.

    RFC 1034 §5.3.3 3. Send them queries until one returns a response.
  4. 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.3 a. 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

Text

Loading the RFC text…