CentOS 9 Stream DNS Failures from systemd-resolved Misconfiguration

Problem: name resolution fails but the network is up

On CentOS Stream 9, ping to an IP address works and the interface has an address, but hostname lookups fail for local commands and applications. The useful takeaway is that systemd-resolved owns name resolution and the failure is usually service state, the resolv.conf symlink, or missing upstream DNS, not a broken network.

This guide assumes CentOS Stream 9 with systemd-resolved enabled. Behavior varies with systemd versions and network manager configuration. Verify on the target system before applying changes.

Recognizable condition

• ping 8.8.8.8 succeeds, ping example.com fails with Name or service not known
• Applications report DNS timeouts while curl with an IP works
• /etc/resolv.conf contains nameserver 127.0.0.53 but queries never reach upstream DNS

Cause and diagnostic table

Ordered checks

1. Confirm systemd-resolved unit

Run as root or with sudo on the host.

systemctl status systemd-resolved

Check that the unit is active and not masked. A masked unit prevents start and leaves the stub at 127.0.0.53 unresponsive.

2. Verify resolv.conf is a symlink

ls -l /etc/resolv.conf

Expected state is a symlink to /run/systemd/resolve/stub-resolv.conf. If it is a regular file, the kernel will not follow systemd-resolved updates. Do not edit /etc/resolv.conf directly.

3. Inspect resolved.conf for upstream DNS

cat /etc/systemd/resolved.conf

Check the DNS= directive under [Resolve]. If empty, systemd-resolved relies on per-link DNS from the network manager. Add a valid upstream if required.

4. Check interface binding

resolvectl status

Confirm the active interface appears and lists DNS servers. If the interface is absent or shows no DNS, the resolver has no upstream.

5. Check firewall and SELinux

firewall-cmd --list-ports

getsebool -a | grep dns

UDP and TCP port 53 must be allowed for outbound queries. SELinux booleans affecting DNS should be reviewed by an administrator. Changing SELinux policy reduces security; apply only if necessary.

Fixes tied to findings

Service inactive or masked

systemctl unmask systemd-resolved

systemctl enable --now systemd-resolved

Risk: enabling a previously disabled service changes resolver behavior for all users.

Missing symlink

Restore the managed symlink. Backup any custom file first.

mv /etc/resolv.conf /etc/resolv.conf.bak

ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Rollback: restore the backup if applications require a static file.

No upstream DNS in resolved.conf

Backup the file before editing.

cp /etc/systemd/resolved.conf /etc/systemd/resolved.conf.bak

Edit /etc/systemd/resolved.conf and set a valid upstream, for example:

[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=

Reload configuration.

systemctl restart systemd-resolved

Risk: hard-coded DNS bypasses local DNS infrastructure.

Firewall or SELinux blocking

Add ports only after confirming the block. Use firewall-cmd in a persistent way and reload. SELinux changes should be tested in permissive mode first.

Verification

Test the stub resolver directly.

dig @127.0.0.1 example.com

Test normal resolution.

ping -c 1 example.com

Check logs for DNS errors.

journalctl -u systemd-resolved --since today

Limitations: this draft reflects model knowledge of systemd-resolved on CentOS Stream 9 and requires current verification on the target system. NetworkManager, NetworkManager-dispatcher, and custom resolver setups can change where DNS is sourced.

Escalation criteria

• systemd-resolved is active and correctly configured but queries still fail to upstream DNS
• resolvectl status shows DNS servers unreachable from the host
• Logs show permission denials despite correct firewall rules

Escalate to network team for upstream DNS reachability and to security team for SELinux policy review.