Some progress, but still getting errors re: the auto-provisioning of the
superslave.
After modifying my pdns.conf to include
...
master=no
slave=yes
local-address=10.1.1.53
local-address-nonexist-fail=yes
local-port=15301
non-local-bind=no
allow-recursion=no
query-local-address=10.1.1.53
disable-axfr=no
allow-axfr-ips=10.1.1.53
allow-dnsupdate-from=10.1.1.53
allow-notify-from=10.1.1.53
slave-renotify=yes
allow-unsigned-notify=no
allow-unsigned-supermaster=no
...
and adding to the sqlite3 trigger statement
DROP TRIGGER IF EXISTS `domains_after_create`;
CREATE TRIGGER IF NOT EXISTS `domains_after_create`
AFTER INSERT ON `domains`
FOR EACH ROW WHEN NEW.`type` = 'SLAVE'
BEGIN
INSERT INTO `domainmetadata` (`domain_id`, `kind`, `content`)
VALUES (NEW.`id`, 'AXFR-MASTER-TSIG', 'pdns-key');
+ INSERT INTO `domainmetadata` (`domain_id`, `kind`, `content`)
VALUES (NEW.`id`, 'TSIG-ALLOW-AXFR', 'pdns-key');
END
;
.exit
it looks like the TSIG signing by pdns is working; as the *external* view data
is being accessed on the supermaster bind9 instance,
...
Dec 31 19:53:39 dns pdns[20210]: Remote 10.1.1.53 wants 'example.com|SOA',
do = 0, bufsize = 512: packetcache MISS
Dec 31 19:53:39 dns pdns[20210]: Query: select algorithm, secret from
tsigkeys where name=:key_name
Dec 31 19:53:39 dns pdns[20210]: Received secure NOTIFY for example.com
from 10.1.1.53, allowed by TSIG key 'pdns-key'
Dec 31 19:53:39 dns pdns[20210]: Query: select
id,name,master,last_check,notified_serial,type,account from domains where
name=:domain
Dec 31 19:53:39 dns pdns[20210]: Received NOTIFY for example.com from
10.1.1.53 for which we are not authoritative
Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters
where ip=:ip and nameserver=:nameserver
Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters
where ip=:ip and nameserver=:nameserver
Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters
where ip=:ip and nameserver=:nameserver
Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters
where ip=:ip and nameserver=:nameserver
Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters
where ip=:ip and nameserver=:nameserver
Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters
where ip=:ip and nameserver=:nameserver
Dec 31 19:53:40 dns pdns[20210]: Unable to find backend willing to host
example.com for potential supermaster 10.1.1.53. Remote nameservers:
Dec 31 19:53:40 dns pdns[20210]: ns1.MY-ISP.com
Dec 31 19:53:40 dns pdns[20210]: ns2.MY-ISP.com
Dec 31 19:53:40 dns pdns[20210]: ns3.MY-ISP.com
Dec 31 19:53:40 dns pdns[20210]: ns4.MY-ISP.com
Dec 31 19:53:40 dns pdns[20210]: ns5.MY-ISP.com
Dec 31 19:53:40 dns pdns[20210]: dnsext.example.net
Dec 31 19:53:40 dns pdns[20210]: Query: select id,name,master,last_check
from domains where type='SLAVE'
But, the
Unable to find backend willing to host example.com ...
error persists, and appears to be due (?) to a mismatch between the external
view's external NS records, for public nameservers
ns1.MY-ISP.com
ns2.MY-ISP.com
ns3.MY-ISP.com
ns4.MY-ISP.com
ns5.MY-ISP.com
dnsext.example.net
the zone's external view's SOA record,
dig -k /usr/local/etc/named/keys/pdns.key SOA example.com +all +short
dnsext.example.net. soacontact.example.net. 1483230865 7200 1800 604800
5
and the "potential supermaster"s internal/LAN IP,
10.1.1.53
What's required to convince pnds' superslave-capable gsqlite3 backend to be
"willing to host" the supermaster hidden primary instance?
_______________________________________________
Pdns-users mailing list
[email protected]
https://mailman.powerdns.com/mailman/listinfo/pdns-users
