The 'Nameserver Not Known' error in CentOS Stream 9 typically indicates that the system cannot resolve domain names because the DNS configuration is either missing, incorrect, or blocked by local firewall rules. This issue often arises when NetworkManager fails to properly propagate DNS settings from the DHCP server to the systemd-resolved service, leaving the resolver with an empty cache or invalid upstream servers.
Understanding the Root Cause
CentOS Stream 9 relies heavily on
NetworkManager for network configuration and
systemd-resolved for name resolution. When a server is directly connected to a router via DHCP, the expectation is that the router will push valid DNS server addresses to the client. If these addresses are not received or applied correctly, commands like
nslookup or
dig will fail with "nameserver not known" or similar timeout errors. This is distinct from general connectivity issues; your ping to IP addresses may work perfectly, but any attempt to resolve hostnames will fail. It is crucial to distinguish this from broader internet connectivity problems, which might require checking physical links or routing tables instead. For related diagnostic steps on general connectivity failures, you may refer to our guide on
Troubleshooting: Cannot Connect to the Internet.
Verifying Current DNS Configuration
Before applying fixes, you must identify exactly what the system thinks its DNS servers are. Open a terminal and run the following command to check the status of the resolved daemon:
systemctl status systemd-resolved
Next, query the current DNS servers assigned to your active interface. Replace
eth0 with your actual interface name, which you can find using
ip link:
resolvectl status eth0
If the output shows "DNS Servers: --" or lists invalid IPs, the configuration is broken. You should also inspect the file
/etc/resolv.conf. In modern CentOS Stream 9, this is usually a symbolic link to the runtime configuration managed by systemd-resolved. If it points elsewhere or contains static entries that do not match your network environment, conflicts may arise.
Restarting Network Services
Often, the issue is a transient state where NetworkManager has lost sync with the DHCP lease or the DNS resolver cache has become corrupted. The simplest first step is to restart the relevant services to force a refresh of the configuration. Execute the following commands in sequence:
sudo systemctl restart NetworkManager
sudo systemctl restart systemd-resolved
After restarting, wait a few seconds and test resolution again using
ping google.com. If the error persists, proceed to manual configuration verification.
Manually Configuring DNS via NetworkManager
If automatic DHCP assignment continues to fail, you can manually specify DNS servers through NetworkManager. This ensures that even if the router does not provide them, your system uses reliable public resolvers like Google (8.8.8.8) or Cloudflare (1.1.1.1).
First, identify the connection UUID or name associated with your network interface:
nmtui-connect
Alternatively, use the command line to modify the connection profile. Assuming your connection is named
System eth0, run:
nmcli con mod "System eth0" ipv4.dns "8.8.8.8 1.1.1.1"
nmcli con mod "System eth0" ipv4.ignore-auto-dns true
nmcli con up "System eth0"
The command
ipv4.ignore-auto-dns true prevents NetworkManager from overwriting your manual settings with potentially bad data from the router. After bringing the connection back up, verify the change with
resolvectl status to ensure the new servers are listed.
Checking Firewall and SELinux Restrictions
In some cases, the firewall may block outbound DNS traffic on port 53. While rare for standard setups, it is worth verifying that no custom rules are interfering. Check the active zones and allowed services:
firewall-cmd --list-all
Ensure that
dns is listed under services, or that UDP port 53 is open. Additionally, while SELinux rarely blocks DNS resolution itself, misconfigured policies on network interfaces can sometimes cause unexpected behavior. If you have recently changed SELinux contexts for network tools, consider resetting them or temporarily setting SELinux to permissive mode for testing purposes only.
Testing Resolution Stability
Once configured, validate the fix by running repeated resolution tests. Use
dig or
nslookup multiple times to ensure consistency:
dig google.com +short
nslookup google.com
If these commands return IP addresses consistently without timeouts, the issue is resolved. Monitor the system logs for any recurring errors using
journalctl -u systemd-resolved -f to catch intermittent failures. For more complex scenarios involving temporary failures or specific Linux distributions like Kali, see our article on
Kali Linux: Troubleshooting Temporary Failure in Name Resolution.
Frequently Asked Questions
Why does ping work but nslookup fails?
This confirms that your network layer is functioning correctly, isolating the problem to the application layer's name resolution process. It means your IP connectivity is fine, but the system lacks valid DNS server addresses to translate hostnames into IPs.
How do I clear the DNS cache in CentOS Stream 9?
You can flush the systemd-resolved cache by restarting the service using
sudo systemctl restart systemd-resolved. Alternatively, you can use the command
resolvectl flush-caches to clear the cache without stopping the daemon entirely.
Can I use /etc/resolv.conf directly to fix this?
While you can edit
/etc/resolv.conf, it is generally discouraged on CentOS Stream 9 because NetworkManager and systemd-resolved manage this file dynamically. Changes made here may be overwritten during the next network restart or DHCP renewal.
What if my router does not provide DNS servers via DHCP?
In this case, you must configure static DNS servers manually as described in the NetworkManager section. Setting
ipv4.ignore-auto-dns to true ensures your manual entries persist regardless of the router's DHCP output.
Is this issue common in virtual machines?
Yes, VMs often face this issue if the virtual network adapter is set to NAT or Bridged mode incorrectly, or if the guest OS fails to negotiate proper DHCP options. Ensuring the virtual NIC is attached to a network that provides valid DNS information is critical.