...
This feature is designed to increase availability of the DNS service by allowing multiple primaries for a zone. It will not increase overall throughput of DNS update traffic, as ultimately all updates must be replicated to (and processed by) all of the primaries.
When determining which appliances should act as primaries for the zone, consider that an additional SOA record will be required in the database for each primary. This will add to the overall record count for the zone, and each SOA will need to be updated for any change to the zone, which can impact performance.
Enable NTP for all members (at the member level) and ensure that their times are properly synchronized with their local time servers. Ensure that you select the "Exclude the Grid Master as an NTP server" option. The appliance selects the latest zone updates based on the timestamps the updates were made by clients to the primary servers. This is especially important when there are conflicts between two or more zone updates. For information about NTP, see Using NTP for Time Settings /wiki/spaces/nios90draft/pages/319652212.
When specifying the primary server for secondaries, you can choose to have the appliance automatically select it for you based on latency determination or you can manually specify it. When manually selecting a primary for zone updates, consider using one that is close in proximity to the secondary servers, which can result in better service performance. For information about setting preference for the primary server, see Adding Grid Secondaries below.
You can configure a default primary for DDNS updates to a zone with multiple primary servers. To enhance service performance, select a default primary that is close in proximity to the DHCP server that provides DDNS updates. This is especially useful if you have DHCP members that are located in different locations. You can configure a different default primary for each DHCP member based on their locations. For more information, see Defining the Default Primary for DDNS Updates to Zones with Multiple Primaries.
DNSSEC is not supported for zones with multiple primary servers. These zones must be unsigned. For information about DNSSEC, see Configuring DNSSEC.
When determining which appliances should act as primaries for the zone, consider that an additional SOA record will be required in the database for each primary. This will add to the overall record count for the zone, and each SOA will need to be updated for any change to the zone, which can impact performance.
...
Name: Enter a resolvable domain name for the external secondary server.
Address: Enter the IP address of the external secondary server.
Stealth: This setting applies only if the primary server is a Grid member or a Microsoft server. Click this checkbox to hide the NS record for the secondary name server from DNS queries. The NIOS appliance does not create an NS record for the secondary name server in the zone data. Select the checkbox again to display the NS record for the secondary name server in response to queries.
Note that to avoid an impact on your database performance, Infoblox recommends that you do not configure a large number of external secondary servers in stealth mode. To ensure that these secondary servers receive notifications about zone updates, you can allow zone transfers for these IP addresses and then enable the appliance to add them to the also-notify statement. For information about how to configure this feature, see Configuring Zone Transfers.
Use TSIG: To authenticate zone transfers between the local appliance and the external secondary server using a TSIG (transaction signature), select this checkbox. Infoblox TSIGs use HMAC-MD5 hashes. These are keyed one-way hashes for message authentication codes using the Message Digest 5 algorithm. For details, see RFC 1321, The MD5 Message-Digest Algorithm, and RFC 2104, HMAC: Keyed-Hashing for Message Authentication.
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as that of the TSIG key for this zone on the external secondary server.
Key: Type or paste a previously generated key. On the external secondary server, this key must also be present and associated with this zone. You can generate a TSIG key, or you can obtain the TSIG key name and key from the external name server, either by accessing the appliance yourself or by requesting the appliance administrator to deliver them to you through some out-of-band mechanism. Then, type or copy-and-paste the name and key into the appropriate fields.
Use 2.x TSIG: Select this checkbox to use TSIG authentication and the external secondary name server is a NIOS appliance running DNS One 2.x code. The local appliance generates the required TSIG key for authenticating DNS messages to and from appliances running DNS One 2.x code.
...