Linucate
~ Linucate_

207.3 Securing a DNS server

All Levels

Introduction

DNS is both critical infrastructure and a frequent attack target. Security begins by exposing only the function each server needs: authoritative service, internal recursion, or forwarding.

What you should be able to do after this lesson:

  • Restrict recursion, queries, updates, and transfers.
  • Run BIND with reduced privileges and understand chroot isolation.
  • Authenticate server-to-server operations with TSIG.
  • Explain DNSSEC signing and validation.
  • Recognize DANE and TLSA records.

Big Idea: Protect the Role, the Process, and the Data

DNS security has three independent boundaries:

  • service policy: who may query, recurse, update, or transfer
  • process isolation: which user and filesystem tree BIND can access
  • data authenticity: whether peers and resolvers can validate DNS messages or records

ACLs, chroot, TSIG, and DNSSEC address different boundaries and do not replace one another.

Minimize the Exposed Role

An authoritative public server should normally refuse recursion for arbitrary clients. An internal resolver should limit access to trusted networks and does not need to host public primary zones.

Useful controls include:

allow-query { any; };
allow-recursion { trusted; };
allow-transfer { key secondary-key; };
allow-update { none; };
version "not disclosed";

Also restrict network access to required UDP and TCP port 53 paths.

Privilege and chroot

BIND should run as a dedicated unprivileged account after opening required sockets and files. A chroot changes the process root to a restricted directory tree. Required configuration, zone data, libraries, device files, and runtime paths must exist inside that tree.

A chroot reduces some filesystem exposure but does not replace current patches, access controls, or mandatory access-control systems.

The service account is represented in /etc/passwd like other local accounts, normally with no interactive login shell. Paths inside a chroot are interpreted relative to the restricted root, so logs, keys, zone files, and runtime sockets need deliberate placement and permissions.

Views and Forwarding

BIND views can present different data based on client source. This supports split DNS, but overlapping ACLs or inconsistent internal and external records can be difficult to troubleshoot.

Forwarders centralize recursive traffic:

forwarders { 192.0.2.53; 192.0.2.54; };
forward only;

TSIG

TSIG uses a shared secret to authenticate messages such as zone transfers or dynamic updates.

tsig-keygen secondary-key

Both peers need the secret. Protect key files with restrictive permissions and rotate compromised keys. TSIG authenticates participating systems; it does not encrypt ordinary DNS query contents.

DNSSEC

DNSSEC signs DNS data so validating resolvers can detect tampering and authenticate the chain of delegation.

Common tools include:

dnssec-keygen
dnssec-signzone
dig +dnssec example.test

Operational correctness depends on keys, signatures, parent DS records, time, and rollover procedures. A broken chain can make a valid zone appear bogus to validating clients.

DANE Awareness

DANE publishes TLS association information in TLSA records and relies on DNSSEC for authenticity. It can bind a service certificate or key to DNS policy.

Guided Practice: Audit a DNS Security Boundary

On a lab server, write a test matrix before making changes:

Client Hosted-zone query Recursive query Zone transfer Dynamic update
external allow deny deny deny
internal allow allow deny policy-dependent
secondary allow policy-dependent TSIG allow deny

Run each allowed and denied query from the relevant network position. Inspect effective process identity and paths:

ps -o user,group,pid,args -C named
named-checkconf
rndc status

Generate a lab TSIG key, store it outside world-readable paths, and configure a transfer permission that names the key rather than an unrestricted address. Test both signed success and unsigned refusal.

Troubleshooting Scenario

After a DNSSEC key rollover, validating clients return SERVFAIL, while nonvalidating tests appear successful. The parent still publishes a DS record for the retired key.

Inspect the chain with dig +dnssec, compare DNSKEY and DS data, check signature validity and system time, and repair the rollover sequence. Disabling validation on clients hides the integrity failure rather than restoring a valid chain.

Exam Focus

  • Restrict recursion, updates, and transfers independently.
  • Understand non-root execution and chroot path requirements.
  • TSIG authenticates selected peer operations but does not encrypt normal queries.
  • DNSSEC signs DNS data; DANE depends on authenticated DNSSEC records.

Recap

  • Separate authoritative and recursive roles where practical.
  • Apply least privilege, ACLs, patching, and network controls together.
  • TSIG authenticates selected DNS messages between peers.
  • DNSSEC protects authenticity and integrity, not confidentiality.
🎯

Test Your Knowledge

Complete the quiz to assess your understanding of this course's concepts.

Back home