Series navigation
- Part 1: Deploy Recursor + Authoritative + PowerAdmin
- Part 2: Operations and troubleshooting
- Part 3 (this post): AXFR workflows and the BIND backend
Why AXFR still matters in internal DNS
Even when most zones are managed through a database-backed authoritative server and a UI, zone transfers are still relevant in internal networks:
- Inbound: receiving zones from an upstream master (PowerDNS as secondary)
- Outbound: serving zones to downstream systems (PowerDNS as primary)
Your authoritative configuration template includes settings to control transfers, such as allow-axfr-ips, allow-notify-from, and disable-axfr. Treat these settings as part of your normal hardening for internal DNS.
Enabling the BIND backend (zonefile interoperability)
PowerDNS can load BIND-style configuration via the bind backend. Your Ansible-managed snippet enables it and points to named.conf:
launch+=bind
bind-config=/etc/powerdns/named.confThis is useful when:
- you need to integrate with systems that still speak in terms of zone files
- you have workflows where zones are received or handled via transfer-driven processes
- you want a pragmatic interoperability path while still using a DB backend for most day-to-day management
Hardening transfers (practical baseline)
Use the authoritative configuration settings to restrict who can:
- request AXFR
- send NOTIFY
The template shows that allow-axfr-ips is the control point for zone transfers. In internal-only environments, this should be limited to:
- your known secondary servers
- your known upstream masters
- explicitly trusted management networks
Conclusion
AXFR is not “legacy”. In internal DNS, it is often the glue between systems. PowerDNS supports it well, and enabling the BIND backend provides an additional interoperability path when zonefile-centric workflows are required.
This wraps up the series.
All configuration files and scripts for this post are available here: https://git.spacewars.ch/blog/public