FAQs: Secondary zones

Introducing redundancy to your infrastructure — leveraging multiple DNS providers — prevents a situation in which you have a single point of failure. You can deploy primary or secondary zone configurations to IBM® NS1 Connect® networks in conjunction with other DNS providers. This topic answers common FAQs related to the creation and management of secondary zones.

For step-by-step instructions on how to set up a secondary zone in NS1 Connect, refer to the following topic: Configuring NS1 Connect as a secondary DNS provider.

Are my secondary zones published to the NS1 Connect DNS network?
All zones, including secondary zones, are published to the Managed DNS network by default unless the option was deselected during zone creation or editing.
My secondary zone status reads Error: Unable to lookup SOA records. Why is the transfer failing?
There are a few reasons why your secondary zones transfer (AXFR) may fail: A common reason is forgetting to add our XFR node (192.135.223.10) to your primary DNS provider's allow list. If you do not do this, all SOA lookups from our XFR node fail, even if the primary IP provided is correct. Another reason is due to the record limitations defined in your subscription plan. The transfer fails if the number of records a zone file contains surpasses the total number of records permitted in your current plan. You can delete existing records to create space for the secondary zone or contact IBM support to request a limit increase.
Will intelligent routing configurations at my primary DNS provider transfer over to my NS1 Connect secondary zone?
AXFR does not support the transfer of advanced configurations, including features such as failover and GeoIP routing from your primary provider. While these features are available for primary zone configuration, any Filter Chain configurations, answer metadata and other details are removed when transferring between secondary zones.
Can I edit records in a secondary zone after it’s been configured?
Once configured, you cannot make record-level changes to secondary zones except for ALIAS records which can be added to the apex of a secondary zone hosted by NS1 Connect. ALIAS records provide CNAME-like functionality at the zone apex. All other changes must be made through the primary DNS provider after which the zone data is transferred to the NS1 Connect platform via AXFR.
How does NS1 Connect handle syncs without NOTIFY enabled?
The zone's serial number is updated with any changes made to the zone. When NOTIFY is enabled, all allowed secondary zones are notified and request the most recent zone file via AXFR. If NOTIFY is not configured, secondary zones will poll the primary zone for the most recent zone file based on the defined SOA refresh interval setting.
Can a secondary zone be converted to a primary zone?
Yes, refer to Converting a secondary to a primary zone for instructions. Alternatively, you can use the following POST request to convert using the API: 
curl -X POST -H "X-NSONE-Key: $NSONE_API_KEY" https://api.nsone.net/v1/zones/example.com -d '{"secondary":{"enabled":false}}'

Note that you must update the delegation at the domain registrar to complete the conversion.

Are there size limitations on zone files being transferred to NS1 Connect through AXFR?
While most zone transfers are done over TCP (to accommodate larger zone files), protections and soft limits are still in place to prevent malicious entities from importing a zone file with hundreds of thousands of records.
Does NS1 Connect support TSIG authentication for secondary zone transfers?
For incoming zone transfers from primary DNS providers to NS1 Connect, TSIG authentication is automatically supported. For outgoing zone transfers from NS1 Connect to secondary providers, NS1 Connect supports TSIG-signed notifications (NOTIFYs), not TSIG authentication on the actual zone transfer.
Why am I getting a superfluous nameserver listed at parent error when running third-party zone consistency checks?
Verify that you have correctly added the NS1 Connect name servers to the zone file at the primary DNS provider. The primary and secondary name servers should be included in the zone file and at the zone's registrar to ensure traffic is distributed according to your use case. For example, your zone should contain:
  • NS records for your primary provider, dns1.exmpl.prim.net, dns2.exmpl.prim.net, dns3.exmpl.prim.net, dns4.expl.prim.net,
  • NS records from the secondary provider, dns1.pxx.nsone.net, dns2.pxx.nsone.net, dns3.pxx.nsone.net, dns4.pxx.nsone.net.

Update the name server delegation at the domain registrar to include all name servers, if applicable.