How to Fix DNS on Linux Server in 2026? – Easy Guide

To fix DNS on a Linux server, verify network connectivity, check which resolver stack you use (systemd-resolved, NetworkManager, or plain resolv.conf), set correct nameservers, flush DNS caches, and test with dig.

If you run a DNS service (BIND/Unbound/dnsmasq), validate configuration, open port 53, and confirm zones and recursion. DNS failing on a server breaks updates, package installs, and outbound API calls.

In this guide, I’ll show you how to fix DNS on Linux server environments step-by-step, using simple commands, proven diagnostics, and distribution-specific instructions. Whether you’re a beginner or maintaining production nodes, you’ll find quick wins and robust, permanent fixes.

Quick DNS Diagnosis Checklist

• Check basic network connectivity: can you ping an IP (not a domain)?
• Identify your resolver stack: systemd-resolved, NetworkManager, or static /etc/resolv.conf.
• Inspect current nameservers and search domains.
• Test DNS resolution with dig and nslookup.
• Flush DNS caches (client and local DNS services).
• Check firewall/SELinux for port 53 if the server runs DNS.
• Review logs: systemd-journals and service logs for errors (SERVFAIL, timeouts).

# 1) Connectivity
ping -c2 1.1.1.1 || ping -c2 8.8.8.8

# 2) What resolver do I use?
readlink -f /etc/resolv.conf
resolvectl status 2>/dev/null || systemd-resolve --status 2>/dev/null

# 3) What is my DNS seeing?
cat /etc/resolv.conf
dig youstable.com +short
nslookup youstable.com

# 4) Trace a domain (find where it fails)
dig example.com +trace

# 5) Logs (adjust service name as needed)
journalctl -u systemd-resolved --no-pager --since "10 min ago"
journalctl -u named --since "1 hour ago"
journalctl -u unbound --since "1 hour ago"

Understand How DNS Works on Linux

glibc resolver and nsswitch

Most Linux apps rely on the glibc resolver, which consults sources listed in /etc/nsswitch.conf. The line “hosts: files dns myhostname” controls resolution order. If DNS appears ignored, check nsswitch to ensure “dns” is present and not blocked by misordered sources.

/etc/resolv.conf

resolv.conf defines nameserver IPs, search domains, and options (like timeout and attempts). Depending on your distro, it may be managed by systemd-resolved, NetworkManager, netplan, or cloud-init. Editing it directly may be overwritten on reboot—use the right tool for persistent changes.

systemd-resolved

On many modern distros (Ubuntu, Debian, Fedora), systemd-resolved is the stub resolver. It commonly uses 127.0.0.53 as a local DNS and manages resolv.conf via a symlink. Use resolvectl to view and set DNS per interface and to flush caches.

NetworkManager, netplan, and ifcfg

NetworkManager (nmcli) and netplan (Ubuntu cloud images) configure interfaces and DNS persistently. RHEL-based systems may use ifcfg files. Cloud-init may set DNS at boot from metadata. Set DNS in the appropriate layer for changes to persist across reboots.

Client-Side Fixes: DNS Not Working on a Linux Server

Step 1: Verify network connectivity and routing

ip a
ip route
ping -c3 1.1.1.1
curl -I http://1.1.1.1

If ping to an IP works but resolving domains fails, the issue is DNS-specific. If IP connectivity is also broken, fix networking first (gateway, routes, security groups).

Step 2: Inspect and set resolv.conf (temporary)

cat /etc/resolv.conf
# Quick temporary fix: point to public resolvers
sudo sed -i.bak 's/^/#/' /etc/resolv.conf
printf "nameserver 1.1.1.1\nnameserver 8.8.8.8\noptions timeout:2 attempts:2\n" | sudo tee /etc/resolv.conf

This may be overwritten by your network stack. Make it persistent using the correct tool below.

Step 3: Use systemd-resolved properly (Ubuntu/Debian/Fedora)

# Show current DNS per interface
resolvectl status

# Set DNS for a specific interface, e.g., eth0
sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl domain eth0 example.local

# Ensure resolv.conf points to systemd-resolved's stub
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# Flush cache
sudo resolvectl flush-caches

If resolv.conf is not a symlink to systemd’s file, mismatches can cause failures. Recreate the symlink as shown.

Step 4: NetworkManager persistent DNS (RHEL/CentOS/Alma/Rocky/Ubuntu Desktop)

# List connections and pick the active one
nmcli con show
# Set DNS and disable automatic DNS from DHCP if needed
sudo nmcli con mod <CONNECTION_NAME> ipv4.ignore-auto-dns yes
sudo nmcli con mod <CONNECTION_NAME> ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con up <CONNECTION_NAME>  # or reload
# For IPv6 if applicable
sudo nmcli con mod <CONNECTION_NAME> ipv6.ignore-auto-dns yes
sudo nmcli con mod <CONNECTION_NAME> ipv6.dns "2606:4700:4700::1111 2001:4860:4860::8888"

Step 5: Netplan (common on Ubuntu cloud images)

sudo nano /etc/netplan/50-cloud-init.yaml
# Example:
# network:
#   version: 2
#   ethernets:
#     eth0:
#       dhcp4: yes
#       nameservers:
#         addresses: [1.1.1.1, 8.8.8.8]
sudo netplan apply

If cloud-init overwrites DNS on reboot, set DNS in /etc/cloud/cloud.cfg or the datasource (metadata) as per your provider’s docs.

Step 6: Fix nsswitch order and hosts file

grep '^hosts:' /etc/nsswitch.conf
# Recommended baseline:
# hosts: files dns myhostname

sudo sed -i 's/^hosts:.*/hosts: files dns myhostname/' /etc/nsswitch.conf
sudo head -n 50 /etc/hosts

Ensure /etc/hosts doesn’t contain conflicting entries that hijack domains you need to resolve via DNS.

Step 7: Flush local DNS caches

# systemd-resolved
sudo resolvectl flush-caches

# nscd
sudo nscd -i hosts

# dnsmasq (cache flush by SIGHUP)
sudo killall -HUP dnsmasq

# unbound
sudo unbound-control flush_zone .  # or specific zones

Step 8: VPN, split-DNS, and IPv6 pitfalls

VPN clients often install their own resolv.conf or push DNS via NetworkManager. Test without VPN. If IPv6 is enabled but your resolver can’t reach v6 upstreams, either add working IPv6 DNS or disable IPv6 DNS for now via NetworkManager or resolv.conf options.

If Your Server Runs DNS (BIND/Unbound/dnsmasq)

Open and test port 53 (UDP/TCP)

# Firewalld
sudo firewall-cmd --add-service=dns --permanent
sudo firewall-cmd --reload

# UFW
sudo ufw allow 53
sudo ufw allow 53/udp

# nftables quick check
sudo nft list ruleset | sed -n '1,200p'

# Test externally (from another host)
dig @SERVER_IP example.com A
dig @SERVER_IP google.com A +tcp

BIND (named) configuration and zone sanity

# Validate configs and zones
sudo named-checkconf
sudo named-checkzone example.com /var/named/example.com.zone

# Common mistakes:
# - Missing SOA/NS records
# - Serial number not incremented
# - Wrong allow-query / recursion settings

For a resolver serving your private network, enable recursion and restrict access:

options {
    recursion yes;
    allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
    allow-query     { any; };
    dnssec-validation auto;
};

Unbound as a validating resolver

# Check logs for SERVFAIL (often DNSSEC-related)
journalctl -u unbound -e

# Basic allowlist for your LAN:
server:
  interface: 0.0.0.0
  access-control: 10.0.0.0/8 allow
  access-control: 192.168.0.0/16 allow
  verbosity: 1

dnsmasq notes

dnsmasq can forward or cache DNS. If it’s bound to 127.0.0.1 but resolv.conf points elsewhere, clients may bypass it. Align resolv.conf or systemd-resolved to use dnsmasq, and HUP after changes.

DNSSEC and SERVFAIL

If you see SERVFAIL sporadically, it may be DNSSEC validation failing due to time skew or upstream issues. Ensure NTP is healthy and your resolver can reach root and TLD servers. As a temporary workaround, use a public resolver (1.1.1.1, 8.8.8.8) while you fix validation.

Verification: Confirm DNS Is Healthy

• Resolve multiple domains: A, AAAA, MX, and NS records.
• Test UDP and TCP on port 53 if you run a DNS service.
• Trace a problematic domain end-to-end with dig +trace.
• Packet capture to see timeouts or refusals.

dig youstable.com A +short
dig google.com MX +short
dig @1.1.1.1 cloudflare.com NS +short
dig example.com AAAA +short
dig +trace example.com

# Tcpdump (observe DNS traffic)
sudo tcpdump -ni any port 53 -vv

Make DNS Settings Persistent

• Use nmcli or netplan instead of editing resolv.conf directly.
• Align systemd-resolved and resolv.conf symlink.
• Disable overwrite sources (DHCP ignore-auto-dns, cloud-init updates) if needed.
• Document DNS choices (public vs. private resolvers) per environment.

Prevention: Reduce DNS Outages

• Always configure at least two resolvers from different networks (e.g., 1.1.1.1 and 8.8.8.8).
• Monitor DNS latency and failure rates with scripts or a monitoring suite.
• Use DNS caching locally (systemd-resolved, Unbound) for faster responses.
• Keep time synced (NTP/chrony) to avoid DNSSEC validation failures.
• Control changes via configuration management (Ansible, Terraform).

When to Escalate and How YouStable Helps

If you still see timeouts, SERVFAIL, or intermittent resolution under load, the issue may involve upstream filters, ISP peering, or recursive resolver behavior. In production, consider managed DNS and managed servers. YouStable’s hosting stack ships with hardened defaults, 24/7 support, and best-practice resolver configurations to keep your apps reachable.

Common Errors and Fast Fixes

• “Temporary failure in name resolution” — set working nameservers and flush caches.
• “connection timed out; no servers could be reached” — check firewall, upstream reachability, or VPN.
• “SERVFAIL” — inspect DNSSEC, time sync, or zone delegation problems.
• resolv.conf keeps changing — configure DNS in NetworkManager, netplan, or cloud-init.
• Works with IP but not hostname — fix nsswitch order and DNS settings.

FAQ’s – Fix DNS on Linux Server