dig +trace👉 New to DNS? Start with What Is DNS? first. This tutorial goes behind the scenes.
You type www.example.com and press Enter. Your computer only understands IP addresses, so it must find the number first.
It does not know the answer, so it asks around. Each helper points to the next one, until one has the real answer.
You type : www.example.com
Asked : resolver → root → TLD → authoritative
Answer : 203.0.113.10
Saved : in a cache, so next time is instant
The IP addresses in this tutorial are example addresses. Real websites have different ones.
You want a friend's phone number. You only know the name. You ask a helper to find it.
Friend's name = Domain name
Phone number = IP address
Your helper = Recursive resolver
Directory of directories = Root server
Directory for one area = TLD server (.com, .in)
The friend's own office = Authoritative server
Saving the number in a phone = Cache
The helper asks the big directory. It says "ask the directory for that area". That one says "ask this office". The office has the real number.
The helper brings it back and saves a copy. Next time, it is much faster.
| Server | Job | Example |
|---|---|---|
| Recursive resolver | Takes your question, does the searching for you, and saves answers | Your internet provider's resolver, Google (8.8.8.8), Cloudflare (1.1.1.1) |
| Root server | Points to the right TLD server | The root servers named a.root-servers.net to m.root-servers.net |
| TLD server | Knows all domains that end in one extension, and points to the domain's own nameserver | The .com server |
| Authoritative server | Holds the real records of a domain and gives the final answer | The nameserver of example.com |
A few facts:
You type www.example.com. Here is what happens, in order.
Your browser asks itself: "Do I remember this IP?"
Your operating system keeps its own DNS cache. It also checks a small file called the hosts file.
/etc/hostsC:\Windows\System32\drivers\etc\hostsExample lines:
127.0.0.1 localhost
192.168.1.10 myserver.local
If the name is listed, your computer uses that IP directly. No DNS question is sent.
Your stub resolver sends the question to the recursive resolver. This is usually your internet provider's server, or a public one like 8.8.8.8 or 1.1.1.1.
It is called recursive because it does all the extra searching for you. You ask one question and get one answer.
If anyone asked about this name recently, the resolver already has the answer.
A resolver that already knows the .com server can skip the root. A resolver that already knows example.com's nameserver can skip the root and the TLD.
Resolver : "Who handles .com?"
Root : "Ask the .com TLD server."
The root server does not know the IP. It only knows who handles each extension.
Resolver : "Who handles example.com?"
.com server : "Ask example.com's own nameserver."
The TLD server still does not have the IP. It knows which nameserver is in charge.
This is the final stop. ✅
Resolver : "What is the IP of www.example.com?"
Authoritative : "It is 203.0.113.10."
This server holds the real records. You set it up when you register a domain.
The resolver:
203.0.113.10You type: www.example.com
|
v
[Browser cache] --- found ---> Done
| not found
v
[OS cache / hosts file] --- found ---> Done
| not found
v
[Recursive resolver] --- cached ---> Done
| not cached
v
[Root server] --> "Ask the .com TLD server"
|
v
[.com TLD server] --> "Ask example.com's nameserver"
|
v
[Authoritative server] --> "IP is 203.0.113.10"
|
v
Resolver saves it --> sends it to you --> page loads
Asking four servers every time would be slow. So answers are saved. This is called caching.
Your question is answered from the first place that has the answer:
TTL (Time To Live) is a number on every record. It says how many seconds the answer may be saved before it must be checked again. 3600 means 1 hour.
| TTL | Effect |
|---|---|
| Short (for example 300) | Changes spread fast, but there are more lookups |
| Long (for example 86400) | Fewer lookups, but changes spread slowly |
Run the same lookup twice, a few seconds apart:
dig +noall +answer example.com
sleep 5
dig +noall +answer example.com
Sample output (yours will differ):
example.com. 3600 IN A 203.0.113.10
example.com. 3595 IN A 203.0.113.10
The TTL went down by about 5. The resolver gave you its saved copy, and the copy is getting older.
When the TTL reaches 0, the resolver asks again. Big public resolvers have several caches, so the number may not always go down smoothly.
dig +trace makes dig do the root, TLD and authoritative steps itself:
dig +trace example.com
You will see three stages, one after another. Sample lines (shortened, yours will differ):
. 518400 IN NS a.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
example.com. 3600 IN A 203.0.113.10
a.root-servers.net to m.root-servers.net).com TLD serversBetween the groups, dig also prints ;; Received ... lines, which are left out here.
If this command times out, your network may block direct DNS questions. Try another network.
Windows (Command Prompt as Administrator):
ipconfig /flushdns
Expected output:
Successfully flushed the DNS Resolver Cache.
Linux, only if your system uses systemd-resolved:
resolvectl flush-caches
Do this when you changed a DNS record and your computer still shows the old address.
DNS is everywhere, so attackers target it too.
DNS spoofing (cache poisoning)
An attacker gets a fake IP into a resolver's cache. You type bank.com and land on a fake copy. Your password gets stolen.
DNSSEC
Adds a digital signature to DNS records. It proves the answer is genuine and was not changed on the way. It does not hide your questions.
DNS over HTTPS (DoH)
Encrypts the questions between your device and the resolver. Your internet provider can no longer see which sites you look up. The resolver you chose still sees them, so pick one you trust.
DNS tunneling
An attacker hides data inside DNS questions. It often shows up as many long, strange-looking subdomains. You will see this in CTF challenges and real breaches.
| Error / Symptom | Cause | Fix |
|---|---|---|
SERVFAIL |
The resolver could not get an answer | Try again later, or ask another resolver: dig @8.8.8.8 example.com |
ERR_NAME_NOT_RESOLVED in the browser |
DNS found no IP for that name | Check the spelling. If it is your domain, check that your A record is set |
| You still see the old IP after a change | The old answer is saved in a cache | Wait for the TTL to end, or clear your cache (Lab 3) |
| Site not loading after changing DNS | The old TTL has not expired yet | Wait for the old TTL to run out. It can take from minutes up to a day |
dig +trace times out |
Your network blocks direct DNS questions | Try another network |
Before moving your website to a new server, lower the TTL to 300.
Do it at least one old-TTL period before the move. If the old TTL was 3600, do it more than an hour early. After the move is done, raise it back.
That way, the change spreads in minutes, not hours.
- 4 server types: recursive resolver, root, TLD, authoritative
- The resolver does the searching, the authoritative server gives the final answer
- Lookup order: browser cache, OS cache and hosts file, resolver, root, TLD, authoritative
- Answers are cached in the browser, the OS and the resolver
- TTL = how many seconds an answer may be saved
- Lower the TTL to 300 before moving servers
- dig +trace shows the whole journey (Linux)
- Windows: ipconfig /flushdns | Linux: resolvectl flush-caches
- Spoofing = fake answer in the cache
- DNSSEC = signed answers | DoH = encrypted questions
- 13 root server identities (A to M), run by 12 organizations
TCP vs UDP : DNS uses UDP for most questions. Learn why, and when each one is the right choice.
TechWithJuned · Learn → Execute → Build
💬 Questions & Discussion
Have a doubt? Ask below — no login needed.
Loading comments...