Introducing redundancy to your infrastructure—leveraging multiple DNS providers—prevents a situation in which you have a single point of failure. NS1 customers can deploy either primary or secondary zone configurations in conjunction with other DNS providers.
For step-by-step instructions on how to set up a secondary zone in NS1, refer to the following article: Configuring NS1 as a secondary provider.
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.
Will intelligent routing configurations at my primary DNS provider transfer over to my NS1 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.
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}}'
Note
You cannot convert a zone from primary to secondary.
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.
Yes. NS1 supports TSIG authentication for zone transfers. You can enable TSIG when creating a secondary zone using a selection of hash algorithms, such as hmac-md5, hmac-sha1, sha224, etc.
Why am I getting a “superfluous name server listed at parent” error when running third-party zone consistency checks?
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
NS records for your primary provider, dns1.exmpl.prim.net, dns2.exmpl.prim.net, dns3.exmpl.prim.net, dns4.expl.prim.net,
as well as NS records from the secondary provider, dns1.pxx.nsone.net, dns2.pxx.nsone.net, dns3.pxx.nsone.net, dns4.pxx.nsone.net.
Update your registrar with the full list of nameservers, if applicable.