> On 1 Jan 2017, at 05:29, PGNet Dev <[email protected]> wrote: > [..] > ... > 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 [..] > 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 [..] > What's required to convince pnds' superslave-capable gsqlite3 backend to be > "willing to host" the supermaster hidden primary instance?
You need one row in your sqlite3 db which fulfils this query: > Dec 31 19:53:40 dns pdns[20210]: Query: select account from supermasters > where ip=:ip and nameserver=:nameserver So, inserting ip=10.1.1.53, nameserver=dnsext.example.net into supermasters should fix that. -ch -- Christian Hofstaedtler / Deduktiva GmbH (FN 418592 b, HG Wien) www.deduktiva.com / +43 1 353 1707 _______________________________________________ Pdns-users mailing list [email protected] https://mailman.powerdns.com/mailman/listinfo/pdns-users
