Why Local DNS Stops Working on Linux: A Real dnsmasq Troubleshooting Case on Fedora

When the Symptoms Point in the Wrong Direction

One of the most frustrating situations in a homelab environment is seeing every service online while DNS resolution suddenly stops working.

That was exactly the scenario.

Several internal services were accessible through friendly hostnames such as:

jellyfin.home
grafana.home
books.home
n8n.home

Then, without warning, those names stopped resolving on a Fedora workstation.

At first glance, the conclusion seemed obvious:

The local DNS server must be broken.

But troubleshooting is often about resisting the most obvious conclusion.

The real culprit turned out to be somewhere else entirely.

The Environment

The setup was straightforward.

A home server was running dnsmasq as the local DNS resolver.

The goal was simple:

Instead of accessing services through IP addresses, users could access them through memorable names.

For example:

Instead of:

https://192.168.100.10

Users could simply open:

https://jellyfin.home

This approach significantly improves usability in homelab and self-hosted environments.

The architecture looked like this:

Workstation
      ↓
Home Server (dnsmasq)
      ↓
Internet

Everything had been working correctly until the workstation suddenly lost the ability to resolve local domains.

The Initial Symptom

Attempts to access internal services failed immediately.

Browsers reported that the hostname could not be found.

Command-line tools produced DNS resolution errors.

Yet something felt strange.

The services themselves were still alive.

SSH access to the server worked perfectly.

Mobile devices continued to resolve the same domains successfully.

This was a critical clue.

If only one device is experiencing the issue, the server may not be the problem.

The First Rule of Effective Troubleshooting

Before changing anything, answer one question:

Is the suspected component actually failing?

Many administrators immediately restart services, edit configuration files, or reinstall software.

That often creates more confusion.

Instead, the first step should always be verification.

The investigation started with a direct DNS query to the local DNS server.

The result was immediate.

The expected DNS records were returned correctly.

At that moment, an important conclusion became possible:

The DNS server was functioning normally.

Eliminating the Obvious Suspect

Once the direct query succeeded, the investigation changed direction completely.

The question was no longer:

Why isn't dnsmasq responding?

The question became:

Why isn't the workstation using dnsmasq?

This shift in thinking is often what separates systematic troubleshooting from random trial and error.

The evidence suggested that the DNS server was healthy.

Something in the resolution path was preventing queries from reaching it.

Following the DNS Resolution Path

Every DNS request follows a chain of components.

When a user enters:

jellyfin.home

the request travels through several layers:

Application
      ↓
Local resolver
      ↓
Configured DNS server
      ↓
Response

If the DNS server itself works correctly, then one of the layers before it must be redirecting the request.

The next step was identifying exactly which DNS server the workstation was currently using.

The Critical Discovery

The answer came from inspecting the system's active DNS configuration.

Instead of using the home server as expected, Fedora was actively using an IPv6 DNS server.

Something similar to:

fe80::abcd:1234:5678:9999

That address did not belong to dnsmasq.

It belonged to the router.

The workstation's DNS flow actually looked like this:

Workstation
      ↓
Router

instead of:

Workstation
      ↓
Home Server

The workstation was completely bypassing the local DNS infrastructure.

Why IPv6 Was Causing the Problem

Modern routers commonly advertise DNS servers through IPv6 Router Advertisements.

Even when a custom IPv4 DNS server is configured manually.

Depending on NetworkManager settings and systemd-resolved behavior, the automatically advertised IPv6 DNS server may receive higher priority.

When that happens, Fedora starts sending DNS queries to the router.

The router, however, has no knowledge of internal records such as:

jellyfin.home
grafana.home
books.home

As a result, every local lookup fails.

The DNS server isn't broken.

The workstation is simply asking the wrong server.

Confirming the Theory

Before making any changes, it was important to prove the hypothesis.

The IPv6 address was investigated.

The result confirmed that it belonged to the network gateway.

At that point, every symptom finally made sense.

The puzzle pieces aligned perfectly.

Connecting the Dots

Consider the evidence:

dnsmasq answered direct queries

The DNS server was healthy.

Mobile devices worked normally

The network infrastructure was healthy.

SSH connections succeeded

The server was reachable.

Only local domain resolution failed

The issue was DNS-specific.

Fedora was using the router as its DNS server

Local records never reached dnsmasq.

Once viewed together, the root cause became obvious.

Fixing the Problem

Because the root cause was correctly identified, the fix was surprisingly simple.

No DNS records needed modification.

No dnsmasq configuration required changes.

No service restarts were necessary.

The solution was simply to prevent Fedora from prioritizing the automatically advertised IPv6 DNS server and ensure the workstation used the intended local DNS resolver.

Once the network connection was refreshed, local name resolution immediately returned to normal.

Verifying the Solution

Troubleshooting is not complete when a change is made.

It is complete when the result is validated.

Three verification steps were performed.

1. Verify the Active DNS Server

The workstation now pointed to the home server.

2. Test Local Name Resolution

Internal .home domains resolved successfully.

3. Test Internet Resolution

Public internet domains continued to resolve correctly.

Only after all three checks succeeded was the incident considered resolved.

The Final Architecture

After the correction, DNS resolution followed the intended path.

Internal Services

Workstation
      ↓
systemd-resolved
      ↓
dnsmasq
      ↓
.home domains

Internet Domains

Workstation
      ↓
systemd-resolved
      ↓
dnsmasq
      ↓
Public DNS
      ↓
Internet

An Important Reliability Consideration

This troubleshooting session also highlighted an architectural consideration.

When the home server acts as the primary DNS resolver, it becomes a critical infrastructure component.

If the server becomes unavailable:

Local domains stop resolving.
Internet DNS resolution may stop working.
Services remain online but become accessible only by IP address.

This behavior is expected, but it is important to understand before an outage occurs.

The Most Valuable Lesson Learned

The most important takeaway from this incident is not related to dnsmasq.

It is not about Fedora.

It is not even about IPv6.

The real lesson is about methodology.

When DNS resolution fails, many administrators immediately focus on the DNS server.

A better question is:

Which DNS server is actually answering queries right now?

That single question led directly to the root cause.

The DNS server was never broken.

The workstation was simply talking to the wrong server.

And that is exactly why systematic troubleshooting consistently outperforms trial and error.

Key Takeaways

Always verify the suspected component before changing anything.
A working DNS server can still appear broken if clients are querying a different resolver.
IPv6 DNS advertisements can silently override expected DNS behavior.
Fedora's systemd-resolved and NetworkManager can prioritize IPv6 DNS servers automatically.
Understanding the DNS resolution path is often more valuable than memorizing commands.