You can configure IBM NS1 Connect to be secondary to alternative DNS providers by creating a secondary zone and specifying the IP address(es) of the primary servers. A copy of the zone file is stored on NS1 nameservers, making it available if the primary DNS servers cannot be reached.
A secondary zone receives updates from the primary server based on the start of authority (SOA) refresh value defined in the primary zone. SOA refresh is the amount of 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, then the secondary zone will request new data from the primary server every 12 hours.
Typically, you can automate DNS notifications, or NOTIFY messages, from the primary to the secondary servers upon changes to the zone data. In response, the secondary server requests new zone data immediately instead of waiting for the end of the current SOA refresh interval.
The NS1 Connect platform supports two types of incoming zone transfers from a primary zone.
-
Authoritative transfers (AXFR) include the entire zone file.
-
Incremental transfers (IXFR) include only new or modified zone data.
Secondary zones contain a read-only copy of the primary zone data, so secondary zone configuration options are limited. The only record that you can add to a secondary zone directly in the NS1 Connect platform is an ALIAS record which provides CNAME-like functionality at the zone apex. Key traffic steering features like the Filter Chain are also not supported for secondary zones.
The following configuration options are available for secondary zones:
-
Support for publishing to multiple NS1 DNS networks
-
Support for multiple primary servers.
-
Support for TSIG authentication for incoming zone transfers.
-
Support for DNSSEC on incoming zone transfers in which an NSEC or NSEC3 record is used to prove non-existence.
-
Support for ALIAS record for CNAME-like functionality at the secondary zone apex.
-
Support for outgoing zone transfers to additional secondaries. This type of configuration is useful for creating redundancy in public DNS by using a "hidden primary" whereby the source of truth does not serve public traffic directly. Note that ALIAS records and other NS1-specific features are not included in outgoing zone transfers.
-
Support for converting a secondary zone to a primary zone.
The steps below outline the process for configuring IBM NS1 Connect to be the secondary DNS provider for your domain.
Refer to the instructions provided by your primary DNS provider to enable the primary servers to receive incoming AXFR queries over TCP and SOA queries over UDP from the NS1 Connect XFR server. For reference, if your primary were on the NS1 Connect platform, you would complete this step by configuring an outgoing zone transfer in the primary zone settings.
-
For secondary zones published to the shared Managed DNS network (network 0), the XFR server IP address is 192.135.223.10.
-
For secondary zones published to any other network, the correct IP address will be provided to you during the initial setup.
Follow the instructions below to create a secondary zone, providing the IP addresses for one or more primary servers.
-
In the NS1 Connect portal, go to DNS > Zones.
-
Click the + icon to create a new zone.
-
Enter the fully qualified Domain name (FQDN) for the secondary zone.
-
Select the DNS network(s) on which you want to publish the zone. You can deselect 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 AXFR queries will originate. The network must be one of the DNS 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.
Once saved, the secondary zone is created in a “pending” state. It may take a few minutes for the first synchronization with your primary server. You can monitor the server’s status under the Zone Settings tab. Once complete, all records configured on your primary server will appear on the NS1 platform.
In order to enable traffic flow through NS1 servers, you must add the NS1 nameservers to the NS record within the primary zone.
-
Locate the NS1 nameservers assigned to the secondary zone. You can do this via the portal or API.
-
Using the configuration tools provided by your primary DNS provider, add NS records to the primary zone for each NS1 nameserver.
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.