DNS software should be selected by role and operational requirements, not by a universal “best server.” An authoritative service publishes zones; a recursive service answers clients by resolving and caching; a forwarding resolver sends queries to another resolver. Combining roles changes the attack surface.
DNS · Lesson 5
DNS Setup
Learn how to choose, secure, validate, and operate authoritative or recursive DNS services.
Choosing a Role and Implementation
- BIND can provide authoritative and recursive service with extensive standards support.
- Unbound is commonly deployed as a validating recursive resolver.
- dnsmasq provides lightweight forwarding, caching, and DHCP features for smaller controlled networks.
- PowerDNS offers separate authoritative and recursive products with several data backends.
Capabilities and packaging change, so consult the installed version's official documentation. Deploy only the role needed and disable unintended recursion or zone service.
Which role publishes definitive records for zones it serves?
Designing Before Installing
Define zones, clients, query volume, update mechanism, DNSSEC needs, logging, monitoring, backups, and recovery. Authoritative zones need redundant servers and correctly registered delegations. Recursive service needs explicit client access control, cache policy, upstream or iterative reachability, and protection against abuse.
Never expose unrestricted recursion to the Internet. Open resolvers can be abused for reflection attacks and consume local resources.
Why restrict recursive queries to authorized clients?
Validating Configuration and Zone Data
Use the implementation's syntax and zone-checking tools before reload. For BIND, common examples are:
$ named-checkconf
$ named-checkzone example.com /etc/bind/zones/db.example.com
Run with appropriate permissions and paths for the host. A parser success does not prove delegation, serial propagation, DNSSEC chain, firewall reachability, or correct answers, so follow with controlled queries.
What does a successful zone syntax check fail to prove?
Applying and Testing Safely
Preserve current configuration and recovery access, validate, then reload rather than restart when supported. Query each authoritative server directly with recursion disabled and compare SOA serial, NS set, positive records, nonexistent names, and both UDP and TCP behavior:
$ dig @192.0.2.53 example.com SOA +norecurse
$ dig @192.0.2.53 missing.example.com A +norecurse
$ dig @192.0.2.53 example.com SOA +norecurse +tcp
For recursion, test allowed and denied client networks, DNSSEC validation, cache behavior, and failure of upstream dependencies.
Why query an authoritative server with +norecurse?
Operating the Service
Monitor query failures, latency, cache behavior, resource use, zone transfers, serial consistency, DNSSEC expiry, and delegation health. Back up source configuration and signing material securely, but verify that a fresh instance can load zones and serve correct answers. Patch supported versions and limit control interfaces, dynamic updates, and transfer access.
What should authoritative DNS redundancy testing include?
Lesson complete
You finished DNS Setup
You can now design a DNS deployment around explicit authority or recursion roles.
Choose software only after defining the required role.
Restrict recursion and administrative interfaces.
Validate configuration and zones before reload.
Test authority, denial, transport, and client policy directly.
Monitor redundancy, DNSSEC, data consistency, and recovery.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account