edubun
English
English한국어EspañolPortuguêsFrançaisDeutschItalianoРусский
Home›Computer basics and typing›How the internet works

DNS: turning names into addresses

The 13 root name servers are run by 12 organisations from 2047 machines around the world (root-servers.org, 17 October 2026).

BackgroundBefore DNS, every computer on the ARPANET kept a copy of one text file, HOSTS.TXT, listing every host name and address. The Stanford Research Institute's Network Information Center maintained it, and every site downloaded fresh copies. As the network grew, the file grew, changes took longer to spread, and names clashed. RFC 1034 describes this problem and the design that replaced it: a tree of names, each part looked after by its own servers. DNS was published as RFC 1034 and RFC 1035 in 1987.

Nobody downloads that file now. You type example.com rather than 198.51.100.20, and the name is looked up at the moment you need it. Routers still only understand numbers, though, so before your browser can send a single packet to a website, the name has to become an address. The Domain Name System (DNS) does that, and Cloudflare's guide calls it the phonebook of the internet.

A name is a path down a tree

Read www.example.com from the right. At the top is the root, written as an invisible dot. Below it are top-level domains (TLDs) such as com, org and kr. Below com is example, and below that is www. Each piece is a label; RFC 1035 allows up to 63 bytes per label and 255 bytes for a whole name. Different organisations run different branches of the tree, so no single computer has to know every name, which was exactly what went wrong with HOSTS.TXT, where one file on every machine tried to hold them all.

The DNS tree. www.example.com is the path www → example → com → root, read from left to right but looked up from the root down.

Four servers, eight steps

Cloudflare lists four kinds of server in a lookup. The recursive resolver, usually run by your ISP or a public DNS service, does the legwork for you. A root server knows where the TLD servers are. A TLD server, such as the one for com, knows which servers hold each domain beneath it. The authoritative server for a domain holds its actual records and gives the final answer. With nothing cached, a lookup takes eight steps. Your computer asks the resolver. The resolver asks the root, which points it to com. It asks com, which points it to the domain's name servers. It asks those, they answer with the address, and the resolver hands the address back to you.

Loading

Drag to turn. Scroll or pinch to zoom.

Press Next step eight times, or Play. Then press Look up again: the browser cache answers at once and no message leaves the computer. Wait 1 minute and look up again: the browser copy has expired but the OS cache still has it. Wait 1 hour: the 3600-second TTL has run out everywhere and the full lookup starts over.

Why the second lookup is instant

If every lookup took eight steps, DNS would be slow and the root servers would drown in questions. So answers are kept. They are cached in the browser, in the operating system and in the resolver. Each record comes with a time to live in seconds, set by the domain owner. A TTL of 3600 means "you may reuse this answer for an hour". A short TTL lets an owner move a site quickly; a long one saves lookups. The root servers are spread out too: the 13 named root servers, a to m, were running as 2047 separate instances on 17 October 2026.

Two kinds of question, one port

One lookup mixes two kinds of question. Your computer sends the resolver a recursive query, which means "give me the final answer or an error". The resolver then sends iterative queries to the root, TLD and authoritative servers, and each replies with the best it has, often only a pointer to the next server. DNS messages go to port 53, normally over UDP because a question and an answer each fit in one packet. Large answers and transfers between servers use TCP, which RFC 7766 makes a required part of every full DNS implementation. You can try this yourself. On most computers the command nslookup example.com prints the resolver it used and the addresses it got back.

Records hold more than addresses

RecordHoldsExample
AAn IPv4 addresswww.example.com → 198.51.100.20
AAAAAn IPv6 address (RFC 3596)www.example.com → 2001:db8::20
CNAMEAnother name to look up insteadshop.example.com → example.com
MXThe mail server for the domainexample.com → mail.example.com
NSThe authoritative name serversexample.com → ns1.example.com
  1. An uncached lookup of www.example.com: which servers does the resolver ask, in order?
  2. Which server gives the final answer for www.example.com?
    • The authoritative server for example.com
    • The root server
    • The com TLD server
    • The web server
  3. How many steps does an uncached lookup take in Cloudflare's description?
  4. Which record holds an IPv6 address?
    • AAAA
    • A
    • MX
    • CNAME
  5. A record has TTL 3600. For how many minutes may a cache reuse it?
  6. What is the longest a single label (such as example) may be under RFC 1035?
  7. How many named root servers are there?
  8. You looked up a name 10 seconds ago and the browser cache keeps it for 60 seconds. How many DNS messages leave your computer if you look it up again now?
  9. What is an MX record for?
    • Naming the mail server for a domain
    • Storing a web page
    • Holding an IPv6 address
    • Setting the TTL of other records
  10. What did DNS replace?
    • One HOSTS.TXT file copied to every computer
    • The telephone network
    • IP addresses
    • Routers
Common mistakes
  • "DNS stores the web pages." DNS only answers with records such as addresses, mail servers and other names. The page itself comes from the web server at the address DNS returned.
  • "When a site changes its address, everyone sees the new one at once." Browsers, operating systems and resolvers keep the old answer until its TTL runs out. With a TTL of 3600, some visitors can still be sent to the old address for up to an hour.
  • "There are exactly 13 root server computers." There are 13 names, a to m, run by 12 organisations. On 17 October 2026 they were answering from 2047 instances around the world.
  • "My computer asks the root server itself." Your computer asks the recursive resolver once. The resolver walks from the root to the TLD server to the authoritative server and hands back only the result.
Teacher's noteRead a few names right to left together before drawing anything; that reading habit is the one to build first. The resolver is the box that goes missing from learners' drawings, so draw it apart from the computer and make every arrow from the computer stop there. Run the simulator's eight steps once, then press Look up again straight away. A second lookup that sends nothing explains caching better than a definition. If a terminal is available, nslookup on a site the class already knows turns the diagram into something real.
Key points
  • DNS turns names into addresses; names are read right to left down a tree.
  • Recursive resolver → root → TLD → authoritative: eight steps with nothing cached.
  • Answers are cached in the browser, OS and resolver for the record's TTL (seconds).
  • A = IPv4, AAAA = IPv6, CNAME = alias, MX = mail, NS = name servers.
Sources for this course (28)
  • (checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
  • IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
  • RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
  • RFC 792 ICMP (Time Exceeded)
  • RFC 801 NCP/TCP transition plan (1 January 1983)
  • RFC 894 Ethernet (1500-byte payload)
  • RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
  • RFC 1122 (127.0.0.0/8 loopback)
  • RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
  • RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
  • RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
  • RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
  • RFC 8446 TLS 1.3 (one round-trip handshake)
  • RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
  • RFC 9293 TCP (three-way handshake, sequence numbers)
  • IANA: ip-parameters registry (recommended default TTL 64)
  • IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
  • Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
  • "What is a URL?", "HTTP response status codes" (developer.mozilla.org)
  • Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
  • "What is HTTP/3?" (cloudflare.com/learning)
  • Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
  • Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
  • Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
  • History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
  • historyofinformation.com and Wikipedia ARPANET (Kline)
  • Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
  • Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)

Checked: 2026-10-17