The labs on this site need JavaScript to run. The same content is written out below.

Learn › Networking › Addresses and names

DNS

Who knows the IP address of a domain name, and when does a change show up?

A computer cannot connect to a name like shop.example; it needs an IP address. DNS is what turns a name into an address. The servers that know the answer are not in one place but are divided into several levels, and an answer that has been received stays in a cache for a set time (the TTL) so that it is not asked for again.

Partly checked against real execution · 32 combinations were run as real DNS messages with a test name server and resolver started on 127.0.0.1, and checked. The parsing of records was checked against c-ares in Node.js 24, and the behavior of the resolver and the cache reproduces the procedures of RFC 1034 and 1035

Concepts in this lab

DNS

The system that translates a domain name (example.com) into the IP address that computers use to communicate. When you enter an address in a browser, the browser first asks this system for the IP address of that name and then connects to that IP address. Lookup results are cached for a certain time.

DNS record

One line of information that the name server of a domain holds for each name, made up of a name, a type, a value, and a TTL. An A record connects a name to an IPv4 address, and an AAAA record connects it to an IPv6 address. A CNAME record makes a name an alias of another name, and if you ask for the alias, you must look up the canonical name once more to get an address. An MX record gives the name and priority of the server that receives mail sent to the domain, and the server with the smaller number is tried first.

Recursive resolver and authoritative name server

An authoritative name server is a server that holds the original records of a domain and answers questions about that domain directly. A recursive resolver is a server that looks for the answer on behalf of the user's computer, starting from a root server and asking a TLD server and then the authoritative name server in that order. A root server and a TLD server give not the answer but the next server to ask, and this kind of response is called a referral. They can do this because the upper zone lists the name servers responsible for the lower zone, and handing a lower zone over to separate servers in this way is called delegation. The user's computer asks only one recursive resolver, and its address is usually given in the network settings by an internet provider or a home router.

DNS cache and TTL

A cache is where an answer received through DNS is remembered so that it is not asked for again, and the TTL is a number, written in seconds, that says how long the answer may be remembered. The side that manages the record decides the TTL and attaches it to the record. There are caches in the browser, in the operating system, and in the recursive resolver, and when the TTL passes, the answer is discarded and asked for again. So even if you change a record, an answer already in a cache is used until the TTL ends, and each user receives the new value at a different time.

Try these

• Default settings — A name asked for the first time. The resolver asks from the root server down, one server at a time, to find the answer.
• A name that was just asked for — The answer is in this PC's cache, so no one is asked.
• Record changed, but traffic still goes to the old address — The TTL has not run out in the resolver's cache, so it gets the old value.
• After the TTL has passed — It asks again and gets the new value. It does not start from the root server.
• A name that goes through a CNAME — It finds the canonical name of the alias, and then looks up that name once more.
• Finding the mail server — An MX record gives the name of the mail server, not an address.

Running with the default settings

1. The browser needs an IP address to connect to shop.example. What to look up is the A record (IPv4 address) of shop.example. First it looks at the cache of this PC (the place where the operating system and the browser remember answers they received earlier). It is a name asked for the first time, so there is nothing.
2. This PC asks the recursive resolver. A recursive resolver is a DNS server that looks for the answer on your behalf. It is usually run by an internet provider or a company, and its address is in the network settings. The resolver also looks at its own cache first. There is nothing. The only thing the resolver knows from the start is the addresses of the root servers.
3. Resolver → root server: The resolver sends the same question to the root server. The root server does not have the answer. Instead, it looks at the end of the name (.example) and gives the addresses of the servers responsible for names ending in .example (the TLD servers). A response like this, which tells the resolver which server to ask next, is a referral. Handing a part of the name space down to the servers below is called delegation.
4. Resolver → .example server: It sends the same question again. This server does not have the answer either, and it gives the addresses of the name servers responsible for shop.example.
5. Resolver → authoritative name server of shop.example: This is the server that holds the original records of this domain. It gives the answer: shop.example A 203.0.113.10, TTL 300s.
6. The resolver puts the records it received in its own cache and returns the answer to this PC. For the next 300s, it answers anyone who asks the same thing from its cache. It also remembers the delegation information it learned on the way. This PC also puts the answer it received in its cache for the TTL.
7. The browser connects to the address it received (203.0.113.10).

Result of this run

• No server has the answer for every name. A root server tells you which servers handle the last part of a name (.example, .com, .kr), those servers tell you the name server for each domain, and the original answer is held by the authoritative name server of that domain. This PC asks only one resolver, and the resolver does the step-by-step asking on its behalf.
• An A record connects a name to an IPv4 address. It is the most basic record.

Code

; Records held by the authoritative name server for shop.example (name, TTL, type, value)
shop.example.        300  IN  A      203.0.113.10
shop.example.        300  IN  AAAA   2001:db8::10
shop.example.        300  IN  MX     10 mail.shop.example.
www.shop.example.    300  IN  CNAME  shop.cdn.example.

; Records held by the authoritative name server for cdn.example
shop.cdn.example.    300  IN  A      203.0.113.80

// The asking side (Node.js, file name ask.mjs). It asks the recursive resolver in the network settings and receives the answer
import { Resolver } from 'node:dns/promises';
console.log(await new Resolver().resolve4('shop.example', { ttl: true }));

Assumptions of this model

A test program was started on 127.0.0.1 that plays the roles of a root server, a .example server, two authoritative name servers, and a recursive resolver, and real DNS messages were exchanged. For 32 combinations, the answer, the number of questions, the order of asking, and whether the changed value is reflected were checked. No outside DNS was queried. However, this test name server, resolver, and PC-side cache were built for this lab by following the standard procedures (RFC 1034 section 4.3.2 for name server responses, section 5.3.3 for resolver procedures, and RFC 1035 section 6.1.3 for the TTL of a cache). So the behaviors "ask from the root server down in order", "use the answer in the cache for the TTL", and "if the delegation information remains after the TTL has passed, ask the authoritative name server directly" were confirmed by reproducing the standard procedures, and were not checked against a resolver product that is actually operated or the cache of an operating system. What was confirmed with an independent implementation is the content of the records. For each combination, the same question was also sent with Node.js 24 dns.Resolver (c-ares), and the values of A, AAAA, CNAME, and MX that c-ares parsed from the response of the test server were checked to be the same. It was also confirmed that the Node.js dns.Resolver does not cache by itself and asks again every time. The time was made by really waiting. In the run, the TTL of the record was set to 4 seconds, and the question was asked again after 1.2 seconds (TTL remaining) and after 5.2 seconds (TTL passed). The 300s, 120s, and 400s on the screen and the 172800s of the delegation information are examples written as numbers of a size commonly seen in the same situation. The meaning of the records follows RFC 1035 sections 3.3 and 3.4.1 (A, CNAME, MX) and RFC 3596 (AAAA), and looking up the canonical name again when a CNAME is met follows RFC 1034 section 3.6.2. A real resolver does more, such as choosing one of several root servers and name servers, sending only part of the name in a query (RFC 9156), and caching negative answers, that is, answers saying that a name does not exist. There are also cases in which a browser and an operating system do not keep the TTL exactly and remember an answer for a shorter or longer time. All the addresses are in the ranges reserved for documentation.

Previous lab: URL structure · Next lab: IP addresses and subnets