Free tools Windows power users keep installed
One-click scans. No signup required.
To replicate a DNS zone with PowerDNS, configure the receiving server as a secondary, define each zone with its primary address or addresses, permit AXFR/IXFR and NOTIFY traffic, and authorize transfers on the primary. Secondary mode is disabled by default. Once the primary increments the SOA serial and sends NOTIFY, the secondary checks the zone and retrieves it; without NOTIFY, it discovers changes by polling the SOA record.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
PowerDNS now uses secondary terminology. The old slave setting was renamed in version 4.5.0 and removed in 4.9.0, although database rows may still accept the legacy SLAVE value for compatibility.
As an Amazon Associate I earn from qualifying purchases.
How PowerDNS secondary replication works
A PowerDNS secondary does not continuously copy a database. It obtains an authoritative copy of a zone from a primary using DNS zone-transfer protocols. A full transfer is AXFR; an incremental transfer is IXFR. The primary also sends DNS NOTIFY messages when the zone changes. NOTIFY prompts an immediate SOA freshness check, while normal SOA polling provides a fallback when a notification is delayed or unavailable.
The secondary stores the transferred zone through its configured backend and answers authoritatively for that zone. Replication therefore depends on four separate pieces working together:
#1 Best Overall
- Watchguard T145 Firebox with 1 Year Standard Support License (WGT145001) - The Firebox T145 delivers enterprise-grade protection for branch offices and retail sites. With a blend of 2.5Gb, 1Gb, and SFP/SFP+ ports, it supports high throughput, AI-driven malware protection, and DNS filtering for robust network defense.
- Standard Support covers software updates and round-the-clock emergency help. Add a Basic or Total Security Suite to activate IPS, gateway antivirus, and web filtering so threats are blocked before they reach users.
- Standard Support provides reliable technical assistance and software updates for WatchGuard Firebox appliances. Offering 24x7 help for emergencies and business-hours support for routine needs, it ensures your network stays secure and operational.
- Interfaces and deployment: 2.5Gb and 1Gb Ethernet with SFP or SFP+ fiber for clean aggregation and segmented backhaul at the edge.
- Performance and scale: UTM up to 710 Mbps with inspection on; flexible VPN topologies for hub and spoke or mesh designs.
- The selected backend must support primary or secondary operation and zone transfers.
- Secondary mode must be enabled in the PowerDNS server configuration.
- Each zone must identify its primary server or servers and use the correct secondary type.
- The primary must publish correct NS records and permit the secondary to transfer the zone.
PowerDNS can run both roles in one instance. Enable primary and secondary operation together only when that mixed topology is intentional and each zone has an unambiguous role.
Terminology and version differences
| Item | Current practice | Compatibility note |
|---|---|---|
| Server role | Primary and secondary | Older documentation often says master and slave. |
| Global setting | secondary=yes |
The slave setting was renamed in 4.5.0 and removed in 4.9.0. |
| SQL zone type | SECONDARY where supported |
Many installations still use SLAVE in the domains table. |
| Metadata command | pdnsutil metadata set |
Before version 5.0, the older set-meta spelling was used. |
Check the installed PowerDNS Authoritative Server release before copying examples. Configuration names, migration behavior, and supported backend operations can differ between releases.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Prerequisites before changing configuration
Confirm backend support
Not every PowerDNS backend implements primary and secondary operation. Confirm that the selected backend supports zone transfers before debugging NOTIFY, firewall, or TSIG settings. A backend that cannot create or consume transferred zones will not become a functioning secondary merely because a global option is enabled.
Collect the topology details
- The primary server’s IPv4 and IPv6 addresses.
- The secondary server’s authoritative nameserver name and addresses.
- The exact zone names to replicate, including whether they are forward or reverse zones.
- The service account used by PowerDNS and the location where the backend writes transferred data.
- Whether transfers are AXFR-only or should attempt IXFR, and whether TSIG authentication is required.
Plan serial handling
Every primary-side change must increase the zone’s SOA serial. A secondary compares serials; if the serial has not increased, it considers its copy current even if other records were edited. Make serial updates part of the primary’s normal zone-management process.
Step 1: enable secondary mode
Add the current secondary setting to the receiving server’s PowerDNS configuration, commonly /etc/powerdns/pdns.conf:
secondary=yesSecondary support is off by default. After editing, restart or reload PowerDNS using the service procedure appropriate for your deployment. Confirm in the startup log that the running process accepted the setting; an ignored or misspelled option leaves the server operating as a primary-only instance.
Step 2: define the zone on the secondary
SQL-backed deployments
In an SQL backend, the zone’s row in the domains table must identify it as a secondary and list the primary address or addresses in the master column. Conceptually, the record looks like this:
name = example.com
type = SLAVE (or the current SECONDARY representation)
master = 192.0.2.10[,198.51.100.10]The exact schema, backend name, and migration behavior are backend-specific. Use the supported PowerDNS utility, API, or documented database procedure for your release rather than assuming that an SQL statement from another backend is safe. Multiple primaries are represented as a comma-separated address list when the backend supports that form.
BIND-backend deployments
The BIND backend uses a supported BIND-style zone configuration. Mark the zone as secondary and specify the primary servers with the backend’s masters or primaries directive, according to the syntax supported by your installed release. Do not mix SQL domains rows with BIND-backend configuration assumptions: the representation is different even though both describe the same replication relationship.
Verify the zone role
Check that the zone name is spelled exactly, the role is secondary rather than native or primary, and every listed primary address is reachable from the secondary. A typo in the zone name creates a different zone; a wrong type prevents the transfer scheduler from treating it as a secondary zone.
Recommended Free Tools
Rank #2
- Watchguard T145 Firebox with 3 Year Total Security Suite License (WGT145643) - The Firebox T145 delivers enterprise-grade protection for branch offices and retail sites. With a blend of 2.5Gb, 1Gb, and SFP/SFP+ ports, it supports high throughput, AI-driven malware protection, and DNS filtering for robust network defense.
- The Total Security Suite is WatchGuard’s most comprehensive security package, bundling every advanced service into one subscription. It delivers layered defense with AI-driven malware detection, DNS filtering, cloud sandboxing, and security correlation. Ideal for organizations that demand maximum protection and visibility across their network.
- The Total Security Suite equips your WatchGuard Firebox with the full set of advanced defenses. It adds AI powered malware detection, DNS filtering, cloud sandboxing, threat correlation, and automated response, all managed in WatchGuard Cloud. Ideal for organizations that need maximum protection, compliance ready reporting, and end to end visibility.
- Interfaces and deployment: 2.5Gb and 1Gb Ethernet with SFP or SFP+ fiber for clean aggregation and segmented backhaul at the edge.
- Performance and scale: UTM up to 710 Mbps with inspection on; flexible VPN topologies for hub and spoke or mesh designs.
Step 3: configure the primary server
Allow the secondary to transfer
The primary must allow the secondary’s address to request AXFR and, if enabled, IXFR. Configure the primary’s transfer ACL or per-zone metadata to include the secondary. If a TSIG key is used, the ACL must authorize the matching key as well as, or instead of, an address-only rule.
Publish the secondary in the NS set
The zone’s NS RRset must contain the secondary nameserver name. The primary must also provide an A and/or AAAA record for that nameserver where required by the delegation and zone design. NS records are operational data: omitting the secondary can cause resolvers and administrators to overlook it, and PowerDNS’s setup requirements call for correct NS and address records for each secondary.
Increment the SOA serial and send NOTIFY
When the zone changes, increment the SOA serial and send NOTIFY to the secondary. NOTIFY is an acceleration mechanism, not a replacement for serial management. If a notification is lost, the secondary will eventually poll the primary’s SOA and retrieve a higher serial.
Step 4: permit DNS and transfer traffic
Network policy must permit the traffic used by the deployment:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall- DNS queries between the systems when the secondary performs SOA checks.
- TCP connections for AXFR and IXFR. Zone transfers use TCP even when ordinary DNS queries commonly use UDP.
- NOTIFY delivery from the primary to the secondary.
- Return traffic and any IPv6 path when primaries or secondaries use IPv6 addresses.
PowerDNS documentation defines the transfer and notification roles but does not prescribe one universal firewall syntax. Apply equivalent rules in host firewalls, cloud security groups, network ACLs, and any intermediate filtering device. Restrict transfer access to the intended secondary addresses or authenticated keys rather than opening transfer ports broadly.
Step 5: secure transfers with TSIG when required
Unauthenticated address-based ACLs may be adequate on a tightly controlled network, but TSIG adds cryptographic authentication to transfer requests and responses. Create the same named key and secret on both servers, protect the key file, and associate it with the zone.
Secondary-side metadata
Set the zone’s AXFR-MASTER-TSIG metadata to the key name. On current releases, the supported form is the pdnsutil metadata set operation; releases before version 5.0 used the older set-meta spelling. Use the command syntax documented for your installed version and verify the resulting per-zone metadata.
Primary-side authorization
Configure the primary’s transfer ACL or metadata to accept that TSIG key. The primary-side TSIG-ALLOW-AXFR control is relevant when transfers are restricted by key. A key name mismatch, different secret, wrong algorithm, or incorrect ACL produces a transfer refusal even when TCP connectivity is working.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose the AXFR source address when necessary
AXFR-SOURCE selects the source address used by the secondary for AXFR and IXFR requests. This is useful on multihomed hosts or networks whose ACLs expect a particular source address. Ensure that the chosen address is present on the host and routable to the primary.
Step 6: decide whether to use IXFR
AXFR transfers the complete zone. IXFR requests only the changes between serials when the primary can provide a suitable incremental history. To have a zone attempt IXFR retrieval, set its IXFR metadata to 1. If IXFR cannot be supplied or is unsuitable, the deployment may fall back to a full transfer.
Rank #3
- 4x Intel i226-V 2.5G LAN: Upgraded with 4 genuine Intel i226-V 2.5GbE ports, offering up to 2.5x faster throughput than standard gigabit. Delivers low latency, high stability, and native driver support for modern pfSense, OPNsense, OpenWrt, and Linux distributions.
- High-End Core i7 Powerhouse: Equipped with the premium Intel Core i7-4500U processor (4M Cache, up to 3.00 GHz), delivering maximum single-thread compute power and processing speed for deep packet inspection (IDS/IPS like Suricata/Snort), intensive VPN tunnels, and complex multi-device network management.
- Fanless Aluminum Silent Chassis: Engineered with a rugged aluminum alloy casing that acts as a passive heatsink. The 100% silent, fanless design eliminates dust buildup and moving-part failures, maximizing hardware longevity.
- Flexible Memory & Storage Storage: Features 1x DDR3L SO-DIMM RAM slot, 1x mSATA SSD slot, and 1x 2.5-inch SATA drive bay, allowing flexible expansion for extensive network logging, packet capturing, or caching.
- Industrial & Essential I/O: Equipped with 1x RS232 COM port for serial console access or industrial control, 1x HD Port for direct display output, and 4x USB ports, offering robust enterprise capabilities in a compact footprint.
PowerDNS can retrieve IXFR updates but cannot serve IXFR updates itself. Therefore, a PowerDNS server acting as a secondary cannot be assumed to provide incremental histories to downstream secondaries.
DNSSEC and NSEC3 caveat
Documentation warns that a transition from non-DNSSEC to DNSSEC, or a change in NSEC3 mode, may not be fully represented by IXFR. When such a transition leaves stale DNSSEC state, delete the secondary’s zone contents through the supported administrative process and force a fresh retrieval. Plan this as a controlled maintenance action because it temporarily removes the stored copy before AXFR repopulates it.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteStep 7: make transferred data writable
The secondary must be able to persist the zone through its backend. Packaged systemd units commonly use ProtectSystem=full, which can prevent writes under /etc or /home. A transfer may appear to start successfully yet fail to persist if the service account cannot write the backend files or destination directory.
- Identify the actual transfer destination used by the backend.
- Confirm ownership, group membership, mode bits, ACLs, and available space for the PowerDNS service account.
- Check systemd hardening settings, including
ProtectSystem, before changing directory permissions. - Prefer a writable state directory outside protected paths when the backend supports it.
- If hardening must be relaxed, document the narrow override and review it after package upgrades.
Do not make the entire filesystem writable as a quick fix. Adjust the deployment layout or the specific hardening policy deliberately.
Step 8: trigger and observe the first transfer
Use NOTIFY for normal updates
After the primary increments the SOA serial and sends NOTIFY, the secondary performs an immediate freshness check. A higher serial starts the configured transfer method. If NOTIFY is blocked, the secondary relies on periodic SOA polling.
Request an immediate retrieval
For a manual test or recovery, request retrieval with:
pdns_control retrieve <zone>Replace <zone> with the exact authoritative zone name. This command asks the running server to retrieve the zone immediately; it does not correct an invalid zone type, ACL, TSIG key, or firewall rule.
Check logs and the SOA serial
- Watch the PowerDNS service log while issuing the retrieval request.
- Look for the selected primary address, connection result, authentication result, transfer type, and write or backend errors.
- Query the secondary directly for the zone’s SOA record and record its serial.
- Query the primary for the same SOA serial and confirm that the secondary converges to the higher value.
- Repeat with a deliberate primary-side record change and serial increment to verify NOTIFY, not just the initial AXFR.
A successful DNS answer alone does not prove replication is current. Compare SOA serials and inspect transfer logs.
SQL and BIND backend choices
| Decision point | SQL backend | BIND backend |
|---|---|---|
| Where the secondary role is declared | Zone row in domains, using SLAVE or supported SECONDARY. |
BIND-style zone declaration with a secondary type. |
| Primary list | master column, commonly a comma-separated address list. |
masters or primaries directive supported by the backend. |
| Schema or syntax portability | SQL schema and migration are backend-specific. | Configuration syntax follows the supported BIND backend implementation. |
| Recommended administration | Use supported pdnsutil or API operations where available. |
Use the backend’s current configuration and reload procedure. |
Choose one representation that matches the active backend. Instructions written for a different backend can create a zone that exists in the database but is never scheduled for secondary transfers.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Single and multiple primaries
Single primary
A single primary is simplest to operate: the secondary checks one address, and transfer failures have one network and authorization path to investigate. It still requires a working NS design and a recovery plan if the primary is unavailable.
Rank #4
- 4x Intel i226-V 2.5G LAN: Upgraded with 4 genuine Intel i226-V 2.5GbE ports, offering up to 2.5x faster throughput than standard gigabit. Delivers low latency, high stability, and native driver support for modern pfSense, OPNsense, OpenWrt, and Linux distributions.
- Upgraded Turbo i5 Performance: Powered by the Intel Core i5-4200U processor (3M Cache, up to 2.60 GHz with Turbo Boost), providing enhanced multi-tasking capability and faster clock speeds to handle heavy cryptographic workloads, VPN routing, and basic virtualization.
- Fanless Aluminum Silent Chassis: Engineered with a rugged aluminum alloy casing that acts as a passive heatsink. The 100% silent, fanless design eliminates dust buildup and moving-part failures, maximizing hardware longevity.
- Flexible Memory & Storage Storage: Features 1x DDR3L SO-DIMM RAM slot, 1x mSATA SSD slot, and 1x 2.5-inch SATA drive bay, allowing flexible expansion for extensive network logging, packet capturing, or caching.
- Industrial & Essential I/O: Equipped with 1x RS232 COM port for serial console access or industrial control, 1x HD Port for direct display output, and 4x USB ports, offering robust enterprise capabilities in a compact footprint.
Multiple primaries
List multiple primary addresses in the backend’s supported format when the zone has more than one source. Confirm that all primaries serve the same zone, use compatible SOA serials, and authorize the secondary consistently. A reachable but stale or differently configured primary can make troubleshooting appear intermittent because the secondary may contact different sources.
AXFR, IXFR, NOTIFY, and polling compared
| Mechanism | Purpose | What to verify |
|---|---|---|
| AXFR | Complete zone transfer. | TCP reachability, transfer ACL, TSIG, and writable storage. |
| IXFR | Incremental retrieval of changes. | Per-zone IXFR metadata and a usable primary-side change history. |
| NOTIFY | Prompt freshness checking after a change. | Primary sends it, network policy permits it, and the secondary receives it. |
| SOA polling | Periodic detection when NOTIFY is absent or lost. | Secondary can query the primary and sees an increased serial. |
These mechanisms are complementary. NOTIFY does not carry the zone data; it tells the secondary to check. IXFR does not replace AXFR permanently; a full transfer remains necessary when no usable incremental history exists.
Troubleshooting by symptom
Secondary support disabled
Confirm that the active configuration contains secondary=yes, that the service was reloaded or restarted after the edit, and that the startup log shows the option being accepted. Check that you are editing the configuration file actually used by the running service.
No transfer after a zone change
- Query the primary’s SOA and verify that the serial increased.
- Confirm that the primary sent NOTIFY to the secondary address.
- Check that the secondary appears in the zone’s NS RRset with the correct A or AAAA record.
- Verify TCP transfer connectivity and the primary’s AXFR/IXFR ACL.
- Run
pdns_control retrieve <zone>and inspect the resulting log entries.
Transfer refused
Inspect the primary’s transfer ACL, the secondary’s source address, and any TSIG settings. With authenticated transfers, verify the key name, algorithm, secret, zone association, and the primary-side TSIG-ALLOW-AXFR policy. A DNS query path can work while the separate TCP transfer path is denied.
The zone is known but never persists
Check backend write permissions and systemd’s ProtectSystem=full. Confirm that the service account can create or update the actual zone storage location and that the filesystem is not full or mounted read-only.
IXFR leaves stale DNSSEC data
For a non-DNSSEC to DNSSEC transition or an NSEC3-mode change, force a fresh retrieval by removing the affected zone contents through the supported backend procedure, then trigger AXFR. Do not assume that repeating the same IXFR request will reconstruct metadata that the incremental stream did not represent.
A removed primary zone still answers on the secondary
This is expected. AXFR has no deletion operation. Removing a zone from the primary does not tell the secondary to delete its local copy. Retire the zone explicitly on the secondary through its supported backend or administrative cleanup process, then confirm that queries no longer receive an authoritative answer.
Only one of several primaries works
Compare the zone data, SOA serials, transfer ACLs, TSIG configuration, and routing for every listed primary. Ensure that each address is intended to serve the same zone and that the secondary’s source address is accepted by all of them.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Operational checklist
- Verify the backend supports secondary operation.
- Enable
secondary=yesand reload the correct service instance. - Define each zone with the secondary type and primary address list.
- Publish the secondary in the primary’s NS RRset and provide its A or AAAA record.
- Allow DNS, TCP AXFR/IXFR, and NOTIFY traffic between the systems.
- Configure matching TSIG metadata when transfer authentication is required.
- Set
IXFR=1only when incremental retrieval is appropriate for the deployment. - Ensure the backend’s transfer destination is writable despite systemd hardening.
- Test an immediate retrieval, then verify matching SOA serials.
- Document and perform explicit secondary cleanup when a zone is retired.
When to use a mixed-role PowerDNS instance
A single PowerDNS instance may be both primary and secondary when both capabilities are enabled. This can be useful in a topology where one server originates some zones and receives others. Separate the zone definitions clearly, apply transfer ACLs per zone, and monitor each role independently. Do not assume that enabling both roles changes the deletion behavior or lets the instance serve IXFR histories; the same protocol limitations still apply.
Final verification before production
Perform a complete change cycle rather than stopping after the first AXFR. Add or edit a harmless test record on the primary, increment the SOA serial, send NOTIFY, and confirm that the secondary retrieves the new serial and record. Then block or restore NOTIFY in a controlled test to verify that SOA polling eventually detects the change. Finally, test the documented cleanup procedure on a non-production zone so operators know how to remove a zone that has been deleted at the primary.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
