Quest 3
Name Resolution Order
When tools disagree
The situation
A service connects to the wrong server, but only from one box. `dig` shows the right IP; the app uses a different one. The culprit isn't DNS — it's the order the system resolves names.
`/etc/nsswitch.conf` sets the lookup order. The default `hosts: files dns` means **/etc/hosts wins over DNS**. A leftover hosts entry will silently override the correct DNS answer for every normal program — but not for `dig`.
⚠️If `getent`/apps and `dig` disagree, suspect `/etc/hosts` and the nsswitch order before you touch the DNS server.
/etc/hosts (files)10.0.0.99 — checked first, wins
DNS10.10.10.40 — never reached for this name
Why it matters in production: 'Works on my machine' DNS bugs are very often a stray /etc/hosts line. Knowing nsswitch order turns a baffling outage into a one-line fix.
Objective
Find why cache.shellquest.local resolves to two different IPs depending on the tool — and explain which the app uses.
learner@nameforge
The Nameforge lab is live. Type `help` to see what this lab understands.
Use the chips below to get started — then go off-script.
learner@nameforge:~$
Evidence
- ○Resolved via the system (getent)
- ○Queried DNS directly (dig)
- ○Read the resolution order
- ○Confirmed files are checked before dns
Next: `getent hosts cache.shellquest.local` returns the IP the app will use.
Hints
Stuck? Reveal hints one at a time — the validation panel already tells you what evidence is missing.