Domains and DNS
On This Lesson 11 topics
Lesson Overview
In the last lesson you saw that computers find each other with numbers: an IP address and a port. Nobody wants to type 192.0.2.10 to read the news. We type names such as example.com instead. This lesson explains how a name becomes a number.
The system that does this is the Domain Name System, or DNS. It is often called the internet's phone book: you look up a name and get a number back. We will also clear up the most common misunderstanding in this topic: a domain is a name, not a server.
Why this matters: every time a backend service is deployed, someone must connect a domain name to the right address. When a site "moved to a new server" or "was unreachable for an hour after a change", DNS is usually part of the story. Understanding it also prepares you for the nslookup command in Lesson 7.
This lesson builds on Lesson 2 (IP addresses) and Lesson 1 (the internet and its protocols).
Learning Objectives
By the end of this lesson you will be able to:
- Explain why people use domain names instead of IP addresses.
- Name the parts of a domain name: top-level domain, second-level label, and subdomains.
- Describe what DNS does in one sentence.
- Walk through a DNS lookup: browser cache, resolver, and the DNS servers that answer.
- Explain why a domain is a name that points to servers and is not a server itself.
- Explain why one domain can have several IP addresses, and why several domains can share one.
- Explain what caching does for DNS and why a DNS change can take time to spread.
Written Explanation
Why names?
An IP address is perfect for machines and awful for people. It is easy to mistype, hard to remember, and, as the MDN article on domain names points out, it may change over time. A domain name is a stable, human-readable label that stands in for the address.
Think of your phone's contacts. You tap "Mum" and the phone dials a number. You do not remember the number. DNS is the same idea for the internet, and the whole internet shares one enormous contact list.
Anatomy of a domain name
A domain name is made of parts called labels, separated by dots. You read it from right to left, from the most general part to the most specific.
developer . mozilla . org
subdomain second-level top-level
label domain (TLD)- The top-level domain (TLD) is the last label:
.com,.org,.net, or a country code such as.fr. Some are restricted, for example.govfor governments. - The label directly to the left of the TLD is the part an organisation typically chooses, such as
mozillainmozilla.org. MDN calls it the second-level domain. - Labels added further left are subdomains.
developer.mozilla.organdsupport.mozilla.orgare two subdomains ofmozilla.org. An owner can create as many as they like, such aswww,api, orshop.
Labels follow rules: they use letters, digits, and hyphens, are not case-sensitive, and each is at most 63 characters, according to MDN.
The URL you type includes the domain but adds more. In https://shop.example.com/cart, the scheme is https, the host is shop.example.com (the domain), and the path is /cart. The domain is only the host part.
Who owns a domain?
You do not buy a domain outright. MDN explains that you pay a company called a registrar for the right to use a name for a period, such as a year, and you renew it. The registrar records your claim with a registry, the organisation that tracks names under one TLD. If you stop paying, the name can become available again.
Buying a domain gives you a name. It does not give you a server, a website, or any content. Those are separate things, and that is the heart of this lesson.
What is DNS?
The Domain Name System (DNS) is a hierarchical, decentralised naming system that maps domain names to resources such as IP addresses (MDN's glossary wording). Hierarchical means organised in levels, like folders inside folders. Decentralised means no single computer holds every answer: the work is spread across many servers run by many organisations.
A DNS lookup is the act of asking for the address that goes with a name. The question can be as simple as "what is the IP address of example.com?" and the answer is a number such as 192.0.2.10 (an illustrative address).
How a lookup works
When you type example.com into the browser, a short chain of questions begins. The details can vary, but a typical picture is:
- The browser checks its own memory. If it looked up this name recently, it already knows the address and skips the rest.
- The operating system checks too. Your computer keeps a small DNS cache of its own.
- Your computer asks a DNS resolver. A resolver is a DNS server whose job is to find answers for you. It is usually provided by your internet provider or your network, and it may also be a public service you choose.
- The resolver asks around, if needed. If it does not already know the answer, it asks a root server, which points it to the servers for the TLD (such as
.com). Those point it to the authoritative name server forexample.com, the server that holds the official records for that domain. - The answer comes back. The authoritative server replies with the IP address. The resolver passes it to your computer.
- The browser connects to that address (Lesson 4).
MDN's own summary of the first steps is that the browser checks the local cache, and if it has nothing, the computer asks a DNS server whose job is to map registered domain names to IP addresses. The root, TLD, and authoritative steps in item 4 describe the usual process and are the standard textbook account, but the exact path on your network can differ.
You: "What is the IP for example.com?"
|
[ cache? ] --yes--> use it
| no
v
[ resolver ] --> root --> .com servers --> authoritative server
^ |
+------------------ answer -----------------+The whole process normally takes a tiny fraction of a second.
Caching and why changes take time
Answers are cached, meaning stored temporarily for reuse. Without caching, every page load would trigger a chain of questions. Each DNS record carries a TTL (time to live): how long, in seconds, a cache may keep the answer before asking again.
Caching explains a classic situation. Suppose a company moves its website to a new server and updates the domain's record to the new address. Some visitors still reach the old server for a while, because their resolvers hold the old answer until the TTL runs out. MDN describes the same effect: DNS records are cached for a period, which is why changes to DNS information can take time to propagate.
A domain is a name, not a server
This is the most important idea in the lesson, and a very common mistake.
- A domain is only a name in the naming system. It has no processor, memory, or disk.
- A server is a real computer (or a program running on one) that answers requests, as you saw in BEG-001 and BEG-002.
- DNS connects the two: it says "this name points to these addresses".
The relationship is flexible:
| Situation | What it means |
|---|---|
| One domain, one server | The simplest case. The name points at one address. |
| One domain, several addresses | The site runs on several servers for capacity and reliability, so the answer lists more than one address. |
| Several domains, one server | One server can host blog.example.com and shop.example.com, because the name is sent along with the request (Lesson 4). |
| A subdomain pointing elsewhere | www.example.com and api.example.com can point to different servers entirely. |
Large sites may also give different visitors different addresses depending on where they are, so that each visitor reaches a nearby server. MDN notes that for large sites the address can vary by visitor location. This is why two people in different countries running a lookup on the same domain can legitimately see different numbers.
Names for the same thing
A domain can also act as an alias for another domain. A name that points to another name instead of a number is called a CNAME (canonical name) record. You will see records with other names too, such as A for an IPv4 address and AAAA for an IPv6 address. You do not need to memorise them now. The key idea is that DNS stores several kinds of facts about a domain, and the IP address is the one we care about first.
Examples
Example 1: Splitting a domain (simple)
Break down api.shop.example.com.
| Label | Role |
|---|---|
com | Top-level domain |
example | The organisation's chosen name |
shop | A subdomain of example.com |
api | A subdomain of shop.example.com |
Read from the right: the TLD is com, the organisation is example, and shop and api are added on the left. Whoever controls example.com decides which subdomains exist.
Example 2: Following one lookup (practical)
You type www.example.com for the first time today.
- Your browser has no cached answer.
- Your computer asks the resolver on your network.
- The resolver does not have it either, so it asks the DNS hierarchy, ending at the authoritative server for
example.com. - The authoritative server answers with an address, say
192.0.2.10(illustrative), with a TTL of a few minutes. - Your browser connects to
192.0.2.10. - A minute later, you click a link on the same site. This time the answer is cached, so step 2 to step 4 are skipped.
The first visit costs a lookup. Repeat visits cost almost nothing. That is the benefit of caching.
Example 3: Moving a website to a new server (realistic)
A shop's site runs at 192.0.2.10. The team builds a new server at 192.0.2.99 and tests it. On launch day they change the domain's record from the old address to the new one.
What happens next:
- Visitors whose resolvers have a cached answer keep going to
192.0.2.10until the TTL expires. - Visitors whose caches have expired reach
192.0.2.99immediately. - For a while, some visitors see the old site and some see the new one.
A careful team therefore lowers the TTL a day before the move, so the switch spreads quickly. They also keep the old server running until traffic to it dies down. The domain never changed. Only the address it points to did. That is why a domain cannot be the same as the server.
Backend Insight
Backend developers meet DNS in several everyday ways.
- Deployment. When you publish a service you register or reuse a domain, then create a record that points the name to the address of your server or load balancer (a machine that spreads requests across several servers).
- Configuration. You will connect to databases and other services by name, such as
db.internal.example.com, rather than by address. If the database moves, you change one DNS record instead of editing every program. - Resilience. One domain pointing at several addresses is a simple way to spread load and survive a server failure.
- Debugging. Many outages are DNS problems: a wrong record, an expired domain, or a cached old answer. The first diagnostic question is often "what address does this name give right now?" Lesson 7 shows how to ask with
nslookup.
Remember that DNS answers where, not whether the server is healthy. A name can point to a server that is switched off.
Common Mistakes
Mistake 1: Thinking a domain is a server
- Incorrect: "We need to restart the domain."
- Correct: "We need to restart the server that the domain points to."
You cannot restart a name.
Mistake 2: Thinking a domain has exactly one IP address
A domain can return several addresses, and different visitors can receive different ones. A single number is a snapshot, not a permanent fact.
Mistake 3: Expecting DNS changes to appear everywhere at once
Because of caching, a change can take minutes or hours to reach everyone, depending on TTLs. Plan for the overlap.
Mistake 4: Mixing up domain, URL, and website
example.com is a domain. https://example.com/about is a URL. The pages and files you see are the website. Three different things.
Mistake 5: Treating a subdomain as a separate purchase
Subdomains such as api.example.com are created by the owner of example.com at no extra registration cost. They are not separately registered names.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. In blog.example.org, name the top-level domain and the subdomain.
Show solution A1
A1. The top-level domain is org. The subdomain is blog.
A2. What does DNS do, in one sentence?
Show solution A2
A2. DNS translates domain names into IP addresses (and other records), so that people can use names while computers use numbers.
A3. Is a domain a server? Answer in one sentence.
Show solution A3
A3. No. A domain is a name that points to one or more servers.
Level B: Application
B1. Order these in the sequence they normally happen when the browser has no cached answer: the resolver asks the DNS hierarchy, the browser connects to the IP address, the browser checks its cache, the answer comes back.
Show solution B1
B1. The browser checks its cache, the resolver asks the DNS hierarchy, the answer comes back, the browser connects to the IP address.
B2. A site moves to a new server. A friend still sees the old site two hours later. Give a likely reason.
Show solution B2
B2. Their device or resolver still holds the old address in its cache, and keeps it until the TTL expires. The change takes time to spread.
B3. Two sub-sites, blog.example.com and shop.example.com, run on one computer. Is this possible? Explain.
Show solution B3
B3. Yes. A domain is only a name. Both names can point to the same address, and the server can tell them apart because the requested name is sent along with the request.
Level C: Challenge
C1. A company wants its domain to survive the failure of one server. Describe how DNS can help, and name one thing DNS alone cannot guarantee.
Show solution C1
C1. The domain can have several addresses, so traffic can be shared and, if the records are managed well, one failing server need not take the site down. DNS alone cannot guarantee that every client avoids a dead address immediately, because cached answers and client behaviour mean some clients may still try it, and DNS does not check server health by itself.
C2. A developer says, "I changed the DNS record to the new address. Why does the old server still receive traffic?" Explain, and propose how to plan a smoother move next time.
Show solution C2
C2. Resolvers and devices cached the old answer and keep using it until its TTL ends. Next time, lower the TTL a day or more before the change, make the switch, and keep the old server running until traffic to it falls away.
Mini Challenge
Build a "domain map" for a made-up company.
- Invent a domain, such as
mybakery.example. (Use.example-style names so you do not point at a real organisation.) - Invent four subdomains, such as
www,shop,api, andmail. - Assign each a pretend IP address from the documentation block
192.0.2.0to192.0.2.255. Let two subdomains share one address, and give one subdomain two addresses. - Write one sentence explaining why the two subdomains sharing an address can still be told apart.
- Write one sentence explaining what the domain itself has: names, not machines.
Check your work: one address appears twice, one name has two addresses, and you never wrote "the domain runs on".
Summary & Next Lesson
Key takeaways
- A domain name is a human-friendly label that stands in for an IP address. It is read from right to left: top-level domain, then the chosen name, then subdomains.
- DNS is a distributed, hierarchical system that maps names to addresses.
- A lookup normally checks caches first, then asks a resolver, which asks the DNS hierarchy until the authoritative server answers.
- Caching (with a TTL) makes DNS fast, and it is why changes take time to spread.
- A domain is a name, not a server. One domain can point to several servers, and several names can share one server.
- You rent a domain from a registrar. Owning a name does not give you a website.
Next lesson
You now know how to find a server's address. The next lesson, "Clients, servers, requests, and responses", shows what the browser does once it has that address: it sends a request and reads the reply.
Self-check
- What does DNS do?
- In
www.example.com, which label is the top-level domain? - Why can a DNS change take time to reach everyone?
- Can one domain return more than one IP address?
- Is a domain a server?
Show answers
- It translates domain names into IP addresses.
com.- Resolvers and devices cache answers until the TTL expires.
- Yes, for capacity and reliability, and sometimes depending on the visitor's location.
- No. It is a name that points to one or more servers.
References
- Mozilla Developer Network, DNS (glossary). Supports the definition of DNS as a hierarchical, decentralised naming system that maps domain names to resources such as IP addresses.
- Mozilla Developer Network, What is a domain name?. Supports the label structure, registrars and registries, the cache-then-DNS-server lookup order, and the point that DNS records are cached so changes take time to propagate.
- Mozilla Developer Network, How the web works. Supports DNS as an address book and that large sites may serve different addresses by location. The root, TLD, and authoritative walk-through, the TTL details, and record names such as CNAME, A, and AAAA are standard DNS background that was not checked on those pages here, so treat them as general summaries.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.