2.3Securing a DNS Server

DNS has long been targeted via cache poisoning and response spoofing. Understand it as two complementary layers: infrastructure hardening (chroot, restricted forwarders) that limits blast radius, and protocol-level guarantees (DNSSEC, TSIG, DANE) that ensure responses are genuine.

2.3.1Restricting the process and forwarding targets

• A chroot jail confines the named process's visible filesystem to just a restricted root subtree. Even if compromised, it cannot reach the real /etc and similar—localizing the blast radius.
• forwarders restricts, via forwarders { } in named.conf, which servers recursive queries are handed off to. Not recursing unrestricted anywhere reduces the risk of unintended external responses and cache poisoning.

2.3.2DNSSEC, TSIG, and DANE

• DNSSEC attaches a digital signature to zone data so a resolver can verify a response was not tampered with. Generate keys with dnssec-keygen and sign a zone with dnssec-signzone.
• TSIG (Transaction SIGnature) authenticates and protects the integrity of server-to-server messages—zone transfers, dynamic updates—using a shared key. Where DNSSEC signs the zone data itself, TSIG protects individual transaction messages.
• DANE (DNS-based Authentication of Named Entities) publishes TLS certificate information in DNS (a TLSA record), reinforcing certificate validity via a path protected by DNSSEC.

Think of hardening as two layers working together: one that limits damage if something breaks, and one that detects forgery in the first place. On the infrastructure side, running named inside a chroot (e.g. /var/named/chroot/) prevents a compromised process from reaching the real filesystem even if a vulnerability is exploited. Pair this with restricting forwarders in named.conf—e.g. forwarders { 192.0.2.53; };—to trusted internal or upstream servers only, disallowing recursion to arbitrary external servers. On the protocol side, the standard flow is signing a zone: generate a zone-signing key (ZSK) and key-signing key (KSK) with dnssec-keygen, then apply signatures with dnssec-signzone, producing a signed zone file with added DNSKEY, RRSIG, NSEC, and similar records. This lets resolvers verify response signatures and detect in-path tampering, including cache poisoning. For zone transfers and dynamic updates between primary and secondary, configure a TSIG shared key to confirm, message by message, that communication comes from a legitimate server. Finally, binding a PKI certificate to DNS via DANE (a TLSA record) reinforces, through a DNSSEC-protected path, that a certificate really belongs to its legitimate issuer—defense in depth that does not rely solely on certificate authority trust.

2.3.3Section summary

• Infrastructure: chroot (limits reach) / restricted forwarders (limits recursive targets)
• DNSSEC = zone signing/validation (dnssec-keygen then dnssec-signzone) / TSIG = key-based server-to-server authentication / DANE = reinforces certificates via DNSSEC