What an answer is actually made of
In the previous guide you watched a resolver walk a name from the root down to the authoritative server and come back with an answer. But "an answer" was a polite simplification. What the authoritative server actually hands back is not a sentence; it is a small, rigidly formatted row of data called a resource record, or RR for short. Every fact that DNS knows about the world is stored as one of these rows, and learning to read a row is most of learning DNS.
A record has the same four parts every time. There is the name it is about (example.com), a type that says what kind of fact this is (an address? a mail server?), a TTL which is a number of seconds we will come back to, and the data itself, called the RDATA, which is whatever that type carries. Think of one card in an old library catalogue: the title is the name, the category sticker is the type, the pencilled date is the TTL, and the line of text is the data. DNS is nothing but an unimaginably large, distributed drawer of these cards.
NAME TTL TYPE RDATA (the data) -------------------- ------ ----- -------------------------- example.com. 3600 A 93.184.216.34 example.com. 3600 AAAA 2606:2800:220:1:248:1893:: example.com. 3600 MX 10 mail.example.com. example.com. 86400 NS ns1.example.com. www.example.com. 300 CNAME example.com. example.com. 3600 TXT "v=spf1 include:_spf..." ^ name it's about ^ secs ^ kind ^ whatever the kind carries
A small zoo of record types
There are dozens of record types, but a handful do almost all the work. The A record is the original and most common: it maps a name to an IPv4 address, the kind you met as an IPv4 address like 93.184.216.34. Its twin the AAAA record (say "quad-A") does the same job for an IPv6 address; it is four times the bits, hence four A's. When your browser wants to open a connection, an A or AAAA record is almost always the fact it is really after, because TCP and IP speak in addresses, not names.
The CNAME record is an alias: it says "this name is just another name for that name, go look there instead". So www.example.com might be a CNAME pointing at example.com, and the resolver follows the pointer and resolves the target. It is the forwarding sticker on a moved letter. The MX record (mail exchanger) names the server that accepts email for a domain, with a number in front giving its priority, so mail can fall back to a backup. The NS record names the authoritative servers for a zone, and these are the very records that made delegation work in the last two guides; a parent zone hands you down to a child by handing you its NS records.
Finally the TXT record is the junk drawer: it holds arbitrary text, and the Internet has bolted whole systems onto it. Email anti-spoofing schemes (SPF, DKIM, DMARC) live in TXT records; so does the little proof a site shows a service to say "yes, I really do own this domain". TXT is powerful precisely because DNS never said what the text means, so people kept inventing meanings for it.
The TTL: a record with an expiry date
Now back to that number in the middle column. The TTL, or time to live, is how many seconds anyone is allowed to keep a copy of this record before they must throw it away and ask again. An A record with a TTL of 3600 says "this address is good for one hour". It is the pencilled use-by date on the milk: trust it until then, then check for a fresh carton. The authoritative server, the one that truly owns the record, is the only party that sets the TTL, and it is choosing how long the rest of the world is allowed to remember its answer.
Why does one number matter so much? Because without it, DNS could not exist at scale. There are billions of devices and they look up the same popular names over and over. If every single lookup had to march all the way from the root to the authoritative server, the root and the busiest authoritative servers would be crushed instantly, and every page load would pay the full multi-hop journey you traced last guide. The TTL is the permission slip that lets answers be reused, and reuse is what turns an impossible amount of work into an easy amount.
Caching: the answer you already have
Here is the mechanism the TTL unlocks. When your local resolver (the recursive one your computer talks to) finishes a lookup, it does not just hand the answer to you and forget it. It keeps a copy in memory, a store called the cache, stamped with the moment it arrived. This is DNS caching. The next time anyone on that resolver asks for the same name, it can answer from the cache in under a millisecond, no walking the hierarchy at all. The first lookup of a popular name is slow; the next thousand are nearly free.
- A record arrives at the resolver with TTL 3600. The resolver stores it and notes the clock: this expires 3600 seconds from now.
- Anyone asking for that name in the next hour gets the cached copy instantly, and the resolver also counts down the TTL it reports, so a record cached for 600 seconds is handed out with a remaining TTL of 3000.
- When the countdown hits zero the record is stale. The resolver discards it and, on the next request, does the full recursive walk again to fetch a fresh copy.
Caching is layered, just like envelopes nested inside envelopes elsewhere in networking. Your browser keeps a tiny cache, your operating system keeps one, your home router often keeps one, and your ISP's big recursive resolver keeps a huge one shared by many customers. A query stops at the first layer that already knows the answer. This is why a name you just visited resolves the instant you type it, and why a brand-new name takes a visible beat the first time.
Choosing a TTL is a real trade-off
The TTL is not a detail to set and forget; it is a knob with two opposite costs. A long TTL (a day, say 86400 seconds) means answers are reused for ages, so your authoritative servers get asked rarely and lookups are fast and cheap. The price is that if you change a record, the old answer lingers in caches everywhere until they expire. A short TTL (say 300 seconds, five minutes) means changes spread fast, but every cache re-asks constantly, loading your servers and adding latency. There is no universally right value, only the right value for what you are doing.
Two honest caveats. First, the TTL is a hint the authoritative server gives, not a law it can enforce: a misbehaving or aggressive cache can hold a record longer than asked, and you cannot reach into the world's caches to force them to forget early. So a TTL is the maximum you should expect, planned around, never a guarantee. Second, caching plus TTL is also why DNS feels "laggy" after changes; the record is correct at the source the instant you save it, but the rest of the world only catches up as old copies time out. That delay is not a bug, it is the very reuse that makes DNS scale.
Looking up backwards, and who keeps it humming
Almost everything so far went name to address. But sometimes you have an address and want the name, for example a mail server checking who is connecting to it. That is reverse DNS, and the clever trick is that reverse DNS reuses the very same tree. The address 93.184.216.34 is written backwards as a name under a special zone, 34.216.184.93.in-addr.arpa, and a record type called PTR (pointer) at that name gives the hostname. Reversing the octets is what lets the normal top-down hierarchy and delegation work for addresses too; no second system was needed.
Two last pieces tie the rung together. Records do not appear by magic; a human (or their hosting tool) puts them into a zone, and the right to use a name at all is rented through a domain registrar, the company you pay to register example.com and tell the registry which NS records point to your authoritative servers. And those records are reached over a network that must itself be fast and resilient, which is where anycast comes in: the busiest resolvers and root servers announce the same IP address from many locations at once, so your query is steered to the nearest copy, like a chain of local warehouses all sharing one phone number. Anycast plus caching is why looking up a name almost anywhere on Earth feels instant.