FAQs: Understanding secondary zones

By default, when creating a secondary zone, the NS1 Managed DNS network option is enabled. Never disable this option unless you have an NS1 on-premises DDI network deployed with NS1. If you do have an on-premises DDI network with NS1, you must use the DDI portal to ensure your secondary zone is connected either to a dedicated or managed DNS network.

There are a few reasons as to why your secondary zones AXFR transfer may fail:

A common reason is forgetting to whitelist our XFR node (192.135.223.10) at your primary DNS provider. Without this step, all SOA lookups from our XFR node will fail even if the primary IP provided is correct.

Another reason is due to the record limitations defined in your subscription plan. If the number of records a zone file contains will surpass the total number of records permitted in your current plan, the transfer will fail. You can delete existing records to create space for the secondary zone, or you can contact support@ns1.com to request a limit increase.

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.

Once configured in the NS1 portal or API, you cannot make record-level changes to secondary zones. All changes must be made through the primary DNS provider. Changes made to the primary zones are transferred to the secondary zone via AXFR.

The zone's serial number is updated with any changes made to the zone. When NOTIFY is enabled, all whitelisted 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.

To convert a secondary zone to a primary zone (in other words, make NS1 your primary DNS provider), you can do so via API using the following cURL request:

curl -X POST -H 'X-NSONE-Key: $APIKEY' https://api.nsone.net/v1/zones/example.com -d '{"secondary":{"enabled":false}}'

While most zone transfers are done over TCP (to accommodate larger zone files), protections and soft limits are still in place to prevent malicious users from importing a zone file with hundreds of thousands of records.

NS1 supports TSIG authentication on zone transfers for secondary zones in Cloud-Managed DDI networks. You can enable TSIG when creating a secondary zone using a selection of hash algorithms, such as hmac-md5, hmac-sha1, sha224, etc.

For outgoing zone transfers, NS1 supports TSIG-signed NOTIFYs, not TSIG authentication on the actual zone transfer. For TSIG authentication on the zone transfer itself, you need to create a DNS view, add a TSIG Access Control List (ACL), and attach it to the zone. Currently, the NS1 DNS views functionality required to allow TSIG authentication is only available for zones in Cloud-Managed DDI networks. Managed DNS networks do not yet support DNS views; however, this is a future feature.

Verify that you have properly added the NS1 nameservers to the zone file at the primary DNS provider. Both the primary and secondary nameservers 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

Update your registrar with the full list of nameservers, if applicable.