If you have multiple DNS providers and want to configure NS1 authoritative DNS nameservers as secondary, you can create a secondary zone on the IBM NS1 Connect platform and update the nameserver delegation for the domain to include the assigned NS1 nameservers.
Secondary zones contain a read-only copy of the zone data that is kept updated by recurring zone transfers from the primary nameservers to the NS1 Connect platform. Since secondary zones inherit their records and configuration settings from the primary zone, the configuration options supported for secondary zones on the NS1 Connect platform are limited. For example, the only type of record you can create within a secondary zone is an ALIAS record, and key platform traffic steering features, like the Filter Chain, are not supported for secondary zones.
A secondary zone receives updates from the primary server based on the start of authority (SOA) refresh value defined in the primary zone. The SOA refresh value specifies the time between each request from the secondary to the primary server for new zone data. If the SOA refresh value is set to 43200 seconds, the secondary zone will request new data from the primary server every 12 hours.
The instructions below assume you have created the primary zone on your primary DNS provider, and that the primary servers are configured to receive incoming AXFR requests from the NS1 Connect platform. Refer to Configuring NS1 as a secondary DNS provider for details on the full configuration process when using multiple DNS providers with NS1 as the secondary.
Follow the instructions below to create a secondary zone, providing the IP addresses for one or more primary servers.
-
In the portal, go to DNS > Zones.
-
Click the + icon to create a new zone.
-
Under Domain name, enter the fully qualified domain name (FQDN) for the zone.
-
Select the DNS network(s) on which you want to publish the zone or de-select all networks to leave the zone unpublished.
-
Under Zone Settings, select Secondary zone.
-
Enter the Primary IP address corresponding to the primary DNS server.
-
Specify the port on which the primary server will receive incoming AXFR queries.
-
Select the NS1 network from which the SOA and AXFR queries will originate. To facilitate zone transfers, the network must be one of the DNS networks to which the zone is published—in other words, one of the networks selected above.
-
Optionally, you can specify multiple primary servers by including the corresponding IP address, port, and network (as described above) for each. The NS1 Connect platform will balance AXFR queries among all primary servers. If an AXFR query fails, the platform will attempt to query one of the other primary servers.
-
Optionally, select the Enable TSIG option to configure TSIG authentication on incoming zone transfers, and then enter the following:
-
TSIG hash - The cryptographic algorithm used to generate the TSIG key.
-
TSIG key name - Name of the TSIG key used in the domain name syntax. This must match what is configured on the primary server.
-
TSIG key value - The base64 string encoding the shared key secret. This must match what is configured on the primary server.
-
-
Click Save zone. The zone remains in a pending state until the first zone synchronization with the primary server is complete. You can monitor the server’s status on the Zone settings page. Once complete, all records configured on your primary server will appear on the NS1 platform.
-
To complete the primary/secondary configuration, add NS records to the primary zone specifying the hostnames of each NS1 nameserver assigned to the secondary zone. Refer to Locating assigned nameservers for help locating the nameservers, and then refer to the instructions provided by your primary DNS provider to add NS records to the primary zone.
Once complete, the zone is re-synchronized based on the SOA refresh. If the zone transfer fails, the secondary zone enters a “warning” state and NS1 will attempt to complete the zone transfer based on the retry interval until it is successful or until it reaches the expiry timeout. If the process exceeds the expiry timeout before NS1 can sync successfully, then the secondary zone enters an “error” state and the NS1 server responds to queries with zone data based on the last successful transfer.