PowerDNS secondary (slave) unable to AXFR zone after IP address change: client has no permission

Written by Claudio Kuenzler - 0 comments

Published on February 25th 2022 - Listed in PowerDNS DNS

---

After the IP address of a PowerDNS secondary server (old term: slave server) was changed, the zone transfers (AXFR), initiated by the secondary server, stopped working.

Note: For this article the real IP addresses of the involved DNS name servers are obviously anonymized. For the primary server, IP address 192.168.100.53 is used. For the secondary server, the new IP 192.168.200.53 is used (another IP address was used before).

How does DNS replication work in PowerDNS?

An article from 2019 (PowerDNS Master Slave DNS Replication with MySQL backend) explains in detail how the DNS replication works. But in a nutshell:

After changing a DNS zone on the primary server (old term: master server) the secondary DNS servers are notified. PowerDNS does look up the secondary server(s) dynamically by going through all the NS records of the modified zone.  After the secondary server(s) received the NOTIFY message about the changed zone, a domain transfer (AXFR) is initiated from the secondary server. The primary server receives the AXFR and, if the secondary server is allowed to, the zone is sent to the secondary server.

AXFR stopped working after IP change

After the IP address of the secondary server changed (using Opera DNS UI), zone transfers (AXFR) stopped working. After a change of a zone (example.com) on the primary server, the following logs showed up.

On the primary:

Feb 10 15:08:05 primary dnsui: client_ip=10.162.210.49;uid=claudio;zone=example.com.;object=rrset;action=add;name=dasdasdfasdf.example.com.
Feb 10 15:08:05 primary pdns_server[19977]: Queued notification of domain 'example.com' to 192.168.200.53:53
Feb 10 15:08:05 primary pdns_server[19977]: Queued notification of domain 'example.com' to 192.168.100.53:53
Feb 10 15:08:05 primary dnsui: client_ip=10.162.210.49;uid=claudio;zone=example.com.;object=zone;action=update;status=succeeded
Feb 10 15:08:05 primary pdns_server[19977]: Received NOTIFY for example.com from 192.168.100.53 but slave support is disabled in the configuration
Feb 10 15:08:06 primary pdns_server[19977]: AXFR of domain 'example.com' initiated by 192.168.200.53
Feb 10 15:08:06 primary pdns_server[19977]: AXFR of domain 'example.com' denied: client IP 192.168.200.53 has no permission
Feb 10 15:08:06 primary pdns_server[19977]: AXFR of domain 'example.com' failed: 192.168.200.53 cannot request AXFR
Feb 10 15:08:06 primary pdns_server[19977]: Removed from notification list: 'example.com' to 192.168.200.53:53 (was acknowledged)
Feb 10 15:08:06 primary pdns_server[19977]: Received unsuccessful notification report for 'example.com' from 192.168.100.53:53, error: Not Implemented
Feb 10 15:08:06 primary pdns_server[19977]: Removed from notification list: 'example.com' to 192.168.100.53:53 Not Implemented

On the secondary:

Feb 10 15:08:06 secondary pdns_server[1261]: Domain 'example.com' is stale, master serial 2022021004, our serial 2019101701
Feb 10 15:08:06 secondary pdns_server[1261]: Initiating transfer of 'example.com' from remote '192.168.100.53'
Feb 10 15:08:06 secondary pdns_server[1261]: Starting AXFR of 'example.com' from remote 192.168.100.53:53
Feb 10 15:08:06 secondary pdns_server[1261]: Unable to AXFR zone 'example.com' from remote '192.168.100.53' (resolver): AXFR chunk error: Server Not Authoritative for zone / Not Authorized

By only looking at the logs on the secondary server, the message ("Server Not Authoritative for zone") would make sense if the secondary's public NS record would still resolve to the previous IP address. However with dig, this can be verified:

$ dig -t A ns1.example.com +short
192.168.100.53
$ dig -t A ns2.example.com +short
192.168.200.53

Both records are up to date and the secondary (ns2.example.com) shows the new IP address.

But by looking at the primary logs, one message makes more sense and helps to understand where the problem might be: "AXFR of domain 'example.com' denied: client IP 192.168.200.53 has no permission".

Don't forget the allow-axfr configuration

Basically the PowerDNS primary server (NS1) says that an AXFR request was received and initiated by the slave server (NS2) from IP 192.168.200.53. But the zone transfer was denied, because client IP 192.168.200.53 has no permission. There could only be two reasons for that:

1. The IP address 192.168.200.53 is not part of any NS records in the zone (but dig above showed that ns2.example.com correctly resolves to this IP)
2. The IP address 192.168.200.53 is not listed in the allow-axfr configuration option

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.