The address works, the name does not
A new colleague types intranet.example.com and sees "server not found". You type 192.168.1.50 on the same laptop and the page opens.
So the server is fine. The problem is turning the name into the number. That job belongs to a system called DNS, and it is behind almost every request you make.
By the end of this lesson
Note
I can explain how a name becomes an address.
Key words
| Word | What it means | Example |
|---|---|---|
| Domain name | a name people use for a server | shop.example.com |
| DNS | the system that turns names into IP addresses | |
| Resolver | the server that looks a name up for you | |
| Record | one fact a name server holds about a name | |
| CNAME | a record that says one name is another | |
| TTL | how many seconds an answer may be kept | 300 |
The cells students fill in are left blank in this preview.
A resolver asks until it finds out
Your laptop does not know where shop.example.com is. It asks a resolver. In an office, that is often the router or a company server.
If the resolver does not know either, it asks in steps. First a root server, which points to the servers for .com. They point to the servers for example.com. Those give the answer, and the resolver passes it back to your laptop.
Try it: look a name up
# A tiny copy of what a name server knows
records = {
"shop.example.com": "203.0.113.10",
"mail.example.com": "203.0.113.25",
"intranet.example.com": "192.168.1.50",
}
name = "shop.example.com"
if name in records:
print(name, "is at", records[name])
else:
print(name, "has no record: the browser shows 'server not found'")
# Change name to "payroll.example.com", then press Run.
A name server holds records
A name server keeps records about each name. Each record has a type.
An A record gives an IPv4 address. An AAAA record gives an IPv6 address. A CNAME says "this name is really that name", so the lookup carries on. An MX record says which server takes the email for a domain.
When you set up a new service at work, you often ask for one of these.
Records you will meet at work
| Type | Example name | Example value |
|---|---|---|
| A | web.example.com | 203.0.113.10 |
| AAAA | web.example.com | 2001:db8::10 |
| CNAME | shop.example.com | web.example.com |
| MX | example.com | mail.example.com |
| TXT | example.com | A short note other services read |
The cells students fill in are left blank in this preview.
Answers are kept for a while
Asking the whole chain every time would be slow. So a resolver keeps each answer for a number of seconds. That number is the TTL.
Below is real output from dig, a tool engineers use to ask DNS directly. The 300 on each answer line is the TTL: five minutes. The last line shows which resolver answered.
Real output from dig
$ dig shop.example.com
;; QUESTION SECTION:
;shop.example.com. IN A
;; ANSWER SECTION:
shop.example.com. 300 IN CNAME web.example.com.
web.example.com. 300 IN A 203.0.113.10
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)A common mistake
Warning
Many people think a DNS change shows up everywhere at once. A resolver keeps the old answer until its TTL runs out. So after a change, some users see the old address for a while. Lower the TTL a day before a planned move.
Try it: a local list of names
# A hosts file: one address and one name on each line
printf "192.168.1.50 intranet.example.com\n192.168.1.60 wiki.example.com\n" > hosts
# Find the address for the wiki
grep "wiki.example.com" hosts | awk '{print $1}'
# Change wiki to intranet, then press Run.