Loading...

VONDS ©

Lab 134: Fix DNS Failure Caused by Bad resolv.conf

Back to Lab Index

Confirm the host can reach the internet by IP, then isolate the outage to DNS. Fix resolver configuration persistently via NetworkManager and verify name resolution is restored.

networking troubleshooting dns networkmanager core

Scenario

Users report: “The server can ping 1.1.1.1, but anything using hostnames fails.” You suspect a resolver misconfiguration on this host and need to restore reliable DNS quickly and persistently.

Operator context

Do not fix DNS by hand-editing /etc/resolv.conf on a NetworkManager system. Treat it as generated output and correct upstream configuration so the fix survives reboots and DHCP renewals.

Objective

  • Confirm a default route exists.
  • Prove raw internet connectivity works by IP.
  • Reproduce the DNS failure using getent.
  • Inspect current resolver output in /etc/resolv.conf.
  • Identify the active NetworkManager connection name.
  • Set working DNS servers persistently with nmcli.
  • Apply the change and confirm /etc/resolv.conf updates.
  • Verify name resolution works again.

Concepts

  • If you can reach the internet by IP but not by hostname, DNS is the likely failure domain.
  • On NetworkManager systems, /etc/resolv.conf is typically generated state, not the source of truth.
  • Fix DNS at the profile layer (NetworkManager connection), not by editing resolver output directly.
  • Use getent to validate resolution using NSS, not just a single tool’s DNS behavior.
  • After a config change, force a re-apply so resolver state is regenerated.

Walkthrough

Step 1 : Confirm the host has a default route.
Command 
ip route
# OR
ip r

DNS will not work reliably without a valid path off the subnet. Confirm the default route before changing resolver settings. 

default via 192.168.50.1 dev eth0 proto dhcp metric 100
192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.20 metric 100
Step 2 : Prove internet connectivity works by IP.
Command 
ping -c 2 1.1.1.1
# OR
ping -c 2 8.8.8.8

If ping works by IP, your next suspect is name resolution, not routing. 

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=16.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=15.9 ms

--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
Step 3 : Demonstrate DNS failure using NSS (getent).
Command 
getent hosts example.com
# OR
getent ahostsv4 example.com

getent follows the system’s NSS order and gives you a clean signal: resolution either works or it does not. 

(no output)
getent: Name or service not known
Step 4 : Inspect the current resolver output.
Command 
cat /etc/resolv.conf
# OR
sudo cat /etc/resolv.conf

This host is pointing at 127.0.0.1 as its DNS server. That only works if a local resolver is running and configured. In this incident, it is not. 

# Generated by NetworkManager
search lab.local
nameserver 127.0.0.1
Step 5 : Identify the active NetworkManager connection name.
Command 
nmcli -t -f NAME,DEVICE con show --active

You will use the connection profile name next. Hardcoding a name across systems is fragile. 

System eth0:eth0
Step 6 : Set working DNS servers persistently with NetworkManager.
Commands 
sudo nmcli con mod "System eth0" ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con mod "System eth0" ipv4.ignore-auto-dns yes

This changes the source of truth so the fix survives link resets, DHCP renewals, and reboots. Setting ipv4.ignore-auto-dns yes prevents DHCP from overwriting your DNS servers. 

(no output)
Step 7 : Re-apply the connection to regenerate resolver state.
Command 
sudo nmcli con down "System eth0" && sudo nmcli con up "System eth0"

Bringing the connection down and up forces NetworkManager to re-apply the profile and regenerate resolver output. 

Connection 'System eth0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
Connection 'System eth0' successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/8)
Step 8 : Confirm /etc/resolv.conf contains real nameservers.
Command 
cat /etc/resolv.conf
# OR
sudo cat /etc/resolv.conf

This is your evidence that persistent configuration is now generating correct resolver output. 

# Generated by NetworkManager
search lab.local
nameserver 1.1.1.1
nameserver 8.8.8.8
Step 9 : Verify name resolution works again.
Command 
getent hosts example.com
# OR
getent ahostsv4 example.com

If this works, tools like dnf, curl, and package repositories should behave normally again. 

93.184.216.34   example.com

Breakpoints

No default route

Fix routing first. If there is no default route, DNS is not your primary problem. Confirm the interface has an address and the connection is up, then resolve gateway and DHCP issues.

Ping by IP fails

DNS is not the root cause yet. Pivot to link state, gateway reachability, VLAN or port config, and upstream ACLs.

resolv.conf looks correct but getent still fails

Confirm outbound UDP and TCP 53 are permitted and test DNS directly against a known resolver with dig @1.1.1.1 example.com .

Cleanup checklist

If you need to revert to DHCP-provided DNS, re-enable automatic DNS and clear the custom DNS list for the same connection profile, then re-apply.

Commands 
sudo nmcli con mod "System eth0" ipv4.ignore-auto-dns no
sudo nmcli con mod "System eth0" ipv4.dns ""
sudo nmcli con down "System eth0" && sudo nmcli con up "System eth0"

Reference

  • ip route : Show the kernel routing table (look for a default route).
    • ip r : Short form.
  • ping -c <n> <ip> : Confirm path connectivity without involving DNS.
    • -c <n> : Send a fixed number of echo requests.
  • getent hosts <name> : Resolve names through NSS.
  • getent ahostsv4 <name> : Resolve IPv4 addresses through NSS.
  • cat /etc/resolv.conf : View current resolver configuration (often generated by NetworkManager).
  • nmcli -t -f NAME,DEVICE con show --active : Print the active connection profile name and device.
    • -t : Terse output.
    • -f : Select fields to print.
  • nmcli con mod <name> ipv4.dns "A B" : Set persistent DNS servers for a connection.
  • nmcli con mod <name> ipv4.ignore-auto-dns yes|no : Control whether DHCP-provided DNS is used.
  • nmcli con down <name> && nmcli con up <name> : Re-apply settings and regenerate resolver state.
  • dig @<server> <name> : Query a specific DNS server directly.