You edited /etc/resolv.conf and your changes vanished
You connect to a network and your DNS is wrong. You open /etc/resolv.conf, add your preferred servers, and save. You reboot. The file is back to its previous state. You feel like you are fighting the system. You are.
Fedora uses NetworkManager to manage network connections. NetworkManager treats /etc/resolv.conf as an output file, not an input file. It generates the contents based on connection profiles and DHCP offers. If you edit the file directly, NetworkManager sees the change is not from its database and overwrites it the next time the interface activates. Manual edits drift. Configuration tools persist.
What's actually happening
NetworkManager maintains a state machine for each network interface. The DNS settings are properties of the connection profile, which lives in the NetworkManager database. When a connection activates, NetworkManager reads the profile, checks for DHCP offers, applies ignore rules, and writes the resulting configuration to /etc/resolv.conf.
The hierarchy is strict. The connection profile defines the intent. DHCP provides dynamic data. NetworkManager reconciles the two and produces the runtime state. /etc/resolv.conf is usually a symlink pointing to a file managed by NetworkManager or systemd-resolved. Editing the target file breaks the management loop.
Use nmcli to modify the profile. nmcli updates the database and triggers the reconciliation process. This ensures your changes survive reboots, interface flaps, and connection switches.
Configure DNS per connection with nmcli
Start by identifying the connection name. The connection name is not the interface name. The interface is eth0 or wlan0. The connection is a profile like Wired connection 1 or MyOfficeWiFi.
nmcli con show
# Lists all saved connection profiles.
# Look for the NAME column.
# The DEVICE column shows which interface is currently using the profile.
Modify the profile to set your DNS servers. Replace MyConnection with the name from the list.
nmcli con mod MyConnection ipv4.dns "1.1.1.1 8.8.8.8"
# Sets the list of DNS servers for IPv4.
# Space-separated list.
# This writes to the persistent profile, not the running state.
nmcli con mod MyConnection ipv4.ignore-auto-dns yes
# Tells NetworkManager to reject DNS servers sent by DHCP.
# Without this flag, DHCP servers can override your static settings.
# This is essential if you want to force specific DNS servers.
nmcli con up MyConnection
# Reactivates the connection to apply profile changes to the kernel.
# If the connection is already active, this deactivates and reactivates it.
# You may lose connectivity for a few seconds during the cycle.
NetworkManager stores the configuration in /etc/NetworkManager/system-connections/. Never edit those files directly. Use nmcli. The files contain binary blobs or complex XML structures that can corrupt if edited manually. nmcli validates the input and updates the internal database correctly.
Handle IPv6 and search domains
Modern Fedora systems enable IPv6 by default. If you set IPv4 DNS but leave IPv6 on automatic, the system may use DHCP-provided IPv6 DNS servers. This creates a split-brain scenario where some queries go to your chosen servers and others go to the ISP.
Set IPv6 DNS explicitly if you want full control.
nmcli con mod MyConnection ipv6.dns "2606:4700:4700::1111 2606:4700:4700::1001"
# Sets DNS servers for IPv6.
# Use the IPv6 addresses of your preferred resolver.
nmcli con mod MyConnection ipv6.ignore-auto-dns yes
# Rejects IPv6 DNS servers from DHCPv6 or SLAAC.
# Prevents split-brain DNS where IPv4 and IPv6 use different resolvers.
Search domains allow you to use short hostnames. If you add a search domain, you can ping server instead of server.example.com.
nmcli con mod MyConnection ipv4.dns-search "example.com internal.lan"
# Adds search domains for hostname resolution.
# Space-separated list.
# Useful in corporate environments with internal DNS zones.
Apply the changes again to update the runtime state.
nmcli con up MyConnection
# Reloads the connection with the new IPv6 and search domain settings.
Check both IPv4 and IPv6. Split-brain DNS causes intermittent failures that are impossible to trace.
Verify the configuration
Confirm that NetworkManager applied the settings. Check the device details and the resolver file.
nmcli dev show MyConnection | grep DNS
# Shows the active DNS servers for the device.
# Look for IP4.DNS and IP6.DNS lines.
# Verify the addresses match your configuration.
cat /etc/resolv.conf
# Displays the current resolver configuration.
# On Fedora, this is often a symlink to /run/NetworkManager/resolv.conf.
# The nameserver lines should match your nmcli settings.
Test resolution against your new servers.
dig @1.1.1.1 fedoraproject.org +short
# Queries the DNS server directly.
# Returns the IP address if resolution works.
# Use this to verify the server is reachable and responding.
dig @8.8.8.8 fedoraproject.org +short
# Tests the secondary server.
# Ensures failover works if the primary is down.
Run journalctl -xeu NetworkManager if you suspect issues. Read the actual error before guessing.
Common pitfalls and errors
You will encounter errors if the connection state is inconsistent or the device type mismatches.
Error: Connection activation failed: No suitable device found for this connection.
This error means you are trying to activate a profile on a device that does not match the profile type. A WiFi profile cannot activate on an Ethernet interface. Check the device status and ensure the interface is available.
nmcli dev status
# Shows all devices and their state.
# Look for the DEVICE and STATE columns.
# Ensure the device is connected to the correct profile.
Error: Connection 'MyConnection' is not active.
The connection profile exists but is not currently active on any device. Run nmcli con up MyConnection to activate it. If the device is disconnected, the command will fail until the cable is plugged in or the WiFi is available.
Another pitfall is setting ipv4.ignore-auto-dns yes on a laptop that roams to captive portals. Some coffee shops and hotels require the DHCP-provided DNS to redirect you to a login page. If you ignore DHCP DNS, the redirect fails and you cannot authenticate. Use nmcli to toggle ignore-auto-dns when you move between environments.
nmcli con mod MyConnection ipv4.ignore-auto-dns no
# Restores DHCP DNS acceptance.
# Necessary for captive portals that rely on DNS redirection.
nmcli con up MyConnection
# Applies the change to allow DHCP DNS again.
Restoring defaults requires clearing the values. Setting an empty string removes the custom servers.
nmcli con mod MyConnection ipv4.dns ""
# Clears the custom DNS list.
# NetworkManager reverts to DHCP or global defaults.
nmcli con mod MyConnection ipv4.ignore-auto-dns no
# Re-enables DHCP DNS processing.
# Essential when removing static DNS configuration.
Backup the connection profile before mass edits. nmcli con export MyConnection saves the profile to stdout. Redirect to a file if you need a restore point.
Use systemd-resolved for runtime control
Fedora ships with systemd-resolved as the default DNS backend. It runs a local stub resolver at 127.0.0.53 and caches queries. NetworkManager pushes DNS settings to systemd-resolved, which then updates /etc/resolv.conf.
You can use resolvectl to manage DNS at the link level. This is useful for temporary overrides or debugging.
resolvectl status
# Shows the DNS configuration for all links.
# Look for the DNS Servers section under each link.
# Verify the servers match your expectations.
resolvectl dns eth0 1.1.1.1 8.8.8.8
# Sets DNS servers for the eth0 link directly.
# This is a runtime change only.
# It does not modify the NetworkManager profile.
# The change persists until the link resets or the system reboots.
Flush the cache if you change DNS servers and want to clear stale results.
sudo resolvectl flush-caches
# Clears the local DNS cache.
# Forces fresh queries to the new servers.
# Useful after changing DNS configuration to avoid cached failures.
resolvectl statistics
# Shows cache hit rates and query counts.
# Helps verify that the cache is being used and refreshed.
resolvectl changes are ephemeral. They do not survive reboots. Use nmcli for persistent configuration. Use resolvectl for quick tests or temporary overrides.
Set a global fallback
If you need a DNS fallback that applies to all connections, use NetworkManager's global configuration. This is useful for servers with fixed DNS requirements or environments where DHCP DNS is untrusted.
Create a configuration file in /etc/NetworkManager/conf.d/.
sudo tee /etc/NetworkManager/conf.d/dns.conf <<EOF
[global-dns-domain-*]
servers=1.1.1.1,8.8.8.8
EOF
# Creates a global DNS configuration file.
# The [global-dns-domain-*] section matches all connections.
# servers= sets the fallback DNS servers.
# Comma-separated list.
# This applies to connections that do not have specific DNS settings.
Reload NetworkManager to apply the global configuration.
sudo systemctl reload NetworkManager
# Reloads the daemon configuration.
# Applies new conf.d files without disrupting active connections.
# NetworkManager merges global settings with profile settings.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Package updates overwrite /usr/lib/ and destroy manual changes.
Decision matrix
Use nmcli con mod when you want persistent DNS settings tied to a specific network profile.
Use resolvectl dns when you need a temporary override for the current session.
Use global conf.d configuration when every connection on the system must use the same DNS servers regardless of DHCP offers.
Use systemd-resolved as the backend when you want local caching and DNSSEC validation across all connections.
Stay on the upstream Workstation defaults if you only deviate from the DNS settings occasionally.