Introduction

A DNS server can answer authoritatively for zones, resolve names recursively for clients, or cache previous answers. Mixing these roles without access controls can expose an open resolver or unwanted zone data.

What you should be able to do after this lesson:

Distinguish authoritative, recursive, forwarding, and caching roles.
Navigate common BIND configuration layouts.
Declare zones and forwarders.
Validate, reload, and query the server.
Restrict recursion and configure useful logging.

Big Idea: One DNS Process Can Perform Different Roles

Classify every answer by its source:

local zone data -> authoritative answer
previous lookup -> cached answer
full lookup on behalf of a client -> recursive answer
query sent to another resolver -> forwarded answer

The same BIND process can perform several roles, but access policy should make each role intentional. Public authoritative data may be available to everyone while recursion is limited to internal clients.

DNS Server Roles

An authoritative server answers from zones it hosts.
A recursive resolver follows referrals to find an answer for a client.
A caching resolver retains previous results according to TTL.
A forwarder sends selected or all unresolved queries to another resolver.

An Internet-facing authoritative server generally should not provide unrestricted recursion.

BIND Configuration

The primary file may be /etc/named.conf or /etc/bind/named.conf, with included files for options and zones.

Example options:

options {
    directory "/var/named";
    listen-on { 192.0.2.53; };
    recursion yes;
    allow-recursion { 192.0.2.0/24; localhost; };
    forwarders { 203.0.113.53; };
};

Example primary zone declaration:

zone "example.test" IN {
    type primary;
    file "example.test.zone";
};

Older terminology may use master and slave; newer BIND documentation also uses primary and secondary.

Root hints identify root servers used to begin iterative resolution when no forwarder supplies the answer. A caching-only resolver normally has no locally managed authoritative zones beyond infrastructure such as localhost, but it still needs a path to the DNS hierarchy.

Validate Before Reloading

named-checkconf
named-checkzone example.test /var/named/example.test.zone
rndc status
rndc reload

named-checkconf validates configuration syntax. Zone validation is separate. A reload preserves service availability when supported; a restart is not required for every zone update.

Query the Server

dig @127.0.0.1 example.test A
dig @127.0.0.1 example.test SOA
dig @127.0.0.1 example.net A +norecurse
host example.test 127.0.0.1

Inspect status flags such as aa for authoritative answer and ra for recursion available. Confirm both successful and intentionally refused queries.

Logging

BIND can write channels and categories for queries, security, resolver activity, and zone transfers. Query logging is high volume and may include sensitive client behavior, so enable it deliberately and rotate logs.

Alternative Servers

Be aware of alternatives such as dnsmasq, djbdns, and PowerDNS. Their configuration differs, but DNS roles and security boundaries remain the same.

Troubleshooting Order

Validate syntax and zone files.
Confirm the daemon listens on UDP and TCP port 53.
Query the loopback address directly.
Check recursion and ACL behavior.
Check firewall rules and then query from a client.
Review DNS and system logs.

Guided Practice: Prove Each Server Role

On an authorized BIND lab server, validate configuration and inspect listeners:

named-checkconf
rndc status
ss -lntup | grep ':53'

Run three explicit queries:

dig @127.0.0.1 example.test SOA +norecurse
dig @127.0.0.1 www.example.test A +norecurse
dig @127.0.0.1 www.example.net A

For each response, record the response code and flags. An authoritative answer normally includes aa; a server that offers recursion advertises ra. Repeat a recursive lookup and compare query time to observe caching without assuming that speed alone proves the cache.

Change only a harmless lab logging or ACL setting. Validate again and reload with rndc reload. Historical service procedures may send a signal such as SIGHUP with kill, but rndc provides explicit named control and clearer errors.

Troubleshooting Scenario

External clients can query a hosted zone, but they can also resolve arbitrary Internet names through the same server. The server has unintentionally become an open recursive resolver.

Keep authoritative queries available, restrict allow-recursion and cache access to trusted networks, validate configuration, reload, and test both an allowed internal client and a denied external client. Blocking all port 53 traffic would also break the intended authoritative service.

Exam Focus

Distinguish authoritative, recursive, caching-only, and forwarding behavior.
Know /etc/named.conf, /var/named/, included files, and root hints.
Use named-checkconf, rndc, host, and dig for different checks.
Recognize dnsmasq, djbdns, and PowerDNS as alternatives.

Recap

Define the server role before writing configuration.
Validate configuration and zone data separately.
Restrict recursion to trusted clients.
Use direct dig @server queries to bypass unrelated resolver settings.

207.1 Basic DNS server configuration