When names stop resolving
You run dnf upgrade and the transaction hangs on "Resolving dependencies". You open a browser and every tab shows a connection error. The terminal spits out Temporary failure in name resolution or Name or service not known. You can ping 8.8.8.8, but ping google.com fails. Your network link is up, but the names are gone. This is a DNS breakage.
How Fedora handles DNS
Fedora does not let applications talk directly to DNS servers on the internet. Instead, it uses a local service called systemd-resolved. This service acts as a stub resolver listening on 127.0.0.53. Every application sends queries to this loopback address. systemd-resolved forwards the query to the upstream servers provided by your network, caches the result, and returns the answer.
This architecture provides a single cache for the whole system, supports DNSSEC validation, and allows per-connection DNS settings. If systemd-resolved is down, misconfigured, or blocked by a firewall, nothing resolves. The stub resolver is the gatekeeper. Fix the gatekeeper and the names come back.
Diagnose the resolver state
Check what systemd-resolved thinks it knows. The resolvectl command shows the active links, the DNS servers assigned to each link, and the validation state.
Here's how to see which DNS servers Fedora is actually using right now.
# Show the full status of the resolver and all network links
resolvectl status
# Look for the section matching your active interface
# Check the "DNS Servers" line for valid addresses
# Verify "DNSSEC" is set to "supported" or "no"
If the output shows DNS Servers: (none) under your active interface, the resolver has no upstream targets. If the interface is missing entirely, systemd-resolved has lost contact with NetworkManager. If you see DNSSEC: failed, validation is rejecting responses, which blocks resolution by design.
Restart the daemon
The systemd-resolved daemon can get stuck in a bad state. It might hold a stale connection to a dead upstream server or fail to pick up a new DHCP lease. A restart forces the daemon to re-read configuration, flush internal state, and re-establish connections.
Restart the service and check its status immediately.
# Restart the local resolver daemon
sudo systemctl restart systemd-resolved
# Verify the service is active and check recent logs
systemctl status systemd-resolved
The status output includes the last few log lines. Look for errors about failed connections or configuration reloads. If the service fails to start, the logs will show the reason. A healthy service reports active (running) and shows no red error lines.
Restart the service before you blame the hardware. The daemon is usually the culprit.
Fix the resolv.conf symlink
Applications read /etc/resolv.conf to find the DNS server. On Fedora, this file must be a symbolic link pointing to the stub resolver. If it is a regular file, applications bypass systemd-resolved and query the wrong servers. This often happens after a manual edit or a migration from another distribution.
Check the symlink and restore it if it is broken.
# List the file to check if it is a symlink
ls -la /etc/resolv.conf
# The output must show a link to /run/systemd/resolve/stub-resolv.conf
# If it is a regular file, recreate the symlink
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
If the file is a regular file, systemd-resolved cannot inject the correct stub address. The symlink points to /run/systemd/resolve/stub-resolv.conf, which is a dynamic file managed by the service. Never edit /etc/resolv.conf by hand. The symlink must point to the stub resolver.
Configure DNS via NetworkManager
DNS settings belong to the network connection profile, not the global system. NetworkManager assigns DNS servers based on DHCP or static configuration. If your router provides bad DNS addresses, or if you are on a network with no DHCP DNS, you need to set the servers manually in the connection profile.
Here's how to set static DNS servers for a specific connection.
# List all connection profiles to find the active one
nmcli con show
# Replace "Wired connection 1" with your profile name
# Set the DNS servers for IPv4
nmcli con mod "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"
# Ignore DNS provided by DHCP to prevent overwrites
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
# Reapply the connection to activate the changes
nmcli con up "Wired connection 1"
The nmcli con mod command modifies the stored profile. The changes do not take effect until you reactivate the connection with nmcli con up. If you set DNS for IPv4, check IPv6 as well. A mismatch can cause resolution to work for some sites but fail for others. Set ipv6.dns and ipv6.ignore-auto-dns using the same pattern if your network uses IPv6.
Flush the cache
systemd-resolved caches DNS responses to speed up lookups. If a domain changes its IP address, or if you switch networks, the cache might hold stale entries. Flushing the cache forces the resolver to fetch fresh data from the upstream servers.
Clear the cache when you suspect stale data is causing failures.
# Flush the local DNS cache
sudo resolvectl flush-caches
# Verify the cache is empty
resolvectl statistics
The statistics output shows the number of cached entries. After flushing, the count should drop to zero. New queries will repopulate the cache. This step is essential after changing DNS servers or modifying connection profiles.
Check firewall and SELinux
If DNS works for some queries but fails for others, or if the service starts but cannot reach upstream servers, a firewall rule or SELinux policy might be blocking traffic. DNS uses UDP port 53 and TCP port 53 for larger responses.
Check the firewall rules and SELinux denials.
# List active firewall zones and services
sudo firewall-cmd --list-all
# Check for SELinux denials related to resolved
sudo journalctl -t setroubleshoot | tail -n 20
If the firewall blocks DNS, add the service. SELinux denials appear in the setroubleshoot journal entries. Read the one-line summary to understand what was blocked. Most DNS issues are network configuration problems, not SELinux blocks. If you see an AVC denial, the journal usually suggests a fix. Do not disable SELinux to work around a denial. Fix the policy or the configuration.
Reload the firewall after every rule change. The runtime configuration and the persistent configuration diverge otherwise.
Verify resolution
Once you have applied fixes, verify that resolution works end-to-end. Use resolvectl query to test the local resolver directly. This command bypasses the application layer and confirms the daemon can resolve names.
Test resolution with a known domain.
# Query the local resolver for a domain
resolvectl query fedoraproject.org
# The output should show the IP address and the source
# If it fails, the error message indicates the specific problem
If the query returns an IP address, DNS is working. If it returns Server returned error NXDOMAIN, the domain does not exist. If it returns Server returned error SERVFAIL, the upstream server is failing. If it hangs, the upstream server is unreachable. Use dig to query a specific upstream server directly if you need to isolate the failure.
# Query a specific DNS server directly, bypassing the cache
dig @8.8.8.8 fedoraproject.org
# Check the "status" field in the response
# NOERROR means success, SERVFAIL means upstream failure
Run journalctl -xe if the query fails. The explanatory text and end-jump flags show the context of the failure. Read the actual error before guessing.
Common pitfalls
DHCP often assigns the router's IP address as the DNS server. The router then forwards queries to the internet. If the router is slow or misconfigured, DNS feels slow or fails. Setting public DNS servers like 8.8.8.8 directly can improve performance, but it bypasses the router's local DNS features. Some home networks rely on the router for local hostname resolution. Switching to public DNS might break access to local devices by name.
IPv6 DNS is a frequent source of confusion. If your connection has IPv6 enabled but no IPv6 DNS servers, resolution might fail for IPv6-only domains. Ensure ipv6.dns is set in the connection profile if the network supports IPv6.
DNSSEC validation can block resolution if the upstream server does not support DNSSEC or returns invalid signatures. systemd-resolved validates responses by default. If you see DNSSEC: failed in resolvectl status, the resolver is rejecting responses for security reasons. Switch to a DNS provider that supports DNSSEC, or disable validation in the connection profile if you trust the network.
When to use which tool
Use systemd-resolved when you want a unified local cache and DNSSEC validation handled automatically. Use NetworkManager to set DNS per-connection so settings follow your Wi-Fi profiles. Use resolvectl to debug the resolver state without restarting services. Use dig or nslookup only when you need to query a specific upstream server directly, bypassing the local cache. Use firewall-cmd when you suspect port 53 is blocked by the host firewall. Use journalctl -t setroubleshoot when you see AVC denials in the logs.
Trust the package manager. Manual file edits drift, snapshots stay.