DNS Configuration on Linux: Resolvers, BIND, DNSSEC, and Troubleshooting

DNS configuration on Linux has two different meanings: configuring a machine’s resolver so applications can look up names, and operating a DNS server that answers queries for a network or domain. Confusing those roles is a common cause of broken name resolution. This guide explains the distinction, shows how queries travel through the Linux networking stack, and provides a practical BIND configuration for a small authoritative or caching deployment. For a network-wide filtering resolver, see Self-Hosted DNS with Pi-hole and AdGuard Home.

What Is DNS Configuration on Linux?

The Domain Name System (DNS) maps names such as www.example.com to data such as IPv4 addresses, IPv6 addresses, mail servers, aliases, and service locations. A Linux host normally acts as a DNS client: applications ask a local resolver library, which sends queries to one or more configured recursive resolvers.

The resolver may be:

• A local stub such as systemd-resolved, which listens on a loopback address and forwards queries upstream.
• A network-provided resolver advertised by DHCP, a VPN, or a manually maintained /etc/resolv.conf.
• A full recursive or authoritative server such as BIND 9, Unbound, or NSD.

These roles are related but not interchangeable. A recursive resolver finds answers on behalf of clients and caches them. An authoritative server publishes the records for zones it serves and should not normally provide unrestricted recursion to the Internet. The BIND 9 Administrator Reference Manual documents the server’s configuration model and operational controls.

Why DNS Configuration Matters

Applications usually report a DNS problem as a timeout, an unknown host, or a failed connection, even though the underlying cause may be elsewhere. A Linux administrator has to separate several failure modes:

1. The host has no route to its configured resolver.
2. The local stub or resolver service is stopped or misconfigured.
3. An upstream resolver is reachable but returns SERVFAIL, NXDOMAIN, or stale data.
4. A local authoritative zone has a syntax, delegation, or serial-number error.
5. A firewall, VPN, container network, or split-DNS rule sends the query to the wrong place.

DNS also affects security. An open recursive resolver can be abused for reflection and amplification attacks. An improperly restricted zone transfer can expose internal hostnames. DNSSEC can authenticate signed answers, but it does not encrypt queries or make an unsigned zone trustworthy. The DNSSEC introduction in RFC 4033 explains the chain of trust and the difference between authentication and confidentiality.

How DNS Resolution Works on Linux

A typical lookup follows this path:

application
  -> libc resolver or language runtime
  -> /etc/nsswitch.conf and resolver configuration
  -> local stub (for example, 127.0.0.53:53)
  -> recursive resolver cache
  -> root servers -> TLD servers -> authoritative servers
  -> response cached according to TTL
  -> application receives the result

The exact path depends on the distribution and enabled services. /etc/nsswitch.conf determines whether a hostname is resolved through DNS, local files, mDNS, or other name services. /etc/resolv.conf usually supplies nameserver addresses, search domains, and options. On systems using systemd-resolved, /etc/resolv.conf may point to a generated file or to the local stub at 127.0.0.53; editing it directly can therefore be temporary or ineffective.

When a recursive resolver does not have a usable cached answer, it follows delegations. Root servers direct it to a top-level-domain server, and the TLD server directs it to the authoritative nameserver for the requested domain. An authoritative server returns the zone data, such as an A, AAAA, CNAME, MX, TXT, or NS record. The resolver then caches the result until its TTL expires.

DNS normally uses UDP port 53 for small queries. TCP port 53 is required for zone transfers and may be used when a response is truncated or too large for the selected transport. DNS over TLS and DNS over HTTPS change the transport between a client and a resolver, but they do not replace authoritative DNS or change the records in a zone.

Components and Configuration Models

The Linux client resolver

The client side includes applications, the Name Service Switch, a resolver library, and a source of nameserver configuration. NetworkManager, netplan, systemd-networkd, VPN software, and DHCP clients may all update that configuration. First identify the owner before making a persistent change.

cat /etc/nsswitch.conf
ls -l /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

If resolvectl status reports that systemd-resolved is not available, use the active network manager’s status commands instead. A manually edited /etc/resolv.conf is appropriate only when the host is deliberately configured that way and no service will overwrite it.

Recursive, forwarding, and authoritative roles

Small networks often use one service for more than one role, but the policies must remain explicit. A server can be authoritative for lab.example and recursive for trusted clients while refusing recursion to untrusted sources. Public authoritative servers should normally disable recursion.

Records and zones

A zone is the portion of the namespace for which a server is authoritative. A zone file contains resource records and an SOA record that controls serial numbers, refresh behavior, retry timing, and negative caching. Common records include:

An A record does not automatically create an AAAA record, and a CNAME cannot normally coexist with other data at the same owner name. Plan the record set and delegation before editing a production zone.

Practical BIND Configuration

BIND is a mature choice when Linux must serve authoritative zones, recursive queries, or both. Package names and file locations vary slightly by distribution. On Debian or Ubuntu, a common starting point is:

sudo apt update
sudo apt install bind9 bind9-utils dnsutils
sudo systemctl enable --now bind9

On a dedicated authoritative server, keep recursion off and restrict transfers. The following named.conf.options example, stored under /etc/bind, permits queries from the local network but does not expose an open resolver:

options {
    directory "/var/cache/bind";

    listen-on { 127.0.0.1; 192.0.2.10; };
    listen-on-v6 { none; };

    recursion no;
    allow-query { any; };
    allow-transfer { none; };

    dnssec-validation auto;
};

Replace 192.0.2.10 with an address assigned to the server. The address block in this example is reserved for documentation. If the same BIND instance is intentionally a recursive resolver, use an ACL and permit recursion only for trusted networks:

acl "trusted_clients" {
    127.0.0.1;
    192.0.2.0/24;
};

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-query { trusted_clients; };
    allow-recursion { trusted_clients; };
    allow-transfer { none; };
    forwarders {
        1.1.1.1;
        9.9.9.9;
    };
    dnssec-validation auto;
};

Forwarders are a policy choice, not a universal performance fix. Select resolvers that meet the network’s privacy, availability, filtering, and compliance requirements. Do not list a public resolver as a forwarder merely because it is familiar; verify that it is reachable and that its behavior is suitable for the environment.

Define an authoritative zone

Add a zone declaration to named.conf.local under /etc/bind:

zone "lab.example" {
    type primary;
    file "/etc/bind/db.lab.example";
    allow-query { any; };
    allow-transfer { 192.0.2.11; };
};

Create db.lab.example under /etc/bind with a valid SOA, nameservers, and records:

$TTL 300
@   IN  SOA ns1.lab.example. hostmaster.lab.example. (
        2026092201 ; serial: increase for every published change
        3600       ; refresh
        600        ; retry
        86400      ; expire
        300        ; negative cache TTL
)

    IN  NS  ns1.lab.example.
    IN  NS  ns2.lab.example.

ns1 IN  A   192.0.2.10
ns2 IN  A   192.0.2.11
www IN  A   192.0.2.20

Names ending with a dot are fully qualified. Without the dot, BIND may append the zone name, which can create an unexpected name such as ns1.lab.example.lab.example. For a secondary server, use type secondary, specify the primary address, and permit transfers only between the intended servers.

Validate and reload safely

Validate the configuration and zone before asking BIND to reload:

sudo named-checkconf
sudo named-checkzone lab.example /etc/bind/db.lab.example
sudo systemctl reload bind9
sudo journalctl -u bind9 -n 50 --no-pager

Then query both the local server and an explicitly selected server:

dig @127.0.0.1 lab.example SOA +noall +answer
dig @192.0.2.10 www.lab.example A +noall +answer
dig @192.0.2.11 lab.example NS +noall +answer

The SOA serial is part of the synchronization protocol. Increment it before reloading a changed primary zone so secondaries know that new data is available. Check that UDP and TCP port 53 are allowed where required, and confirm that the parent delegation points to reachable authoritative nameservers.

Real-World Use Cases

A workstation or server

Use the distribution’s network manager to select DNS servers and preserve the setting across reboots. Prefer resolvectl or NetworkManager configuration over replacing a generated /etc/resolv.conf. If a VPN provides private DNS, verify that its search domains and routing rules do not override public lookups unexpectedly.

A home lab or small office

A local recursive resolver can reduce repeated upstream lookups and provide split DNS for private names. Restrict recursion to LAN or VPN ranges, expose only the required interfaces, and monitor cache and query behavior. Keep internal zones separate from public authoritative zones unless there is a clear operational reason to combine them.

An authoritative service

Use at least two authoritative servers on independent failure domains. Restrict AXFR and IXFR, maintain a documented zone serial policy, monitor SOA and NS responses, and test both UDP and TCP queries. DNSSEC signing should be planned with key storage, rollover, DS publication, and recovery procedures rather than enabled as an isolated checkbox.

Containers and orchestration

Containers often receive a generated resolver configuration and a platform-specific DNS address. A query that works on the host may fail in a container because of an isolated network namespace, search-domain mismatch, or an unreachable upstream. The container networking guide explains how service discovery, network namespaces, and policy affect these queries.

Troubleshooting DNS on Linux

Use a layered workflow and change one variable at a time:

1. Inspect the owner: Check /etc/resolv.conf, resolvectl status, NetworkManager, netplan, or the relevant VPN.
2. Test the local path: Query the configured resolver without relying on application behavior.
3. Test a known resolver: Compare the result with a resolver selected explicitly.
4. Check authority: Query the authoritative server and inspect the delegation chain.
5. Check transport: Verify routes, firewall rules, and both UDP and TCP port 53.
6. Check caching and time: Compare TTLs, flush only the relevant cache, and verify system time for DNSSEC validation.

Useful commands include:

# Show resolver configuration and per-link DNS
resolvectl status

# Query the local configured path
resolvectl query example.com
getent ahosts example.com

# Compare a public recursive resolver with a local service
dig @1.1.1.1 example.com A +stats
dig @127.0.0.53 example.com A +stats

# Follow referrals from the root toward authority
dig +trace example.com

# Check an authoritative server directly
dig @ns1.example.com example.com SOA +noall +answer

getent tests the path applications using the Name Service Switch may follow, while dig sends a DNS query directly and exposes flags, response codes, authority data, and timing. If an IP address works but a hostname fails, start with DNS; if a direct query works but getent fails, inspect NSS, the local stub, search domains, and application-specific behavior.

For BIND, inspect journalctl -u bind9, run named-checkconf and named-checkzone, and look for REFUSED, SERVFAIL, or timeout responses. REFUSED often indicates an ACL or recursion policy; SERVFAIL can indicate an unreachable upstream, broken delegation, or DNSSEC validation failure. A timeout points more strongly toward routing, firewall, listening-address, or transport problems.

Common Misconceptions

“Changing DNS makes the Internet connection faster”

It can reduce lookup latency or improve reliability, but it does not increase link capacity or fix packet loss. Measure query timing separately from the time spent connecting to the returned service.

“/etc/resolv.conf is always the permanent configuration”

Not on many current Linux installations. It may be a symlink managed by systemd-resolved, NetworkManager, netplan, DHCP, or a VPN client. Identify the manager before editing the file.

“DNSSEC encrypts DNS traffic”

DNSSEC authenticates signed DNS data and helps detect tampering. It does not hide the queried name or encrypt the transport. Use an appropriate encrypted resolver transport when confidentiality is required.

“A recursive resolver and an authoritative server are the same thing”

They answer different questions. A recursive resolver finds and caches answers for clients; an authoritative server publishes the source-of-truth data for its zones. One BIND process can perform both roles only when its access controls make that combination safe.

“A successful ping proves DNS is healthy”

Ping may use a cached name, an IP address, or an application path unrelated to the failing lookup. Query the resolver directly and inspect the response code, address family, TTL, and selected server.

Related Articles

• Learn focused lookup techniques in How to Check DNS Records of a Domain.
• Use a broader layered workflow in Network Troubleshooting in Linux.
• Compare the enterprise model in Windows DNS Server Architecture.
• Understand resolver behavior inside workloads with Container Networking Explained.

Authoritative references: BIND 9 documentation, systemd-resolved service documentation, DNSSEC overview in RFC 4033, and IANA’s root server information.