[Pdns-users] how to force pdns4 autoprovisioned superslave to be "willing to host" supermaster?

[PGNet Dev]

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?