For the test and purpose you’re describing you do not need the External DNS feature. As you describe it, you only need to list the IPs puck.nether.net provides you as their DNS servers as secondary name servers on the Custom DNS page in MiaB. Doing that will cause NSD (MiaB’s name server) to notify them all when there is any change and they will in turn request a transfer from your server. That’s all automated and catered for in the normal flow of things related to DNS.
Some DNS providers give you a list of name server names to publish in addition to your own and also a list of IP’s to notify and allow transfers to. You’re suppose to specify all of them on your Custom DNS page as additional servers. Those with names you specify by name (MiaB will resolve their IPs and do the honours, but the names will be added to the zone file as additional name servers) and additional IP specified by your DNS provider goes onto the list using the xfr: notation which results in the IP getting notifications and being allowed to ask for transfers, but not getting listed as a name server. The DNS protocols and conventions makes full provision for primary and secondary servers, the mechanisms to validate who’s allowed to request aone transfers and what triggers those transfers. So even though you’re using a secondary DNS service that is external to MiaB, none of what you set up on the Custom DNS page involves what MiaB calls External DNS.
The MiaB term External DNS is a slightly different story primarily for when your hosting environment makes it impossible or undesirable to expoe MiaB as your primary name server because it isn’t reachable on TCP/UDP port 53 from the Internet. In that case you are instructed to manually take the zone file MiaB produced and feed that to a public DNS provider who then serves as master for your zone.
That’'s the important distinction. While MiaB is reachable (at least most of the time) for DNS queries and you’re happy or it to serve as master server for your zones any other servers you may elect to involve are simply secondary servers and there is no External DNS involved. The moment MiaB is no longer master for your zone `(i.e. the active SOA record you get when querying the zone from the internet does not specify ns1.box.yourdomain.tld as master for the domain and ns1.box adn ns2.box is not listed as NS records for the domain) then you’re having an External DNS situation.
I’ve noticed that some MiaB users that are using External DNS didn’t really notice that when they give the zone file to their external DNS provider, that provider will not allow you to specify your own SOA and NS records for the domain (or simply ignore those in the zone file) because they would specify their own. By implication, when you’re using External DNS, i.e. when you’ve downloaded zone files and/or transferred the records onthe External DNS page one-by-one to another DNS provider, then as far as MiaB is concerned it is happily carrying on as if it is the master for the zones except that nobody seems to be quering it on TCP/UDP port 53.
Like I said, that is quite a different scenario to what you’re describing as what and why you’re testing External DNS. At the moment it seems there are far fewer people having any trouble with manual External DNS than I though might be the case because MiaB never or rarely changes the DNS records it produces for any new zone. Largely, when you’ve set up a zone in MiaB, taken the downloaded zone file to your DNS provider, you don;t have to think about it again. Not until you introduce a new domain or make changes to the Custom DNS records that are also included in your zone.
For your casse, which is simply adding additional DNS servers as one or more secondaries, I cannot predict what improvement you can expect as a result in terms of failover and performance as per your reasoning. I’d be surprised if it’s substantial because your own server remains in the mix so will get its fair share of queries to respond to (actually double it’s fair share because by default it is listed twice as nameserver, as ns1.box.yourdomain.tld and ns2.box.yourdomain.tld) so any addditional servers will impove things statistically from there but won’t change the uptime of your box. So if your box is down it can’t accept email anyway. The good news is that the email protocols are patient and will retry many times before even reporting a problem. When your MiaB server is also involved in resolving other names to IP addresses served through load balancers to highly available clusters of machines it quickly becomes a SPoF in access to that web site and neither browsers nor apps nor the people who you them online can be mistaken for patient. MiaB is designed to serve mail purposes exclusively. When your use case involves a web site which outlives the box MiaB is running on you have to accept that you no longer fit within the target audience for MiaB and have to arrange for your own alternatives. I chose to do that by keeping MiaB believing it’s the master of my DNS domains but implementing an out of band mechanism to automate the changes I make in MiaB with regards to Custom DNS records. For me that’s the best of both worlds and at the moment it seems that I am the only one with that use case.