🧭 Debugging a Real DNS Outage — When My Website Worked on Mobile but Not Wi-Fi

By Ankit Tiwari — October 2025

🚨 The Incident

Today (22nd October 2025) afternoon, I noticed that my website iskconsarjapurroad.com was not working on my laptop's WiFi connection. 😰 Panicking, I quickly checked the VM - all metrics were good ✅. Then I checked on my mobile, and to my surprise it was working perfectly fine on mobile data! 📱

Yes, it was a sigh of relief 😮‍💨 - it wasn't an outage for all my users. That's when I got a hunch that the issue was with my WiFi network 🤔.

🧩 Step 1 — Verifying the Problem

I started by checking if my system could resolve the domain using nslookup 🔍.

Figure 1 — DNS lookup failed with SERVFAIL on Wi-Fi.

This meant my system reached the DNS server (192.168.0.1) but it couldn't fetch the IP address for my domain — a clear sign of DNS resolver trouble ⚠️.

⚙️ Step 2 — Checking My DNS Configuration

Figure 2 — DNS configuration showing router as resolver.

This showed that my Mac was using my router (192.168.0.1) as its DNS resolver 🏠. The router in turn forwarded all DNS traffic to my Internet Service Provider's DNS servers 🌐.

🌐 Step 3 — Verifying the Request Route (Traceroute)

To confirm where my network traffic was actually going, I ran the following commands 🕵️:

Figure 3 — Traceroute showing ISP path to Google DNS.

This told me my ISP is Intech Online Pvt Ltd 🏢. Then, I traced the route to 8.8.8.8 (Google's DNS) to see the actual network hops 🛣️:

Here's what each hop means 📍:

• Hop 1 — 192.168.0.1: My home router 🏠. It's the gateway between my Mac and the internet.
• Hop 2 — 10.70.0.1: The first internal IP of my ISP's network 🔗.
• Hop 3 — 124.108.17.181 (intechonline.net): A router inside Intech Online's backbone — confirming the traffic is indeed routed through them ✅.
• Hop 4 — *: No response ❌, which is normal if a router doesn't return ICMP packets.

This verified that all requests from my Mac were indeed passing through Intech's network infrastructure 🌐. So, if there's a delay or SERVFAIL, it's likely happening at their DNS resolver 🎯.

🧱 Step 4 — Router's DNS Setup

Figure 4 — Router's DNS setup showing ISP DNS and Google DNS.

Here, 103.14.232.100 belongs to my ISP (Intech Online Pvt Ltd) 🏢, and 8.8.8.8 is Google's public DNS 🌍. The router always queries the primary DNS first — so everything depended on the ISP's resolver ⚡.

🧪 Step 5 — Comparing DNS Speeds

Figure 5 — DNS query speed with my ISP DNS resolver.

2.49 seconds — that's unusually high 🐌! When I tested Google DNS, it responded in just 140 ms ⚡:

Figure 6 — DNS query speed with Google DNS resolver.

This clearly pointed to an issue with the ISP's DNS resolver being slow or unreliable 🚨.

🔍 Step 6 — Confirming the Issue

nslookup iskconsarjapurroad.com 103.14.232.100   → SERVFAIL
nslookup iskconsarjapurroad.com 8.8.8.8          → Works instantly

🔍 Understanding the nslookup Command

Command Breakdown:

• nslookup — DNS lookup utility that queries DNS servers
• iskconsarjapurroad.com — The domain name we want to resolve to an IP address
• 103.14.232.100 — The specific DNS server to query (ISP's DNS resolver)
• 8.8.8.8 — Google's public DNS server for comparison

What SERVFAIL means:

• 🚫 Server Failure: The DNS server received the query but couldn't complete the resolution
• ⚠️ Not a timeout: The server responded, but with a failure status
• 🔧 Possible causes: Server overload, configuration issues, or upstream DNS problems
• 📊 Different from NXDOMAIN: SERVFAIL means server issues, not that the domain doesn't exist

Key Insights:

• ✅ Same domain, different results: The domain exists (Google DNS proves it)
• 🎯 Server-specific issue: Problem is isolated to the ISP's DNS server
• ⚡ Performance difference: Google DNS responds instantly vs ISP's SERVFAIL
• 🔄 Intermittent failure: ISP DNS works sometimes but fails unpredictably

The first query failed using my ISP's DNS, but the second one (via Google) worked immediately. That confirmed the culprit — the ISP's DNS server was failing intermittently.

🧰 Step 7 — Before vs After (Visual)

Here’s how the DNS query was flowing before and after the fix.

🚫 Before — ISP DNS Failing

Before — DNS query stopped at ISP DNS (103.14.232.100).

✅ After — Switched to Google DNS

After — DNS query now flows smoothly via Google (8.8.8.8) to the website.

⚙️ Step 8 — Fixing It on macOS

Option 1 — Using System Settings (GUI) 🖱️

1. Open System Settings → Network 🔧
2. Select your active connection (Wi-Fi) 📶
3. Click Details → DNS 🌐
4. Remove 192.168.0.1 and add:

   8.8.8.8    ← Google DNS 🌍
   1.1.1.1    ← Cloudflare DNS ⚡

5. Click OK → Apply ✅

Option 2 — Using Terminal 💻

sudo networksetup -setdnsservers Wi-Fi 8.8.8.8 1.1.1.1

To verify it worked 🔍:

networksetup -getdnsservers Wi-Fi
8.8.8.8    ✅
1.1.1.1    ✅

✅ Step 9 — Verifying the Fix

nslookup iskconsarjapurroad.com
Server:  8.8.8.8       ← Now using Google DNS! 🌍
Address: 8.8.8.8#53
Name:    iskconsarjapurroad.com
Address: 34.47.185.39  ← Success! ✅

Everything resolved instantly — no more timeouts or failures! 🎉 Switching to Google's DNS permanently solved the issue 🚀.

🧠 Why Using Google DNS Works Better

• Lower latency: Global caching and faster routing 🌐.
• High reliability: Redundant servers worldwide 🔄.
• Bypasses ISP issues: Independent of local resolver failures 🛡️.

🧾 Final Summary

What started as a simple "Wi-Fi not working but mobile does" problem turned into a deep DNS investigation 🕵️. By switching to Google's DNS, my website now loads instantly everywhere — and I learned a ton about how resolvers, ISPs, and routes actually work! 🎓✨