PowerDNS Security: Harden Authoritative, Recursor, dnsdist and APIs

A PowerDNS deployment holds the answers your users and customers trust, so the API key, the transfer and update ACLs, and the resolver's client list decide who can change or abuse those answers. This guide explains how to run the three PowerDNS products securely: the Authoritative Server, the Recursor and the dnsdist load balancer. It covers the REST API and its key, the built-in webservers, zone transfer and dynamic update controls, TSIG, DNSSEC keys, recursor client ACLs, the dnsdist console and webserver, logging, security polling and a hardening baseline with rollout steps. It is written for DNS engineers, platform teams and security engineers who operate PowerDNS for internal resolution, hosting or service-provider DNS. For the discipline as a whole see the DNS Security Guide; this page goes deeper on PowerDNS settings.

This is an independent guide from NHI Mgmt Group, based on PowerDNS's public documentation as of November 2026. It is not sponsored or reviewed by PowerDNS. Product features change, so confirm settings against PowerDNS's current documentation.

Key takeaways

• The API key is a zone-editing credential. On the Authoritative Server, api-key sent in the X-API-Key header can change any zone, so store it hashed (supported since 4.6.0), keep webserver-allow-from tight and treat every script that holds it as a machine identity.
• Defaults are local, keep them that way. The Authoritative webserver binds to 127.0.0.1:8081 with webserver-allow-from of 127.0.0.1 and ::1, and dnsdist's webserver and console accept loopback only. Widen only to named management hosts.
• Transfers and updates need explicit allow lists. Set allow-axfr-ips to your secondaries, sign transfers with TSIG, leave dnsupdate=no unless needed, and narrow allow-notify-from, which defaults to any address.
• The Recursor answers only the networks you list. incoming.allow_from defaults to loopback and private ranges and incoming.listen to loopback; an empty allow list allows every client, so never clear it on an internet-facing address.
• Run with least privilege and watch security status. Use setuid and setgid or systemd containment, give the database user SELECT where possible, and alert on the security-status metric that security polling populates.

How identity and access work in PowerDNS

PowerDNS has no user directory of its own. Access is decided by three kinds of control, and each product uses a different mix:

The practical consequence is that every PowerDNS secret is a non-human credential: there is no per-person login to audit, so the controls are which hosts may connect, which secret they present and where that secret lives. Front ends and automation (provisioning tools, hosting panels, ACME DNS-01 clients, Kubernetes ExternalDNS) usually authenticate with the same Authoritative API key. Inventory them, give each an owner and plan rotation. See the API Key Management Guide.

Admin roles and privileged access

Privileged access to PowerDNS comes from four places, and each needs its own control:

• Host and service account: anyone with root on the server can read pdns.conf and the backend database. PowerDNS's security page calls setuid and setgid highly recommended, so the daemon drops to a dedicated user (not nobody) after binding port 53. On systemd distributions the docs prefer the operating system's containment over chroot, which they note is not actively tested.
• Backend database: the documentation advises giving the database user only the privileges it needs, typically SELECT, never connecting as root or sa, and running the database on a separate machine. A write-capable account belongs to provisioning, not to the serving daemon, where your design allows it.
• pdnsutil and the control socket: pdnsutil manages zones, DNSSEC keys and TSIG keys (for example pdnsutil zone secure in 5.0 and later, pdnsutil secure-zone before). Limit who can run it with sudo rules and log its use.
• dnsdist console: controlSocket() plus setKey() gives full runtime control. dnsdist's documentation says enabling the console without encryption is not recommended, that setConsoleACL() defaults to 127.0.0.1, and that passing the key with -k on the command line leaks it into shell history. Generate the key with makeKey() and keep it in the configuration file with restricted permissions.

Our recommendation (NHI Mgmt Group): separate the person who can change DNS data (API or pdnsutil) from the person who can change server configuration, use named sudo accounts on the hosts, and route day-to-day zone changes through a reviewed pipeline that holds the API key, rather than handing the key to people. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Authoritative REST API

The API is enabled with api=yes and api-key in pdns.conf, and the key is sent in the X-API-Key header. Since 4.6.0 the key can be stored hashed and salted, produced with pdnsutil hash-password, and webserver-hash-plaintext-credentials (default no) hashes any plaintext password and key at start-up so plaintext is not held in memory, at some CPU cost per check. Apply these settings:

1. Generate a long random key and store only its hash in pdns.conf; keep the plaintext in your secrets manager for the clients that need it (see the Secrets Management Guide).
2. Keep webserver-address on a management interface (or a UNIX socket, from 5.0.0) and list only the automation hosts in webserver-allow-from (default 127.0.0.1,::1).
3. Set webserver-password as well; the docs note the webserver exposes sensitive process data such as frequent and failing queries and remote hosts.
4. Put a TLS-terminating reverse proxy in front if the API must cross a network, so the key never travels in clear text.
5. Rotate the key on a schedule and when anyone with access leaves. Our starting point is every 90 days, with a short overlap handled by updating clients first through your secrets manager.

Zone transfers, NOTIFY and dynamic updates

TSIG keys are imported with pdnsutil tsigkey import and bound to a zone with the TSIG-ALLOW-AXFR metadata on the primary and AXFR-MASTER-TSIG on the secondary, activated with pdnsutil tsigkey activate (5.0 and later). PowerDNS lists hmac-md5 as typical and also supports hmac-sha1 and hmac-sha224 to hmac-sha512; choose hmac-sha256 or stronger. Note the documentation's caution: any host with the correct TSIG key can transfer the zone even if its address is not in allow-axfr-ips, so a TSIG secret is a credential to protect and rotate.

DNSSEC keys

When a zone has a DNSSEC configuration, the Authoritative Server serves keys, signatures and denial-of-existence records automatically. Keying material is kept in separate tables from zone data, often in the same database, and PKCS#11 HSM storage is documented. Restrict read access to the key tables to the PowerDNS service account, back them up encrypted and consider an HSM for high-value zones. See the DNSSEC Deployment Guide.

Untrusted zone content

If customers upload zone files, PowerDNS's security page advises a low max-generate-steps, max-include-depth of 0 and enable-lua-records=no (the default), plus validation of TTLs, SOA values, delegations and record counts before loading.

Recursor and dnsdist access controls

From Recursor 5.2.0 YAML is the default configuration format, and old-style files need --enable-old-settings. The key settings:

• incoming.allow_from: defaults to loopback, RFC 1918, 100.64.0.0/10, link-local and IPv6 ULA ranges. The docs state an empty value allows all clients. List your own client networks; use incoming.allow_from_file for long lists.
• incoming.listen: defaults to 127.0.0.1 and ::1. Bind only to the interfaces clients use.
• dnssec.validation: defaults to process since 4.5.0. Move to validate once you have tested internal zones, so bogus answers are refused.
• Anti-spoofing: the Recursor randomises the UDP source port per query (RFC 5452) and retries over TCP when it sees too many near-miss answers, tunable with recursor.spoof_nearmiss_max.
• Webservice: webservice.api_key, webservice.password and webservice.allow_from follow the same rules as the Authoritative webserver.

dnsdist's client ACL applies to UDP, TCP, DNS over TLS and DNS over HTTPS and defaults to the same loopback and private ranges. Manage it with setACL(), addACL() and setACLFromFile(), and check it with showACL(). Its webserver accepts 127.0.0.1 and ::1 by default; set both password and apiKey in setWebserverConfig(), keep apiRequiresAuthentication, dashboardRequiresAuthentication and statsRequireAuthentication at their default of true, and call setAPIWritable() only where you need runtime ACL changes (which are not persisted across restarts). Keep the default security headers rather than removing them with customHeaders. For volumetric protection see the DDoS Protection Guide.

Logging and detection

The Authoritative Server logs to syslog at loglevel 4 by default (the docs advise not going below 3). log-dns-queries is for debugging only and needs loglevel 5 or higher; query-logging asks backends to log their queries. On the Recursor logging.quiet defaults to true, so queries are not logged. For query-level visibility at scale, use dnstap or protobuf export where your build supports it rather than text logging, and send it to the platform described in the DNS Logging and Detection Guide.

Metrics that show the controls are working:

• Instances with management webservers reachable only from listed hosts (target 100%).
• API keys stored hashed, with a named owner and a rotation date.
• Zones whose transfers are TSIG-signed with SHA-256 or stronger.
• Days with security-status above 1 before the upgrade is applied.
• Refused queries from non-client networks per day, trending flat or down.

Hardening baseline

1. Inventory: list every Authoritative, Recursor and dnsdist instance, version, listening address, webserver and console settings, and every client that holds an API key or TSIG secret.
2. Run as a dedicated user: set setuid and setgid and use your distribution's systemd unit containment.
3. Lock management interfaces: confirm webservers and the dnsdist console listen on loopback, a UNIX socket or a management network, with allow lists and passwords set and console encryption on.
4. Hash and vault secrets: move API keys to hashed form, put plaintext copies in a secrets manager and remove keys from shell history and scripts.
5. Close DNS-plane ACLs: set allow-axfr-ips, TSIG on every zone with secondaries, allow-notify-from and version-string; on recursors set incoming.allow_from and incoming.listen.
6. Turn on DNSSEC: sign zones in a pilot and move recursors to dnssec.validation: validate after testing.
7. Watch and patch: keep security polling on (default suffix secpoll.powerdns.com, or your own domain), alert on security-status, and apply vendor security updates promptly from the PowerDNS security advisories.

Testing and rollback: change one secondary or one recursor first and confirm resolution, transfers and API calls from each known client. Keep the previous configuration file and database dump so you can revert and restart within minutes. Apply ACL changes to dnsdist at runtime first (they are not persisted), confirm, then write them to the configuration file.

Small and large deployments: a single hosting server can reach a strong baseline with steps 2 to 5 in an afternoon. Service providers and enterprises should add configuration management for pdns.conf and recursor.conf, a separate database tier, an HSM for signing keys and central telemetry.

Framework mapping

Common misconfigurations

• Webserver widened without an allow list: moving webserver-address to a public interface for a dashboard. Keep webserver-allow-from to named hosts and add a password.
• Plaintext API key copied into many tools: the same key in a hosting panel, a CI job and an ACME client makes rotation hard. Issue keys through your secrets manager, store the hash in PowerDNS and keep an inventory of consumers.
• Transfers allowed by IP alone: addresses can change hands. Add TSIG with hmac-sha256 or stronger, and rotate the secret when a secondary is retired.
• Recursor allow list cleared during troubleshooting: an empty incoming.allow_from allows every client. Re-apply it from configuration management and alert on drift.
• dnsdist console key on the command line: the key ends up in shell history. Keep it in the protected configuration file.
• Security polling turned off: an empty security-poll-suffix removes the upgrade signal. Keep it on, or point it at your own mirror domain.

Practitioner checklist

• Inventory every PowerDNS instance, its role, version and management listeners.
• Store api-key hashed, set webserver-allow-from and webserver-password, and front remote API access with TLS.
• Record every API key and TSIG secret consumer with an owner and rotation date.
• Set allow-axfr-ips, TSIG on every transfer and a narrow allow-notify-from; keep dnsupdate=no unless required.
• Set incoming.allow_from and incoming.listen on every recursor and move to DNSSEC validation.
• Encrypt the dnsdist console, keep its ACL local and keep webserver authentication on.
• Run daemons with setuid/setgid and a least-privilege database account.
• Keep security polling on and alert on security-status.
• Ship logs and query telemetry to the SIEM and review refused transfers and API writes weekly.

Standards and references

• PowerDNS: Authoritative Server Security
• PowerDNS: Authoritative Server HTTP API
• PowerDNS: Authoritative Server Settings
• PowerDNS: TSIG
• PowerDNS: Recursor Security
• PowerDNS: Recursor YAML Settings
• dnsdist: Console
• dnsdist: Built-in Webserver

Related NHI Mgmt Group resources: DNS Security Guide · DNSSEC Deployment Guide · DNS Logging and Detection Guide · API Key Management Guide · Secrets Management Guide