After years in the field, I’ve figured out one universal truth: users come to you with a problem, you fix DNS, they leave happy.
Classic. So today we’re going deep on DNS in Linux — from the basics all the way down, with practical tricks, real cases from the trenches, and just enough dark humor to survive the process.
DNS in Plain English (For Those Who Just Got Here)
DNS is the internet’s phone book. Humans remember names like google.com, but networks need IP addresses like 142.250.185.206.
Linux takes a domain name and starts a quest: who to ask, who to trust, and where to cache the result so it doesn’t have to run the whole thing again in five minutes.
When DNS is broken, apps, browsers, and services start behaving like sulking children — they hang, time out, throw cryptic errors.
And you sit there thinking: «What the hell? The internet is working!»
Spoiler: the internet is working. DNS is not.
How Linux Resolves Names (The Anatomy of Pain)
The typical resolution chain looks like this:
/etc/hosts— the local database where admins love to write all sorts of nonsense- systemd-resolved / dnsmasq / nscd — local caching resolvers
/etc/resolv.conf— config file pointing to DNS servers- External DNS (Google, Cloudflare, corporate, whatever)
Important: on modern systems, /etc/resolv.conf is often a symlink to /run/systemd/resolve/stub-resolv.conf or something similar.
If you edit it directly and then everything «breaks by itself» — don’t be surprised.
NetworkManager or systemd-resolved will simply overwrite it, like an overprotective parent who doesn’t trust your decisions.
Practice: Checking DNS on Linux (5 Battle-Tested Examples)
Example 1: Basic Diagnostics with dig
The simplest way to check whether DNS is alive:
dig google.com
If there’s a response and you see an IP in the ANSWER SECTION — DNS is working.
If you get SERVFAIL, a timeout, or connection timed out; no servers could be reached — time to dig deeper.
Pro tip: Check the query time at the bottom. If it’s over 500ms — either your DNS server is slow, the network is lagging, or you’re querying a server on Mars.
Example 2: Tracing a DNS Query
Want to see exactly which servers handle your request? Use +trace:
dig +trace example.com
This shows the full path from the root DNS servers down to the final authoritative nameserver.
Perfect for debugging domain delegation and finding the exact link in the chain where everything broke.
Example 3: Querying a Specific DNS Server
Suspecting that your corporate DNS is misbehaving? Test it directly:
dig @8.8.8.8 google.com
dig @192.168.1.1 google.com
The first command asks Google’s DNS. The second asks your router.
Compare the results and you’ll know immediately who’s to blame.
Example 4: Reverse DNS Lookup (PTR Records)
Need to find out what hostname is associated with an IP?
dig -x 8.8.8.8
The answer should be something like dns.google.
If it’s empty — the reverse zone isn’t configured.
For mail servers, that’s a disaster. For everything else, it’s just sad.
Example 5: Querying All Record Types
Want to see everything DNS knows about a domain?
dig ANY example.com
You’ll get A, AAAA, MX, TXT, NS, and everything else in one shot.
Fair warning: some DNS servers ignore ANY queries because of DDoS abuse, but it’s worth trying.
systemd-resolved: Friend or Enemy?
On modern distributions (Ubuntu 18.04+, Fedora, Arch), DNS resolution is often handled by systemd-resolved.
It’s a daemon that caches queries, supports DNSSEC, handles split-DNS (different DNS for different interfaces), and is generally a solid piece of engineering.
There’s a catch, though: it listens on 127.0.0.53:53, not the usual 127.0.0.1:53.
Some legacy applications don’t understand this magic and start screaming.
Check its status:
systemctl status systemd-resolved
resolvectl status
The second command shows which DNS servers are being used per interface — incredibly useful when debugging VPN setups where DNS should go through the tunnel but mysteriously doesn’t.
Nuclear option: disabling systemd-resolved (when it’s just not cooperating):
systemctl disable --now systemd-resolved
rm /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf
echo "nameserver 1.1.1.1" >> /etc/resolv.conf
chattr +i /etc/resolv.conf
The last command makes the file immutable so nothing can overwrite it.
Brutal, but effective.
Pi-hole: The DNS That Kills Ads and Makes Marketers Cry
Pi-hole is a local DNS server with network-wide filtering built in.
It doesn’t just resolve domains — it blocks ads, trackers, telemetry, and general garbage before any of it reaches the browser.
Think about it: no YouTube ads, no banner ads, no analytics quietly phoning home to Google.
This isn’t just DNS. It’s a philosophy.
Why sysadmins and privacy-conscious people love Pi-hole:
- Minimal resource usage — runs comfortably on a Raspberry Pi Zero
- Dead-simple installation — one script and you’re done
- Web dashboard with detailed statistics (who queried what, when, and how often)
- Works as DNS for the entire network — configure it once, forget about it
- DNS-level blocking applies to every device: laptops, phones, Smart TVs, IoT devices
Installation (the classic, on Debian/Ubuntu):
curl -sSL https://install.pi-hole.net | bash
The script will ask a few questions, generate an admin password, and give you the web interface URL.
After that, point your router to Pi-hole as the DNS server — and your entire network breathes easier.
Ads? Gone. Trackers? Blocked. Happiness? Close enough.
Pro move: Pair Pi-hole with Unbound (a recursive resolver) so you’re not depending on any external DNS provider at all.
Full paranoia mode: activated.
MikroTik DNS: Fast, Simple, No-Nonsense (For Network People)
If you have a MikroTik in your network — you already have a DNS server.
Most people don’t think about this, but RouterOS ships with a fully capable caching DNS resolver out of the box.
It can cache queries, hand out its IP as DNS via DHCP, and act as a solid resolver for small networks.
What MikroTik DNS can do:
- Cache DNS queries (configurable TTL)
- Distribute its own IP as DNS server via DHCP
- Forward requests to upstream DNS (Google, Cloudflare, corporate)
- Add static DNS records (local hostname resolution without a dedicated DNS server)
Basic MikroTik DNS configuration via CLI:
/ip dns set servers=8.8.8.8,1.1.1.1 allow-remote-requests=yes cache-size=2048KiB
After this, the router accepts DNS queries from clients, caches them, and proxies them to Google/Cloudflare.
Simple, effective, zero BIND or dnsmasq headaches required.
Adding static records for your local network:
/ip dns static add name=server.local address=192.168.1.10
/ip dns static add name=nas.home address=192.168.1.20
/ip dns static add name=printer.office address=192.168.1.30
You’ve just built your own local DNS without spinning up a dedicated server.
For home labs and small offices — this is perfect. Need to add a new host? One command and it works.
Pro tip: You can set up periodic cache flushing via a script so the router drops stale records on schedule.
MikroTik even supports regexp-based DNS filtering — yes, it can do that too.
The Most Common DNS Mistakes I See Constantly (And You Will Too)
- Clients using different DNS servers — one host points to 8.8.8.8, another to the corporate resolver, another to the router’s DNS.
Result: some machines can resolve internal domains, others can’t. Pure chaos. - VPN without split-DNS — connected to VPN and all DNS queries go through the tunnel.
Local resources become unreachable, everything slows down.
Configuring split-DNS fixes this in under a minute. - systemd-resolved and NetworkManager fighting for control — both trying to write
/etc/resolv.conf, each overwriting the other.
DNS works intermittently. The fix: pick one, disable the other. - Forgotten /etc/hosts entries — someone added
192.168.1.100 google.comfor a test, forgot to remove it.
Now Google doesn’t open, and you spend an hour hunting the problem before checking hosts. - High TTL after a DNS change — you updated a DNS record but it’s not propagating.
Check the TTL — it’s 86400 seconds (24 hours). So you wait. Drink coffee. Repeat.
If something «works sometimes» — check DNS.
If everything «just fixed itself» — it was the cache.
If absolutely nothing works — check DNS first, then look for other causes.
/etc/hosts: Old, Useful, and Surprisingly Dangerous
The /etc/hosts file is like your grandmother’s address book: old-fashioned, but occasionally invaluable.
It lets you manually map IP addresses to domain names, bypassing DNS entirely.
# Local hosts
192.168.1.10 server.local
192.168.1.20 nas.home
# Ad blocking — the hardcore method
0.0.0.0 ads.example.com
0.0.0.0 tracker.analytics.com
Pros: always works, takes priority over DNS, instant.
Cons: doesn’t scale, easy to forget about, trivially easy to break something accidentally.
Real case: A developer mapped a production domain to a test server IP in /etc/hosts, forgot about it, deployed to production a week later, and couldn’t figure out why everything worked fine on his machine but was broken for everyone else.
He spent three hours debugging before he remembered the hosts file.
dnsmasq: Lightweight and Versatile
If Pi-hole feels like overkill and BIND feels like piloting a cargo ship, there’s a perfect middle ground: dnsmasq.
It’s a lightweight DNS/DHCP server that handles caching, address distribution, and local resolution with minimal fuss.
Installation:
apt install dnsmasq
Basic config (/etc/dnsmasq.conf):
# Listen on loopback only
listen-address=127.0.0.1
# Upstream DNS servers
server=8.8.8.8
server=1.1.1.1
# Cache size
cache-size=1000
# Local domain override
address=/local.dev/192.168.1.10
Restart:
systemctl restart dnsmasq
And there you go — your own local DNS server with caching.
Light, fast, no drama.
DNSSEC: Paranoia Mode Enabled
DNSSEC is a mechanism for cryptographically signing DNS records.
It protects against DNS spoofing, cache poisoning, and other fun attacks.
In theory, it sounds great. In practice, it’s a headache.
Check whether a domain supports DNSSEC:
dig +dnssec example.com
If the response contains RRSIG records — DNSSEC is active.
If not — it’s either not configured or broken.
My honest opinion: DNSSEC is like antivirus on a server. In an ideal world it should be there, but in practice it creates more problems than it solves.
Set it up if you genuinely need it (finance, government, high-security environments).
Otherwise, focus your energy elsewhere.
How to Know If the Problem Is Actually DNS (Checklist)
- Ping works by IP, fails by hostname:
ping 8.8.8.8 # works ping google.com # failsDNS is broken. Full stop.
- nslookup/dig returns an error:
nslookup google.com # ;; connection timed out; no servers could be reachedDNS server is unreachable or incorrectly configured.
- Different results on different machines — one machine resolves the domain, another doesn’t.
They’re probably using different DNS servers or have different/etc/hostscontents. - Browser shows «DNS_PROBE_FINISHED_NXDOMAIN» — either the domain doesn’t exist, or DNS can’t see it from here.
- curl/wget works by IP but not by hostname — textbook DNS failure.
Conclusion: DNS Is Not Just a Service — It’s an Art Form
DNS is the foundation of networking. Without it, the entire internet collapses into a meaningless pile of IP addresses.
Pi-hole makes it smart and kills every piece of advertising garbage before it reaches your devices.
MikroTik makes it convenient and bakes it right into your router.
Linux gives you the flexibility and tools to do whatever you need — including things you probably shouldn’t.
Once you understand how all these pieces fit together, you stop panicking when someone says «the website won’t load» and start fixing methodically.
Panic is for users. We’re above that. 😉
P.S. If DNS still isn’t working after all this — try rebooting the router.
Seriously. It fixes things 50% of the time and nobody knows why.
Got questions or a DNS horror story of your own? Drop it in the comments — we read every one.
Subscribe to our Telegram channel for more hands-on sysadmin guides, scripts, and network tools.
Author: over_dude
Оставайтесь на связи
Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.
Подписаться на IT-Аптеку →
