DEV Community: Ciarán Doyle

DNS Troubleshooting Checklist: The 10-Step Process I Use for Every Client Call

Ciarán Doyle — Sat, 04 Apr 2026 08:26:50 +0000

It happens every week without fail. The phone rings, it's a client in a panic — a shop in Tuam, a solicitor's office in Clifden, a small hotel out near Connemara — and the first thing they say is "the internet's gone." Nine times out of ten, it's not the internet. It's DNS.

DNS troubleshooting is one of those things that looks like black magic until you have a repeatable process. Over the past decade doing network and infrastructure work across the West of Ireland, I've built a DNS troubleshooting checklist that I run through on every single call, in roughly the same order, every time. It gets the job done. Here it is.

Step 1: Confirm It's Actually a DNS Issue

Before you touch anything, verify the problem. A DNS failure means names aren't resolving — but other network issues can look identical to the uninitiated.

Quick test:

ping 8.8.8.8

If that works but a website doesn't load, you've got a DNS issue. If even the ping fails, you're dealing with a broader connectivity problem and DNS is a red herring. Don't go chasing DNS gremlins when the router's acting the maggot entirely.

Step 2: Check What DNS Servers the Device Is Using

This is where most people skip straight past the obvious. Find out what DNS resolver the affected machine is actually pointing at.

Windows:

ipconfig /all

Linux/Mac:

cat /etc/resolv.conf
# or
nmcli dev show | grep DNS

Look at the DNS Servers line. Is it pointing at your router (e.g. 192.168.1.1)? A corporate DNS server? A public resolver like 1.1.1.1 or 8.8.8.8? Knowing this shapes every step that follows.

Step 3: Try a Direct DNS Query with nslookup

This is your first real diagnostic step. nslookup troubleshooting is fundamental — it lets you query DNS directly, bypassing the browser cache and OS resolver cache.

nslookup example.com

Then try querying a known public resolver directly:

nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

If the domain resolves against 8.8.8.8 but not against your local DNS server, your problem is upstream of the client device — it's the resolver or the network path to it.

If you're on a machine without command-line access, I use publicdns.info's online dig tool to run the same queries from a browser. It's saved me more than a few times when I'm remote-assisting someone who hasn't got a terminal window to hand.

Step 4: Flush the Local DNS Cache

Cached records can cause DNS not resolving issues long after the actual problem is fixed. Always flush before assuming something is still broken.

Windows:

ipconfig /flushdns

Mac:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

I had a client in Galway city — a small accountancy firm — swearing blind their new website still wasn't showing up a full day after their DNS change. Flushed the cache, restarted the browser. Sorted in 30 seconds.

Step 5: Check TTL and Propagation Status

If you're dealing with a recent DNS change — new hosting, migrated domain, updated records — propagation time is a factor. TTL (Time to Live) determines how long resolvers cache a record before fetching a fresh copy.

Check the current TTL on the record:

dig example.com A

Look at the answer section — the number before IN A is the TTL in seconds. If it's 86400, that's 24 hours. If someone lowered the TTL after making the change, it's too late — the old TTL was already cached.

I use the DNS propagation checker at publicdns.info to see how a record looks from different resolvers globally. It's handy when a client is asking "is it live yet?" and you need a quick answer without spinning up a VPN.

Step 6: Query Authoritative Nameservers Directly

Don't trust what your local resolver tells you. Go straight to the source.

# Find the authoritative nameservers
dig example.com NS

# Query one of them directly
dig @ns1.example-nameserver.com example.com A

If the authoritative nameserver returns the correct record but end users are seeing the wrong one, the issue is caching at an intermediate resolver — not the DNS configuration itself. This distinction matters when you're telling a client what's actually wrong.

Step 7: Check for DNS Hijacking or Interception

This one's more common than people think, especially on compromised routers or in environments with overly aggressive filtering. To fix DNS issues caused by hijacking, you need to spot it first.

nslookup google.com

If the IP address returned is completely unexpected — especially if it's a private IP like 192.168.x.x or 10.x.x.x when querying a public domain — something is intercepting your DNS queries. Check the router firmware, look for rogue DHCP entries, and inspect any firewall or proxy rules.

I've seen this twice in small businesses on the Wild Atlantic Way corridor — routers compromised and quietly redirecting DNS traffic. Not fun to unravel, but it's always worth checking.

Step 8: Test with Alternative DNS Resolvers

Swap the DNS server temporarily to rule out resolver-specific issues. This is one of the fastest DNS diagnostic steps you can run.

On Windows (temporary):

netsh interface ip set dns "Local Area Connection" static 1.1.1.1

Test the resolution again. If it works with Cloudflare's 1.1.1.1 but not your ISP's resolver, the ISP resolver is the problem — either it's down, or it's returning stale/incorrect data. Cloudflare's DNS documentation has good guidance on setting this permanently across different OS types.

Step 9: Check DNSSEC Validation

If DNSSEC is enabled on a domain, a misconfiguration will cause resolvers to return SERVFAIL even though the zone itself is fine. This one catches people out badly.

dig example.com +dnssec

Look for the AD flag in the response — that means DNSSEC validated successfully. A SERVFAIL with no useful error usually points at a broken DS record or an expired RRSIG. The IETF's DNSSEC operational guidance (RFC 6781) is dry reading, but it's the definitive reference if you need to go deep on this.

Step 10: Document and Report

This is the one people always skip, and it's the one that pays off six months later when the exact same issue reappears.

Write down:

What the symptoms were
What resolver was in use
Which step identified the root cause
What the fix was
Any TTL or propagation times involved

I keep a simple log per client. When someone rings me with "the DNS is gone again," I can pull up the notes from the last time in under a minute. Half the time, it's the same problem — same misconfigured router, same ISP resolver dropping the ball on a Friday afternoon.

Final Word

DNS is boring until it breaks, and when it breaks everything stops. Having a repeatable DNS troubleshooting checklist means you're not guessing — you're working through a proven set of diagnostic steps in the right order.

The tools are mostly free. nslookup, dig, ipconfig — they're on every machine. When I'm working remotely and the client doesn't have a terminal, publicdns.info's dig tool does the job straight from the browser.

Run the list, trust the process, and you'll have most DNS issues sorted before the kettle's even boiled.

Why Your Website Works in Chrome but Not Safari: A DNS Caching Deep Dive

Ciarán Doyle — Thu, 02 Apr 2026 22:15:21 +0000

A cafe owner in Salthill rang me last month in a panic. "My website's down." I checked on my phone — loaded fine. She checked on hers — nothing. Her husband's laptop? Also nothing. Her daughter's phone? Worked perfectly.

Same WiFi. Same network. Some devices could reach the site, others couldn't. Classic DNS caching issue, and it catches people out more often than you'd think.

What actually happened

She'd migrated her site to a new host the day before. The domain's DNS records were updated to point to the new server's IP address. But here's the thing — not every device got the memo at the same time.

DNS doesn't update instantly. When you change a DNS record, the old IP address is cached at multiple levels: your browser, your operating system, your router, your ISP's resolver. Each cache has its own expiry timer (the TTL — Time to Live), and until that timer runs out, the device keeps using the old, stale IP.

Her phone had cleared its cache recently (she'd restarted it that morning). Her husband's laptop hadn't been restarted in a week. The browser was still sending requests to the old server, which was already shut down.

Where DNS gets cached

There are four layers of caching between you and a DNS answer:

1. Browser cache — Chrome, Firefox, Safari, and Edge all maintain their own DNS caches, separate from the OS. This is the most common source of "works in one browser, not another" problems.

2. OS cache — Your operating system caches DNS lookups too. This affects all applications on the device.

3. Router cache — Some routers cache DNS responses. Less common with modern routers, but it happens.

4. ISP resolver cache — Your ISP's DNS server caches responses based on the TTL set by the domain owner. You can't flush this one — you have to wait, or switch to a different resolver.

How browsers handle DNS caching differently

This is where it gets interesting. Each browser has its own caching behaviour, and they don't all agree:

Browser	Default DNS cache TTL	How to clear
Chrome	60 seconds (ignores TTL > 60s)	`chrome://net-internals/#dns` → Clear host cache
Firefox	60 seconds	`about:networking#dns` → Clear DNS Cache
Safari	Follows OS cache	Clear via OS (see below)
Edge	Same as Chrome (Chromium-based)	`edge://net-internals/#dns` → Clear host cache

Chrome aggressively caps DNS TTL at 60 seconds internally, regardless of what the domain's actual TTL is set to. That's why Chrome often picks up DNS changes faster than Safari — Safari relies on macOS's system-level DNS cache, which respects the original TTL and can hold onto stale records for hours.

This is exactly why my client's daughter (Chrome on her phone) could see the new site while her husband (Safari on his MacBook) couldn't.

How to flush DNS on every platform

When you're troubleshooting DNS caching issues, flushing the cache forces your device to do a fresh lookup:

macOS

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Windows

ipconfig /flushdns

Linux (systemd-resolved)

sudo systemd-resolve --flush-caches

Chrome (all platforms)

Navigate to chrome://net-internals/#dns and click "Clear host cache". Then go to chrome://net-internals/#sockets and click "Flush socket pools" — this clears any connections still pinned to the old IP.

Firefox

Navigate to about:networking#dns and click "Clear DNS Cache".

How to verify the fix

After flushing, confirm your device is resolving to the correct IP:

dig example.com +short

Compare the result to what you expect. If you don't have dig installed, use the online dig tool at publicdns.info — it queries from an external server, so you'll see the current authoritative answer without any local caching interfering.

If your local result differs from what publicdns.info shows, something between you and the authoritative server is still caching the old record.

How to prevent this in the first place

If you're planning a migration, lower the DNS TTL before you move:

48 hours before migration: Drop the TTL to 300 seconds (5 minutes) or lower
Wait for the old TTL to expire — if it was set to 86400 (24 hours), you need to wait at least that long after lowering it
Do the migration — update DNS records to the new IP
After everything's stable: Raise the TTL back to a sensible value (3600-86400)

Most DNS caching issues after migrations happen because someone skipped step 1. They change the IP while the TTL is still set to 24 hours, and then half their users are stuck on the old address for a day.

You can check what TTL a domain currently has using publicdns.info — compare responses from different DNS servers to see if they've all picked up the change.

The router wildcard

One thing that caught me out on this particular job: after flushing the DNS on her husband's laptop, it still didn't work. Turned out their router (an older Eir-supplied one) was caching DNS responses too.

Power-cycling the router cleared it. Not elegant, but effective. If flushing the device cache doesn't help and you're behind a home router, this is worth trying before you go down more complicated debugging paths.

Quick reference

"Works in Chrome, not Safari" → Chrome caps DNS cache at 60s, Safari uses OS cache. Flush macOS DNS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
"Works on phone, not laptop" → Phone was restarted recently, laptop has stale cache. Flush DNS on the laptop.
"Works nowhere on my network" → Router is caching. Power-cycle it.
"Works on my network, not others" → ISP resolver still has old record. Wait for TTL to expire, or switch to a public DNS like 1.1.1.1 or 8.8.8.8.
Before any migration → Lower TTL to 300 seconds at least 48 hours ahead.
Verify current state → Check publicdns.info/tools/dig to see what the rest of the world sees.

The Salthill cafe owner? Flushed DNS on the laptop, power-cycled the router, and everything was grand. Total fix time: about three minutes once I knew what the problem was. The trick is knowing where to look.

DNS for Sysadmins: The Commands and Tools You Actually Need

Ciarán Doyle — Thu, 02 Apr 2026 22:08:49 +0000

DNS comes up in sysadmin work constantly. Server migrations, email deliverability issues, "the website isn't loading" tickets, certificate renewals, debugging weird routing problems. You don't need to be a DNS expert, but you do need a solid toolkit.

Here's the DNS commands and tools I use regularly, with real examples from actual problems I've dealt with.

dig - the workhorse

dig is the most useful DNS tool you'll ever learn. It queries DNS servers and shows you exactly what they return, with full detail.

Basic lookup

dig example.com

This queries your system's default DNS resolver for the A record. The output is verbose but everything in it is useful.

Query a specific DNS server

dig @8.8.8.8 example.com

This bypasses your local resolver and asks Google directly. Essential for comparing what different resolvers return.

Query specific record types

dig example.com MX    # Mail servers
dig example.com TXT   # SPF, DKIM, DMARC, verification records
dig example.com NS    # Nameservers
dig example.com AAAA  # IPv6 addresses
dig example.com CAA   # Certificate Authority Authorization
dig example.com SOA   # Start of Authority (serial, refresh, retry)

Short output

dig +short example.com

When you just want the IP address, no fuss. I use +short in scripts all the time.

Trace the full resolution path

dig +trace example.com

This shows every step of DNS resolution: root servers, TLD servers, authoritative servers. Brilliant for finding exactly where a lookup goes wrong.

Check TTL

dig example.com | grep -A1 "ANSWER SECTION"

The number between the domain name and record type is the remaining TTL. Useful before migrations.

Reverse lookup

dig -x 8.8.8.8

Turns an IP address back into a hostname. Handy for identifying mystery IPs in logs.

nslookup - quick and dirty

nslookup is older and simpler than dig. I use it mostly on Windows machines where dig isn't installed by default.

nslookup example.com
nslookup example.com 8.8.8.8
nslookup -type=MX example.com

It works, but the output is harder to parse than dig's. If you have both available, use dig.

host - the one-liner

host gives you the basics with minimal output:

host example.com

Returns A, AAAA, and MX records in a single readable line each. I use it when I just need a quick "does this resolve?" check.

host -t TXT example.com   # Specific record type
host example.com 1.1.1.1  # Query specific server

whois - domain ownership and registration

When you need to know who owns a domain, when it expires, or which registrar it's with:

whois example.com

The output format varies by registrar and TLD but you'll usually find registration date, expiry date, registrar name, and nameservers.

If you're not at a terminal, publicdns.info has a web-based WHOIS tool that works with both domains and IPs. I keep it bookmarked for when I'm on a call with a client and need to check something quickly.

Real-world scenarios

"Email isn't being delivered"

Nine times out of ten, it's DNS. Check:

# MX records - where should email go?
dig example.com MX +short

# SPF - who's allowed to send as this domain?
dig example.com TXT | grep spf

# DKIM - signature record
dig selector._domainkey.example.com TXT

# DMARC - policy
dig _dmarc.example.com TXT

If SPF is missing or wrong, email goes to spam. If MX records point to the wrong server, email doesn't arrive at all.

"SSL certificate renewal is failing"

Let's Encrypt and other CAs use DNS to validate domain ownership:

# Check the ACME challenge record exists
dig _acme-challenge.example.com TXT +short

If this returns empty, your cert renewal script didn't create the record, or DNS propagation hasn't reached the CA's resolver yet.

Also check CAA records:

dig example.com CAA +short

If CAA is set and doesn't include your CA, certificate issuance will be blocked.

"The website loads from some places but not others"

Usually a propagation issue after a DNS change, or a geo-DNS setup:

# Compare what different resolvers see
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
dig @9.9.9.9 example.com +short

If they return different IPs, use a propagation checker to see the global picture.

"Is DNSSEC working on this domain?"

dig example.com +dnssec

Look for the ad flag in the response (Authenticated Data). If it's there, DNSSEC is validating.

Web-based alternatives

Sometimes you're not at a terminal. I keep publicdns.info/tools/dig bookmarked. It does proper dig queries from a browser - all record types, choice of DNS provider, shows the full response. Covers 90% of what I need when I can't open a terminal.

Quick reference card

What you need	Command
A record lookup	`dig example.com`
Specific server	`dig @1.1.1.1 example.com`
MX records	`dig example.com MX +short`
TXT records (SPF/DKIM)	`dig example.com TXT`
Nameservers	`dig example.com NS +short`
Full trace	`dig +trace example.com`
Reverse lookup	`dig -x 8.8.8.8`
Domain info	`whois example.com`
DNSSEC check	`dig example.com +dnssec`

DNS looks simple until it isn't. Start with dig, check the obvious records, and work outward from there. Most DNS issues turn out to be simpler than they first appear.

I Changed My DNS and My Site Disappeared: A Quick Guide to DNS Propagation

Ciarán Doyle — Thu, 02 Apr 2026 21:59:05 +0000

You've just migrated your website to a new host. You updated the nameservers at your registrar. You triple-checked everything. And now your site is gone. Vanished. Your client is ringing you in a panic.

Don't worry. Your site is fine. It's DNS propagation, and it's completely normal.

What's actually happening

When you change DNS records - nameservers, A records, CNAME records, whatever - the change doesn't take effect instantly across the entire internet. That's because DNS is cached at multiple levels:

Your browser caches DNS lookups (usually for a few minutes)
Your operating system caches them too
Your router might cache them
Your ISP's DNS resolver caches them (this is the big one)
Other DNS resolvers (Google, Cloudflare, etc.) all have their own caches

When you make a change, it updates at the authoritative nameserver immediately. But all those cached copies don't know about the change yet. They'll keep serving the old record until their cache expires.

That expiry time is controlled by the TTL (Time To Live) value on the DNS record.

TTL: the number that controls propagation speed

Every DNS record has a TTL value, measured in seconds. It tells resolvers "cache this answer for this many seconds, then check again."

Common TTL values:

300 (5 minutes) - for records that change frequently
3600 (1 hour) - a reasonable default
86400 (24 hours) - for records that rarely change

If your A record has a TTL of 86400, it means every DNS resolver that cached it will keep the old value for up to 24 hours before checking for updates.

This is why the standard advice is "DNS propagation takes 24-48 hours." In reality, it takes exactly as long as the TTL on the old record. If your TTL was 300 seconds, most of the internet will see the change within 5-10 minutes.

The trick: lower TTL before migrating

If you know you're going to change DNS records, lower the TTL a day or two before the change:

Day before migration: Change TTL from 86400 to 300
Wait 24 hours (so the old high TTL expires everywhere)
Make your DNS change
Within 5-10 minutes, most resolvers will pick up the new value
After migration is stable: raise TTL back to 3600 or whatever you prefer

This is the single most useful DNS trick I know. I do it for every migration and it saves a pile of stress.

How to check propagation progress

You're sitting there after making the change and you want to know: has it propagated?

From the command line

# Check what different resolvers see
dig @8.8.8.8 yourdomain.com A
dig @1.1.1.1 yourdomain.com A
dig @9.9.9.9 yourdomain.com A

If they all return your new IP, you're mostly there. If some still show the old IP, those resolvers haven't refreshed their cache yet.

Using a propagation checker

For a more complete picture, use a tool that checks from multiple locations worldwide. publicdns.info has a propagation checker that queries servers across different countries simultaneously, so you can see exactly where the change has landed and where it hasn't.

This is what I pull up on screen when a client is asking "is it done yet?" - shows them the green ticks rolling in across different regions.

Common propagation problems

"My site works for me but not for my client"

Your machine probably cached the new DNS record already (or you flushed your cache). Your client's ISP resolver still has the old one cached. Just wait for their TTL to expire.

"It's been 48 hours and it still hasn't propagated"

Something else is wrong. After 48 hours, every cache in the world should have expired. Check:

Did you actually update the right records? (Check at your registrar, not just your DNS host)
Are the nameservers correct? (dig NS yourdomain.com)
Is there a DNSSEC issue? (Misconfigured DNSSEC can make your domain unresolvable)

"It propagated and then went back to the old value"

This can happen with load-balanced DNS or if you have conflicting records. Check that you don't have the old A record still present alongside the new one.

"My email stopped working after the DNS change"

MX records. When you change nameservers, make sure the MX records exist on the new DNS host. This catches people out all the time. Email DNS is just as important as web DNS.

Checking your current TTL

Before making any DNS change, check what TTL your records currently have:

dig yourdomain.com A | grep -A1 "ANSWER SECTION"

The number after the record name is the TTL in seconds. If it shows 86400, you'll want to lower it before making changes.

After the change

Once propagation is complete and everything is working:

Raise your TTL back to something reasonable (3600-86400)
Test from multiple locations to confirm
Keep the old server running for a few days as a safety net
Check your email is still working (MX records)

The short version

DNS propagation isn't mysterious. It's just caching. Lower your TTL before making changes, use a propagation checker to monitor progress, and wait for the old caches to expire. Your site didn't disappear - the internet just hasn't all got the memo yet.

Setting Up Pi-hole? Here's How to Pick Your Upstream DNS

Ciarán Doyle — Thu, 02 Apr 2026 21:57:45 +0000

You've got Pi-hole installed. The dashboard is up. Ads are getting blocked. Grand. But there's one decision that trips people up more than it should: which upstream DNS server should Pi-hole forward queries to?

Now, pi-hole blocks ads by intercepting DNS queries for known ad domains and returning nothing. But for everything else, it needs to forward the query to an actual DNS resolver. That upstream resolver is doing the real work of turning domain names into IP addresses. Picking the right one matters.

What the Pi-hole docs suggest

The Pi-hole setup wizard gives you a list of common options:

Google (8.8.8.8)
OpenDNS (208.67.222.222)
Cloudflare (1.1.1.1)
Quad9 (9.9.9.9)

Any of these will work. But "works" and "works well for you" aren't the same thing.

What to optimise for

Speed

I had a client in Connemara last month who had this exact issue, and DNS latency compounds. A page with 40 resources from 20 different domains means 20 DNS lookups. If each one takes 50ms instead of 5ms, that's nearly a full second added to your page load.

The fastest upstream for you depends on where you are geographically. Google and Cloudflare have data centres everywhere, so they're usually fast. But a smaller regional provider might be closer to you.

Test it:

# From the machine running Pi-hole
dig @8.8.8.8 example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @9.9.9.9 example.com | grep "Query time"

Honestly, run each one a few times. The first query to a new domain is always slower (cache miss). It's the second and third queries that show you the real-world performance.

If you want to test a wider range of servers, publicdns.info has a directory of thousands of live-tested public DNS servers. You can filter by country to find resolvers close to you. I've found some regional servers in Ireland that consistently outperform the big names for my setup.

Privacy

Pi-hole itself doesn't encrypt DNS queries to the upstream. So your ISP can still see which domains you're looking up (just not the ad ones, since Pi-hole blocks those locally).

If privacy matters, you've got a few options:

Use a privacy-focused upstream - Quad9 or Cloudflare with their no-logging policies
Add Unbound - run a local recursive resolver alongside Pi-hole. Queries go directly to authoritative servers instead of a third-party resolver
Enable DNS over TLS - encrypt the connection between Pi-hole and the upstream

Option 2 (Unbound) is what I use and recommend. It's more work to set up but it means your DNS queries don't go to any third party at all.

Security

Some upstreams add a layer of security:

Quad9 blocks known malicious domains before they resolve. It uses threat intelligence feeds, so if someone on your network clicks a phishing link, Quad9 might catch it.
OpenDNS lets you configure custom filtering categories through their dashboard.
AdGuard DNS blocks ads and trackers at the resolver level (though Pi-hole already does this).

I like layering Quad9 as upstream with Pi-hole handling ad blocking. Two layers of protection, different approaches.

How many upstream servers should you set?

Pi-hole lets you configure multiple upstream DNS servers. The question is: should you?

One server: Simplest. All queries go to the same place. If it goes down, DNS breaks until you change it.

Two servers: Most people should do this. Pi-hole will use both and failover between them. Pick two from different providers for redundancy (e.g., Cloudflare + Quad9).

Three or more: Diminishing returns. Two is enough for redundancy. Adding more can actually slow things down slightly as Pi-hole rotates between them.

My setup: two upstream servers from different providers. If Cloudflare has a bad day, Quad9 picks up the slack.

The Unbound option

For maximum control, run Unbound as a local recursive resolver and point Pi-hole at it. Instead of forwarding queries to Google or Cloudflare, Unbound goes directly to the authoritative DNS servers.

Client -> Pi-hole (ad blocking) -> Unbound (recursive) -> Root/TLD/Auth servers

This means:

No third party sees all your queries
You're not trusting any single DNS provider
You get DNSSEC validation locally
Slightly slower first lookups (no shared cache), but Unbound caches aggressively

Setting it up is a separate guide, but the Pi-hole docs cover it well. It's about 15 minutes of work and it's been rock solid for me.

My recommended setups

Simple and fast:

Pi-hole -> Cloudflare (1.1.1.1) + Quad9 (9.9.9.9)

Privacy-focused:

Pi-hole -> Unbound (local recursive resolver)

Maximum protection:

Pi-hole -> Unbound -> DNS over TLS to Quad9 (with malware blocking)

Testing your setup

After configuring upstream DNS, test from a device on your network:

# Should resolve (not an ad domain)
dig google.com @<pi-hole-ip>

# Should be blocked (ad domain)
dig ads.google.com @<pi-hole-ip>

# Check query time
dig example.com @<pi-hole-ip> | grep "Query time"

Then check the Pi-hole dashboard. You should see queries flowing through, with ad domains getting blocked and everything else resolving normally.

Wrapping up

The upstream DNS choice isn't something you need to agonise over. Cloudflare + Quad9 is a solid default that gives you speed, privacy, and malware protection. If you want to go further, add Unbound for full recursive resolution.

The important thing is that you've got Pi-hole running at all. That's already a massive improvement over bare ISP DNS. The upstream choice is just fine-tuning from there.

DoH vs DoT: Which Encrypted DNS Should You Actually Use?

Ciarán Doyle — Tue, 31 Mar 2026 22:34:39 +0000

Regular DNS queries are sent in plain text. Anyone on the network path between you and the resolver - your ISP, your coffee shop's WiFi, whoever - can see exactly which domains you're looking up. That's not great for privacy.

Two protocols fix this: DNS over HTTPS (DoH) and DNS over TLS (DoT). Both encrypt your queries. But they work differently and the choice between them isn't just technical - it's political.

What DoT does

DNS over TLS wraps regular DNS queries in a TLS tunnel on port 853. It's straightforward: same DNS protocol, just encrypted.

Your device --[TLS encrypted, port 853]--> DNS resolver

Your ISP can see you're connecting to a DNS server on port 853 (so they know you're using DoT), but they can't see what you're looking up.

Pros

Clean separation - DNS stays on its own dedicated port
Network admins can see that DNS traffic exists (useful for monitoring and policy)
Slightly lower overhead than DoH in some implementations
Easier to implement in DNS-specific software

Cons

Easy to block - a network admin just blocks port 853 and DoT stops working
Not supported in most web browsers natively
Requires OS-level or resolver-level configuration

What DoH does

DNS over HTTPS sends DNS queries inside regular HTTPS traffic on port 443. From the outside, it looks identical to normal web browsing.

Your device --[HTTPS, port 443]--> DNS resolver (looks like any web traffic)

Your ISP can't tell DNS queries apart from you browsing a website. That's the whole point.

Pros

Nearly impossible to block without breaking all HTTPS traffic
Supported in Firefox, Chrome, Edge, and most modern browsers
Works through corporate firewalls that allow HTTPS
Harder for ISPs to detect and interfere with

Cons

Mixes DNS with web traffic, which complicates network monitoring
Corporate/school network admins lose visibility into DNS queries
Adds HTTP overhead to every DNS lookup
Browsers may bypass the system DNS resolver entirely, which can break split-horizon DNS setups

The political angle

This is where it gets interesting. DoH and DoT aren't just technical choices - they represent different philosophies about who should control DNS.

I've found that i learned this the hard way on a job in Salthill, and DoT says: "DNS should be encrypted, but network administrators should still be able to see that DNS is happening and apply policy to it."

DoH says: "DNS should be encrypted AND invisible. Nobody between you and the resolver should be able to interfere, including your network admin."

ISPs generally dislike DoH because it takes away their ability to monitor, filter, or monetise DNS queries. Network admins in enterprises dislike it because it bypasses their security policies. Privacy advocates love it because it makes DNS surveillance much harder.

Neither position is wrong. It depends on your context.

When to use which

Use DoT when:

You control the full network (your homelab, your business)
You run Pi-hole, AdGuard Home, or Unbound as a local resolver
You want encrypted DNS but also want your network admin to be able to monitor DNS traffic patterns
You're configuring DNS at the OS or router level

Use DoH when:

You're on someone else's network (hotel WiFi, coffee shop, airport)
Your ISP is known to hijack or snoop on DNS queries
You want maximum privacy and minimum interference
You're fine with browser-level DNS configuration

Use both when:

You run a local resolver (Pi-hole/Unbound) with DoT upstream, and also enable DoH in browsers as a fallback
This is actually what I set up for most clients. Belt and braces.

How to set them up

DoH in Firefox

Settings > Privacy & Security > scroll to DNS over HTTPS
Select "Max Protection" or "Increased Protection"
Choose a provider (Cloudflare, NextDNS, or custom)

DoH in Chrome

Settings > Privacy and security > Security
"Use secure DNS" > select a provider

DoT on Android

Settings > Network > Private DNS
Enter a hostname like dns.quad9.net or one.one.one.one

DoT with systemd-resolved (Linux)

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes

DoT with Pi-hole + Unbound

This is the setup I use in my own homelab and recommend to clients. Pi-hole handles ad blocking, Unbound does recursive resolution with DoT to a trusted upstream. You get filtering, privacy, and full control.

How to test if it's working

After setting up encrypted DNS, verify it's actually encrypting:

Cloudflare test: Visit 1.1.1.1/help - it tells you if you're using DoH/DoT
DNS leak test: Use a DNS privacy checker to see if your queries are encrypted and whether they're leaking through other paths
Wireshark: If you want to be thorough, capture traffic and confirm there's no plaintext DNS on port 53

Performance considerations

Both DoH and DoT add a small amount of latency to the first query (TLS handshake). After that, the connection stays open and subsequent queries are about the same speed as plain DNS.

In practice, the difference is negligible for normal browsing. If you're running a high-throughput DNS resolver handling thousands of queries per second, DoT has marginally less overhead because it doesn't have the HTTP layer.

From what I've seen, for home users and small businesses? You won't notice the difference. Pick based on your privacy and control needs, not performance.

My recommendation

For most people: turn on DoH in your browser. It takes 30 seconds, it's free, and it stops your ISP from logging every domain you visit. Cloudflare or Quad9 are both solid choices.

For anyone running their own network: set up DoT at the resolver level (Pi-hole, Unbound, or your router if it supports it). This gives you encrypted upstream queries while keeping full visibility and control over your own network's DNS.

And if you want to check whether your setup is actually private, run it through a DNS privacy check. No point configuring encrypted DNS if something else is leaking your queries out the side door.

DNS Not Working? Here's How to Fix It in 5 Minutes

Ciarán Doyle — Tue, 31 Mar 2026 22:32:53 +0000

"The internet is down." I hear this at least twice a week from clients. And about half the time, it's not the internet at all. It's DNS.

Your connection is fine. Your router is fine. But DNS has stopped resolving, so every website looks unreachable. The good news is this is usually fixable in a few minutes once you know where to look.

Step 1: Confirm it's actually DNS

Before you start changing settings, make sure DNS is the problem and not something else:

ping 8.8.8.8

If this works (you get replies), your internet connection is fine. The problem is DNS. If this fails too, it's a connectivity issue - check your router, cable, WiFi, etc.

You can also try:

curl -I http://1.1.1.1

If you get an HTTP response back, you have connectivity. DNS is the culprit.

Step 2: Check what DNS server you're using

On Linux/macOS:

cat /etc/resolv.conf

On Windows:

ipconfig /all | findstr "DNS"

This tells you which DNS server your machine is talking to. If it's your router's IP (like 192.168.1.1), your router is forwarding queries to whatever your ISP assigned. If it's something like 8.8.8.8, you've set it manually at some point.

Step 3: Test the DNS server directly

Use dig to query the DNS server and see what happens:

dig @8.8.8.8 google.com

If this returns an answer with an IP address, that DNS server is working fine. Try it with whatever server showed up in Step 2:

dig @192.168.1.1 google.com

This comes up a lot when I'm working with local businesses, and no response? Timeout? That's your problem. Your DNS server is either down or unreachable.

In fairness, if you don't have dig installed (common on Windows), you can use the online dig tool at publicdns.info - it does the same thing from a browser without installing anything. Supports all record types too, which is handy for checking MX records, TXT records, and the rest.

Step 4: Try a different DNS server

The quickest fix when your DNS server is misbehaving: switch to a different one temporarily.

# Linux - temporary fix
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf

On Windows, go to your network adapter settings and manually set DNS to 1.1.1.1 or 8.8.8.8.

If everything starts working immediately, you've confirmed the problem was with your original DNS server.

Step 5: Flush your DNS cache

Sometimes your machine has cached a bad or stale DNS response. Clearing the cache forces it to do fresh lookups:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux (systemd)
sudo systemd-resolve --flush-caches

# Linux (nscd)
sudo systemctl restart nscd

After flushing, try loading a website again. If it works now, a stale cache was the issue.

Step 6: Check for DNS hijacking

Some ISPs and networks intercept DNS queries and redirect them to their own servers, even if you've configured different DNS. This is called DNS hijacking and it's more common than you'd think.

Test it:

dig @1.1.1.1 whoami.cloudflare.com TXT

The response should say "resolver IP" matches Cloudflare. If it shows a different IP, something between you and Cloudflare is intercepting your queries.

The fix: use DNS over HTTPS (DoH) or DNS over TLS (DoT), which encrypts your queries so they can't be intercepted. Most modern browsers support DoH natively now.

Step 7: Check if it's just one domain

If most sites work but one specific domain doesn't resolve, the problem might be with that domain's DNS, not yours.

dig example.com @8.8.8.8
dig example.com @1.1.1.1
dig example.com @9.9.9.9

If all three return the same error (NXDOMAIN or SERVFAIL), the domain's DNS records are broken on their end. Nothing you can do except wait or contact the site owner.

If some resolvers work and others don't, it could be a propagation issue - the domain recently changed DNS records and not all servers have the update yet. You can check this with a propagation checker that queries servers in different locations simultaneously.

Common DNS problems and what causes them

Symptom	Likely cause
Everything stops resolving at once	DNS server down, or your router lost its DNS config
One device can't resolve, others can	That device's DNS cache is stale, or it has wrong DNS settings
Slow DNS lookups (pages load eventually)	DNS server is overloaded or far away geographically
Some domains resolve, others don't	DNS filtering/blocking, or propagation delays
DNS works on WiFi but not on VPN	VPN is using a different DNS server that's misconfigured
"Server not found" only in one browser	Browser-level DoH settings overriding system DNS

When to worry (and when not to)

If flushing the cache or switching DNS fixes it, you're grand. It was a temporary glitch.

If DNS keeps breaking repeatedly, that's a sign of a deeper issue - maybe your router's firmware needs updating, your ISP's DNS is consistently unreliable, or there's something on the network intercepting queries. At that point, setting up a local DNS resolver like Pi-hole gives you full control and logging so you can see exactly what's happening.

Quick reference

ping 8.8.8.8 - test connectivity (not DNS)
dig @8.8.8.8 google.com - test a specific DNS server
ipconfig /flushdns or equivalent - clear DNS cache
Switch DNS to 1.1.1.1 or 8.8.8.8 - bypass a broken server
Check publicdns.info/tools/dig if you can't use the terminal

That covers about 90% of DNS issues I see in the field. The other 10% is usually something weird and specific to the network, but these steps will at least narrow down where the problem is.

How to Pick the Right Public DNS Server (And Why It Matters)

Ciarán Doyle — Tue, 31 Mar 2026 18:29:11 +0000

Most people never think about DNS until something breaks. You type in a URL, it loads. Magic. But the DNS resolver your machine talks to has a real impact on how fast pages load, whether dodgy domains get blocked, and how much of your browsing history leaks to third parties.

I've been running a small IT consultancy in the West of Ireland for about 15 years now, mostly working with schools, medical practices, and local businesses. DNS issues come up constantly. And nine times out of ten, the fix starts with "what DNS server are you actually using?"

Why your ISP's default DNS might not be great

In fairness, i've tested this across dozens of different setups, and when you plug in a router, it usually picks up DNS settings from your ISP automatically. That works. But ISP DNS servers tend to be:

Slower than alternatives - they're shared across thousands of customers and not always well-maintained
Less reliable - outages happen, and when your ISP's DNS goes down, everything looks "broken" even though your connection is fine
Missing security features - most ISP resolvers don't support DNSSEC validation or encrypted DNS
Sometimes dishonest - some ISPs hijack failed DNS queries to show their own search pages full of ads

Right, none of this means ISP DNS is terrible. For a lot of people it works fine. But if you want better speed, privacy, or reliability, switching takes about 2 minutes.

What actually matters when choosing

There are loads of public DNS servers out there. Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), OpenDNS, AdGuard - the list goes on. So how do you pick?

1. Speed (latency to you specifically)

In fairness, the fastest DNS server for someone in Tokyo won't be the fastest for someone in Galway. What matters is the round-trip time from your location to the resolver. A server with 5ms latency will feel noticeably snappier than one at 50ms, especially on pages that make dozens of DNS lookups.

You can test this yourself with dig:

dig @8.8.8.8 example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @9.9.9.9 example.com | grep "Query time"

Or if you want to compare a wider range of servers without messing about in the terminal, publicdns.info keeps a live-tested directory of thousands of public DNS servers filterable by country. It tests them every 72 hours so you know which ones are actually responding.

2. Privacy

Every DNS query you make tells the resolver which domains you visit. If privacy matters to you, look for resolvers that:

Support DNS over HTTPS (DoH) or DNS over TLS (DoT) - encrypts your queries so your ISP can't snoop
Have a clear no-logging policy - Cloudflare and Quad9 both publish audited privacy commitments
Don't sell or share query data

Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) are generally the strongest here. Google DNS works well but Google's business model is advertising, which makes some people uncomfortable.

3. Security features

Some resolvers go beyond just answering queries:

Quad9 blocks known malicious domains by default - proper threat intelligence, not just a blocklist
OpenDNS offers configurable filtering categories
AdGuard DNS blocks ads and trackers at the DNS level
CleanBrowsing provides family-safe filtering

If you're setting up DNS for a school or a home with kids, filtering DNS is one of the easiest wins available.

4. Reliability and uptime

The big providers - Cloudflare, Google, Quad9 - run anycast networks spread across dozens of data centres worldwide. They're about as reliable as it gets. Smaller providers can be fine too, but check whether they've had recent outages.

On publicdns.info, servers are marked with status indicators (OK, TIMEOUT, BAD) so you can see at a glance which ones are actually working right now. That's useful if you're comparing lesser-known options.

My go-to recommendations

For what it's worth, here's what I typically set up for clients:

For general use: Cloudflare (1.1.1.1 / 1.0.0.1) - fast, private, reliable. Hard to beat.

For security-conscious setups: Quad9 (9.9.9.9) - blocks malicious domains, no logging, run by a non-profit.

For families/schools: CleanBrowsing (185.228.168.168) or AdGuard Family (94.140.14.15) - content filtering without needing extra software.

For maximum control: Run your own resolver with Pi-hole or AdGuard Home, using any of the above as upstream. Best of both worlds.

How to change your DNS

On most systems it takes under a minute:

Windows: Settings > Network > your adapter > DNS > set to manual, enter the addresses
macOS: System Settings > Network > your connection > DNS
Linux: edit /etc/resolv.conf or use nmcli / systemd-resolved
Router level (recommended): change DNS in your router's WAN settings - covers every device on the network

The way I see it, changing it at the router is what I'd recommend. Do it once and every phone, laptop, and smart TV on your network benefits.

Quick test after switching

After changing DNS, flush your cache and test:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache

# Linux
sudo systemd-resolve --flush-caches

# Then test
dig google.com

If you get a response with a low query time, you're sorted.

Wrapping up

Picking the right DNS isn't complicated, but it does make a real difference. Faster lookups, better privacy, malware blocking - all from changing two numbers in your network settings. If you've never touched your DNS config, it's worth spending 5 minutes on.

And if you want to explore what's out there beyond the big names, have a browse through the server directory at publicdns.info - there are thousands of tested servers across 200+ countries. You might find something faster for your specific location than the usual suspects.