Two jobs: authoritative and recursive
Build a complete DNS service on Debian with PowerDNS: authoritative primary and secondary servers with NOTIFY and AXFR, zones by pdnsutil and the HTTP API, DNSSEC signed all the way from a lab root, and a validating recursor for the office.
By the end you will be able to:
- Explain why authoritative and recursive DNS belong on separate servers
- Run a PowerDNS Authoritative Server with a SQLite backend, and manage zones with pdnsutil and the HTTP API
- Replicate zones to a secondary with NOTIFY and AXFR, and fix the common reasons it doesn't happen
- Sign zones with DNSSEC and build the chain of trust with DS records
- Run a validating PowerDNS Recursor that forwards internal zones and serves only its own network
Prerequisites: Linux Network Connectivity
DNS servers do two completely different jobs, and the first rule of running DNS well is to never mix them on one server. PowerDNS makes that easy, because it ships them as two separate programs: the PowerDNS Authoritative Server and the PowerDNS Recursor. This lesson builds both on Debian 13, with a secondary server, DNSSEC and an API, and every output comes from a real lab.
- An authoritative server holds zones: the definitive records for names you own, like
example.net. It answers only for those zones, and refuses everything else. - A recursive resolver answers any question for its clients by asking other servers: the root, then a top-level domain (TLD) such as
net, then the zone's authoritative servers. It caches what it learns, and it should validate DNSSEC on its clients' behalf.
Why keep them apart
- Different audiences. Authoritative servers must answer the whole internet, but only about your zones. A resolver should answer only your own users, about anything. A server doing both either answers strangers' recursive queries (an open resolver, used for DNS amplification attacks and cache poisoning), or needs fiddly rules to tell the two apart.
- Different risks. A resolver's cache can be poisoned with forged answers. If the same server is authoritative for your zones, a poisoned cache can affect what the world sees for your own names.
- Different failures. A resolver chewing through a flood of lookups shouldn't take your public zones down with it, and an authoritative outage shouldn't stop your staff resolving the rest of the internet.
Old setups (BIND in particular) often did both in one process. PowerDNS's authoritative server can't recurse at all, which settles the argument.
The lab
The company owns example.net. Two authoritative servers, ns1 (primary) and ns2 (secondary), serve the public zone example.net, an internal zone internal.example.net, and the reverse zone for the office LAN. In the office, a recursor serves the staff's computers: it forwards the internal zones to ns1 and ns2, and resolves everything else from the root down, validating DNSSEC.
A Docker lab has no real internet, so the lab includes its own small root and net servers (named ns.root.test and ns.tld.test, using the reserved .test domain). They delegate example.net to ns1 and ns2 exactly as the real ones would, so recursion and the DNSSEC chain of trust work end to end.
- Clients only talk to the resolver. The office's computers send every question to the recursor. It answers from its cache, or goes and finds out.
- Start at the root. The recursor asks the root, which refers it to the net servers; net refers it to ns1 and ns2. (In the lab one server plays both parts.)
- Ask the authoritative server. ns1 (or ns2) answers for its own zone, with DNSSEC signatures that the recursor checks against the chain from the root.
- Internal names go straight to ns1 and ns2. internal.example.net isn't in public DNS, so the recursor forwards those questions directly to the company's servers.
- Keeping the secondary in step. When a zone changes, ns1 sends ns2 a NOTIFY; ns2 checks the serial and transfers the zone with AXFR.
- Strangers get nothing. The recursor only answers the office. A query from the internet is dropped without a reply, so it can't be used as an open resolver.
Check your understanding
Your company runs its public zone on two servers. Someone suggests also letting staff use them as their resolvers, to save a machine. What's the main problem?
- A server that recurses for clients and is authoritative for your zones mixes two audiences: it either answers the whole internet's recursive queries or needs fragile rules, and a poisoned cache can affect your own names.
- Authoritative servers can't store a cache.
- Resolvers can't do DNSSEC.
- It would double the zone transfer traffic.