Real‑world examples of DNS resolution failure: troubleshooting examples that actually help

DNS issues rarely announce themselves as “DNS issues.” Users just say, “I can’t get to the site.” Let’s start with concrete examples of dns resolution failure: troubleshooting examples that mirror what you’re likely seeing right now.

Example 1: Some websites fail to load, but others work fine

A classic example of DNS resolution failure shows up when users report:

“Google works, but our payroll site doesn’t.”

Network connectivity is fine. Pings to 8.8.8.8 succeed, but ping payroll.example.com fails with could not resolve host.

In a real 2024 help desk ticket, the pattern looked like this:

• Public sites like google.com and cnn.com resolved.
• Internal SaaS apps under *.corp-apps.com did not.
• Users were all on the corporate Wi‑Fi, not VPN.

Troubleshooting path in plain English:

The admin ran nslookup payroll.corp-apps.com and saw the query going to the office DNS server, which then forwarded to an upstream resolver. On that upstream resolver, the zone corp-apps.com had expired after a registrar billing issue. Public DNS records were gone; cached entries had just aged out.

The fix was not a firewall rule or a router reboot. It was logging into the domain registrar, renewing the domain, and then watching propagation over the next hour using dig payroll.corp-apps.com @8.8.8.8 and similar checks.

This is one of the best examples of dns resolution failure: troubleshooting examples where the root cause lives outside your network, but the symptoms land on your desk.

Example 2: VPN connected, but no access to internal hostnames

Remote workers in 2025 live on VPNs and zero trust tunnels. A very common example of DNS resolution failure looks like this:

“VPN says connected, but I can’t get to jira.internal.local. The IP works though.”

The user can ping 10.10.20.15 (the Jira server IP) but ping jira.internal.local fails. Web access via IP works; via hostname it doesn’t.

What’s really happening:

The VPN client is supposed to push DNS settings for internal domains (split DNS). In this case:

• ipconfig /all on Windows showed DNS servers pointing to the user’s home router (e.g., 192.168.0.1).
• No internal DNS suffixes like internal.local were present.

The VPN profile had been updated on the server side, but the client software on older laptops didn’t support the new “DNS split include” configuration. So the OS kept using the home network DNS, which had no idea what jira.internal.local meant.

How it was fixed:

The admin:

• Confirmed behavior with nslookup jira.internal.local (showed query to home router).
• Pushed an updated VPN client with proper DNS handling.
• As a temporary workaround, added an entry for jira.internal.local to the user’s hosts file and flushed DNS (ipconfig /flushdns).

This is a textbook example of dns resolution failure: troubleshooting examples where split‑tunnel VPN and DNS suffixes are misconfigured.

Example 3: Home Wi‑Fi “Internet down” caused by ISP DNS outage

Here’s a home user story that plays out every week somewhere:

“Nothing loads, but the modem lights look fine.”

The user can’t reach any website by name, but when they run ping 1.1.1.1 from a laptop, it works. ping cloudflare.com fails.

Diagnosis:

• nslookup cloudflare.com times out when using the ISP’s default DNS.
• Switching the device DNS to 1.1.1.1 and 8.8.8.8 immediately fixes web browsing.

The ISP’s recursive resolvers were having an outage. The connection to the Internet was up; only DNS resolution was broken.

This is one of those simple but powerful examples of dns resolution failure: troubleshooting examples that teach users the difference between “Internet down” and “DNS down.”

For background on how DNS fits into Internet infrastructure, the Internet Society offers a solid overview of DNS and its role in global connectivity.

Example 4: Misconfigured internal DNS zone shadowing a public domain

A more subtle example of DNS resolution failure shows up in hybrid cloud environments.

Symptom:

“From the office, api.vendor.com fails. From home, it works.”

This often happens when an internal DNS zone accidentally overrides a public domain. For instance, an internal DNS zone named vendor.com was created years ago for a test environment. Now the company is working with a real external vendor at api.vendor.com.

Inside the corporate network:

• The internal DNS server thinks it is authoritative for vendor.com.
• It has no record for api.vendor.com.
• Queries for api.vendor.com never leave the organization.

Outside the network, queries go to public DNS and resolve correctly.

How this was confirmed:

• nslookup -type=soa vendor.com inside the office returned the internal DNS server as the Start of Authority.
• The same query from a mobile hotspot showed a completely different SOA from the vendor’s provider.

The fix involved renaming or removing the internal vendor.com zone and replacing it with more specific zones (e.g., test.vendor.internal) so public vendor.com traffic could reach the real Internet.

This is a good example of dns resolution failure: troubleshooting examples where “split‑horizon” or overlapping zones create inconsistent behavior based on location.

Example 5: DNS over HTTPS (DoH) fighting with enterprise policy

By 2024–2025, many browsers default to DNS over HTTPS. That’s great for privacy, but it introduces new examples of DNS resolution failure.

Scenario:

“On the corporate network, some users can’t reach intranet.company.local in Chrome, but Edge works.”

The company uses an internal DNS zone company.local only resolvable by internal DNS servers. The security team also uses DNS logs to detect malware.

Chrome quietly enabled DoH and started sending DNS queries to a public resolver. That resolver has no idea what intranet.company.local is, so DNS resolution fails. Edge, configured to use the system DNS only, works fine.

How admins tracked it down:

• nslookup intranet.company.local on the same machine worked, proving system DNS was fine.
• Chrome’s internal chrome://dns page showed DoH enabled and using a public provider.
• DNS logs on the internal servers never saw queries for intranet.company.local from affected users.

The fix required pushing a group policy to disable DoH for corporate devices or to enforce an enterprise DoH endpoint that understood internal zones. Mozilla and Google both document enterprise controls for encrypted DNS; for example, see Mozilla’s enterprise DNS over HTTPS guidance at https://support.mozilla.org.

This is one of the newer examples of dns resolution failure: troubleshooting examples driven by privacy features colliding with enterprise design.

Example 6: Intermittent failures from EDNS, DNSSEC, or oversized responses

Some of the most frustrating DNS tickets are intermittent: the same hostname resolves sometimes, then mysteriously times out.

In 2024, a global SaaS provider rolled out DNSSEC and larger TXT records for email security (SPF, DKIM, DMARC). Suddenly, a subset of customers reported:

“Our app can’t reach api.saasprovider.com reliably. Sometimes it works, sometimes it just hangs.”

Investigation showed:

• Affected customers used older firewalls or middleboxes that mishandled EDNS0 or fragmented UDP DNS packets.
• dig +dnssec api.saasprovider.com returned large responses, sometimes requiring TCP fallback.
• Some resolvers in the path were dropping or mishandling those larger responses.

Workarounds and fixes:

• Temporarily disabling EDNS0 on certain resolvers (edns-udp-size tuning) or forcing TCP for DNS on problematic paths.
• Updating or replacing legacy firewalls that didn’t handle modern DNS features.

This is a more advanced example of dns resolution failure: troubleshooting examples where protocol evolution (DNSSEC, EDNS0) exposes brittle network gear.

For a deeper protocol‑level view, the Internet Engineering Task Force (IETF) publishes DNS standards and operational notes at https://www.rfc-editor.org.

Example 7: Container and Kubernetes DNS failures inside clusters

Cloud‑native environments add their own flavor of DNS pain.

A development team on Kubernetes reported:

“Pods can’t resolve db-service sometimes, but db-service.namespace.svc.cluster.local works more often.”

They were using CoreDNS for cluster DNS. Under load, DNS queries started timing out.

Findings:

• CoreDNS pods were CPU‑starved and occasionally evicted.
• Application pods cached failed lookups, amplifying the issue.
• A misconfigured stubDomains setting sent some queries to an external DNS server that had no clue about cluster services.

Fixes included:

• Giving CoreDNS dedicated resources and horizontal pod autoscaling.
• Cleaning up stubDomains to avoid misrouting internal service queries.
• Shortening negative caching TTLs so failed lookups were retried sooner.

This is a modern example of dns resolution failure: troubleshooting examples where service discovery and DNS are effectively the same thing.

Patterns across these dns resolution failure troubleshooting examples

Looking across these examples of dns resolution failure: troubleshooting examples, some patterns repeat regardless of environment:

• Users describe symptoms in generic terms: “Internet down,” “site not loading,” “VPN broken.”
• IP‑based tests (pinging a known IP) often succeed, while hostname‑based tests fail.
• Location matters: a hostname may work from home but not from the office, or vice versa.
• Modern features (VPN split DNS, DoH, DNSSEC, Kubernetes) introduce more moving parts.

When you see these patterns, think DNS early. It may not always be the final answer, but ruling it in or out quickly saves a lot of time.

Practical workflow: using these examples of dns resolution failure in your own troubleshooting

Instead of memorizing commands, use a simple mental checklist inspired by the real examples above.

Start with: “Is it DNS or general connectivity?”

• Try reaching a known IP address like 1.1.1.1 or 8.8.8.8.
• If IP works but hostnames do not, suspect DNS.

Then:

• Use nslookup or dig on the failing hostname.
• Note which DNS server is being queried and whether you get a response or a timeout.

These quick checks mirror the best examples of dns resolution failure: troubleshooting examples from the field, where simply identifying the resolver in use points you toward VPN issues, ISP outages, or misconfigurations.

Compare locations and networks

If a hostname fails in one place but works in another, use that difference:

• Test from a phone on mobile data vs. Wi‑Fi.
• Test from inside the VPN vs. outside.

This is how admins found the internal vendor.com zone shadowing the public one, and how they diagnosed ISP DNS outages. Different answers (or no answer) from different networks are valuable signals.

Pay attention to modern twists

In 2024–2025, when you see odd DNS behavior, remember:

• Browsers may use their own DNS (DoH) instead of system DNS.
• VPN clients may or may not correctly override local DNS.
• Cloud and container platforms may have internal DNS layers (CoreDNS, service discovery) that fail independently of external DNS.

These aren’t edge cases anymore; they are part of normal operations.

For general networking education, universities often publish accessible material. For example, MIT’s OpenCourseWare networking resources at https://ocw.mit.edu include material on Internet naming and addressing that helps frame how DNS fits into larger systems.

FAQ: common questions and examples of DNS resolution failure

What are some everyday examples of DNS resolution failure at home?

Common home examples include your ISP’s DNS servers going down, a misconfigured router handing out a bad DNS IP over DHCP, or security software blocking DNS queries. A classic example of this is: you can ping 8.8.8.8, but ping google.com fails with a “temporary failure in name resolution” or similar error.

Can you give an example of DNS resolution failure caused by VPN settings?

Yes. A frequent example of dns resolution failure: troubleshooting examples in remote work is when the VPN connects, but the client does not receive the internal DNS server or search suffix. The result: internal hostnames like fileserver.internal.local do not resolve, even though you can reach them by IP.

How do I know if DNS over HTTPS is causing my problem?

If hostnames fail in one browser but work in another on the same machine, suspect DoH. An example of this is Chrome failing to resolve an internal hostname that works in Edge. Checking the browser’s DNS settings and your enterprise policies will usually confirm it.

Are intermittent DNS failures always a DNS server problem?

Not always. Some of the best examples of dns resolution failure: troubleshooting examples show that middleboxes, firewalls, and even buggy home routers can drop large or fragmented DNS packets. The DNS server might be fine, but responses never make it back to the client.

What’s a quick way to narrow down DNS issues without being an expert?

Use a simple pattern based on the real examples included in this article:

• Test by IP vs. hostname.
• Try a public resolver like 1.1.1.1 or 8.8.8.8 temporarily.
• Compare behavior on different networks (home vs. mobile vs. office).

If those tests change the outcome, you’re very likely dealing with DNS rather than a total Internet outage.

DNS issues are rarely glamorous, but they are everywhere. Learning from real examples of dns resolution failure: troubleshooting examples like the ones above will make you faster, calmer, and far more effective the next time someone says, “The Internet is broken.”