Zone transfer between PowerDNS and Bind9
I have a problem when trying to transfer a full zone from a PowerDNS server to a Bind9 one. The weird part is that there are several zones on the PowerDNS server which serves as a hidden master (with a MySQL backend) but only one zone is failing to be transfered to the Bind9 server.
The two servers are running Ubuntu 16.04 LTS. With:
- Bind9 version = 9.10.3.dfsg.P4-8ubuntu1
- PowerDNS version = 4.0.0~alpha2-3build1
The Bind9 slave zone is configured like this:
zone "example.net" {
type slave;
file "/var/lib/bind/slaves/db.example.net";
masters {
10.0.0.1;
};
};
And the DNS zone from PowerDNS is:
% sudo pdnsutil show-zone example.net
This is a Master zone
Last SOA serial number we notified: 2016050801 == 2016050801 (serial in the database)
Zone is not actively secured
Metadata items: None
No keys for zone 'example.net.'.
% sudo pdnsutil list-zone example.net
example.net. 10800 IN MX 10 mx1.example.org.
example.net. 10800 IN MX 50 mx2.example.org.
example.net. 10800 IN NS ns1.example.org.
example.net. 10800 IN NS ns2.example.org.
example.net. 86400 IN SOA ns1.example.org. hostmaster.example.org. 2016050801 28800 7200 604800 86400
...
Note the difference between .net and .org in this output. And here is the PowerDNS output in the log while trying to provide the zone to Bind.
May 9 00:44:14 hdns01 pdns[40494]: AXFR of domain 'example.net.' initiated by 10.0.0.2
May 9 00:44:14 hdns01 pdns[40494]: AXFR of domain 'example.net.' allowed: client IP 10.0.0.2 is in allow-axfr-ips
May 9 00:44:14 hdns01 pdns[40494]: AXFR of domain 'example.net.' failed: not authoritative
And the corresponding logs given by Bind.
May 9 00:44:14 rdns01 named[32973]: zone example.net/IN: refresh: unexpected rcode (REFUSED) from master 10.0.0.1#53 (source 0.0.0.0#0)
May 9 00:44:14 rdns01 named[32973]: zone example.net/IN: Transfer started.
May 9 00:44:14 rdns01 named[32973]: transfer of 'example.net/IN' from 10.0.0.1#53: connected using 10.0.0.2#55376
May 9 00:44:14 rdns01 named[32973]: transfer of 'example.net/IN' from 10.0.0.1#53: failed while receiving responses: NOTAUTH
May 9 00:44:14 rdns01 named[32973]: transfer of 'example.net/IN' from 10.0.0.1#53: Transfer status: NOTAUTH
May 9 00:44:14 rdns01 named[32973]: transfer of 'example.net/IN' from 10.0.0.1#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.004 secs (0 bytes/sec)
So Bind9 is saying that the server is not authoritative. That's weird. So lets use dig to make things a little bit clear.
% dig @10.0.0.1 example.net. SOA
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @10.0.0.1 example.net. SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47002
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;example.net. IN SOA
;; ANSWER SECTION:
example.net. 86400 IN SOA ns1.example.org. hostmaster.example.org. 2016050801 28800 7200 604800 86400
;; Query time: 2 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Mon May 09 00:53:51 CEST 2016
;; MSG SIZE rcvd: 104
Seems pretty authoritative to me. So after that I tried to do an AXFR with dig. And surprise it works...
% dig -t axfr example.net @10.0.0.1
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t axfr example.net @10.0.0.1
;; global options: +cmd
example.net. 86400 IN SOA ns1.example.org. hostmaster.example.org. 2016050801 28800 7200 604800 86400
...
;; Query time: 73 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Mon May 09 00:56:42 CEST 2016
;; XFR size: 58 records (messages 3, bytes 1952)
I don't know where to look anymore.
Thanks for your help.
UPDATE:
Logs from a packet capture:
1 0.000000 10.0.0.2 10.0.0.1 DNS 82 Standard query 0xe0dd SOA example.net OPT
2 0.002902 10.0.0.1 10.0.0.2 DNS 82 Standard query response 0xe0dd Refused SOA example.net OPT
6 0.004506 10.0.0.2 10.0.0.1 DNS 97 Standard query 0x205c AXFR example.net
8 0.006432 10.0.0.1 10.0.0.2 DNS 97 Standard query response 0x205c Not authoritative AXFR example.net
PowerDNS logs from a successful manual AXFR:
May 9 08:19:51 hdns01 pdns[40494]: AXFR of domain 'example.net.' initiated by 10.0.0.2
May 9 08:19:51 hdns01 pdns[40494]: AXFR of domain 'example.net.' allowed: client IP 10.0.0.2 is in allow-axfr-ips
May 9 08:19:52 hdns01 pdns[40494]: AXFR of domain 'example.net.' to 10.0.0.2 finished
PowerDNS config file:
#################################
# allow-axfr-ips Allow zonetransfers only to these subnets
#
allow-axfr-ips=127.0.0.0/8,::1,10.0.0.2
#################################
# also-notify When notifying a domain, also notify these nameservers
#
also-notify=10.20.1.78,10.0.0.2
#################################
# daemon Operate as a daemon
#
daemon=yes
#################################
# include-dir Include *.conf files from this directory
#
# include-dir=
include-dir=/etc/powerdns/pdns.d
#################################
# launch Which backends to launch and order to query them in
#
# launch=
launch=
#################################
# master Act as a master
#
master=yes
#################################
# setgid If set, change group id to this gid for more security
#
setgid=pdns
#################################
# setuid If set, change user id to this uid for more security
#
setuid=pdns
And the MySQL backend config part inside the /etc/powerdns/pdns.d/ directory.
# MySQL Configuration
#
# Launch gmysql backend
launch+=gmysql
# gmysql parameters
gmysql-host=127.0.0.1
gmysql-port=
gmysql-dbname=pdns
gmysql-user=MYUSER
gmysql-password=MYPASSWORD
gmysql-dnssec=yes
# gmysql-socket=
At my request the poster came into our #powerdns IRC channel, where we quickly figured out that there was actually a typo between the domain names on master and slave - hidden by the obfuscation that was done to ask the question here.
I'm guessing here, because you basically hid everything that was useful. Are you trying on purpose to make it hard to help you?
It looks like you have an example.net entry in your domains table, but under that domain_id in the records table, you put example.org records. pdnsutil check-all-zones (or pdnssec if you're on 3.x) will probably notice this for you.