Fix PowerDNS AXFR TSIG and Autoprimary NOTIFY Errors
Published: 30 Aug, 2026

blog_nzuUavOGIKD9vdIP-7SAoQY_thumb.jpg

When operating a hybrid authoritative DNS architecture where BIND9 or an external appliance acts as the primary (master) and PowerDNS Authoritative Server functions as a secondary (slave), zone synchronization frequently breaks down at the AXFR transaction layer. Two primary failure modes dominate production environments: rejected NOTIFY packets that yield silent synchronization stalls, and cryptographic verification drops producing TSIG signature validation failure (BADKEY or BADSIG).

Symptom Analysis: Logs and Packet Dissections

PowerDNS running with the Generic MySQL (gmysql) or PostgreSQL (gpgsql) backend handles inbound zone provisioning either via explicit slave domains or dynamically through the autoprimary (formerly supermaster) mechanism. When an upstream master issues a NOTIFY query after updating a SOA serial, PowerDNS inspects its local metadata and permissions.

If the configuration or database records contain mismatches, systemd-journald or /var/log/messages reports errors similar to the following:

pdns_server[21450]: Received NOTIFY for example.com from 198.51.100.10:53 which is not an autoprimary
pdns_server[21450]: Packet for 'example.com' denied: TSIG signature validation failure (BADKEY)
pdns_server[21450]: Unable to AXFR zone 'example.com' from remote 198.51.100.10: AXFR-retrieval failed: Packet received has answer section with size 0

At the network layer, a tcpdump capture shows the immediate rejection:

tcpdump -nn -i eth0 'port 53 and host 198.51.100.10' -vv
# Primary -> PowerDNS: DNS NOTIFY example.com (with TSIG)
# PowerDNS -> Primary: DNS NOTIFY Response: REFUSED or NOTAUTH

Resolving Autoprimary / Supermaster Provisioning Failures

When using automatic zone creation, PowerDNS verifies the incoming notification against the autoprimaries table (PowerDNS 4.5+) or the legacy supermasters table. If the source IP or the associated account name fails strict lookup, the packet is dropped with REFUSED.

1. Populate the Autoprimary Metadata

Verify that your PowerDNS backend contains the exact source IP of the primary nameserver. Note that if the primary utilizes a non-standard egress interface or an IPv6 multi-homed endpoint, that explicit source address must be registered.

-- For PowerDNS 4.5+ schema
INSERT INTO autoprimaries (ip, nameserver, account)
VALUES ('198.51.100.10', 'ns1.primary-provider.net', 'core-zones');

-- For legacy schemas (PowerDNS < 4.5)
INSERT INTO supermasters (ip, nameserver, account)
VALUES ('198.51.100.10', 'ns1.primary-provider.net', 'core-zones');

2. Verify pdns.conf Slave Directives

Ensure that PowerDNS is explicitly instructed to process incoming notifications and run secondary replication threads. In /etc/powerdns/pdns.conf, verify the following configuration blocks:

# Enable secondary operation
secondary=yes
# Deprecated alias for older versions:
# slave=yes

# Enable dynamic zone creation from trusted primaries
autosecondary=yes
# Deprecated alias for older versions:
# supermaster=yes

# Polling interval for stale slave zones (seconds)
slave-cycle-interval=60

Correcting TSIG Algorithm and Key Mismatches

Transaction Signatures (TSIG) protect AXFR requests against spoofing and unauthorized zone exfiltration. When a TSIG error occurs, the primary and secondary typically disagree on either the secret digest, the key identifier, or the cryptographic algorithm name format.

SettingBIND9 (named.conf)PowerDNS (SQL Backend)
Algorithm Naminghmac-sha256;hmac-sha256
Key Name Syntaxaxfr-key.example.com.axfr-key.example.com (FQDN format must match)
Secret StringBase64 encoded stringBase64 encoded string

1. Import the TSIG Key into PowerDNS

Use the administrative utility pdnsutil to manage TSIG records directly in the backend storage engine:

pdnsutil import-tsig-key axfr-backup-key hmac-sha256 "k7w8JzPzK3x9U...base64-secret...="

Confirm the key is registered and valid:

pdnsutil list-tsig-keys

2. Bind the TSIG Key to the Target Domain Metadata

For existing domains that fail to transfer via authenticated AXFR, link the imported TSIG key to the specific zone using domain metadata:

pdnsutil set-meta example.com AXFR-TSIG-KEY axfr-backup-key
pdnsutil set-meta example.com TSIG-ALLOW-AXFR axfr-backup-key

If the domain is provisioned via the domains database table directly, verify that the master column specifies the remote IP address, and confirm the metadata linkage with:

pdnsutil get-meta example.com

End-to-End AXFR Debugging Command Sequence

To isolate network path MTU truncations, firewall states, and cryptographic handshakes manually, initiate a direct AXFR query from the PowerDNS host to the primary using dig with the TSIG key parameters:

dig @198.51.100.10 example.com AXFR -y hmac-sha256:axfr-backup-key:"k7w8JzPzK3x9U...base64-secret...="

If the raw AXFR transfer succeeds via dig but PowerDNS still refuses the automated transfer, force an immediate internal retrieval cycle using pdns_control:

pdns_control retrieve example.com

Monitor the live daemon activity to observe the transactional state changes:

journalctl -u pdns -f -n 50

Once authenticated, PowerDNS updates the SOA serial in the records table, resets the retry timers, and commits the incoming RRsets within a single atomic database transaction.