Getting started with IBM NS1 Connect® (Managed DNS)

Once your account has been created, refer to the following implementation steps for guidance during initial setup and configuration.

Before you begin

  • Review other introductory content to learn more about fundamental concepts and components of the IBM® NS1 Connect® platform.
  • Explore the IBM NS1 Connect® portal to familiarize yourself with the navigation and general experience.
  • If interacting with the platform programmatically via the IBM NS1 Connect® API, create an API key in the portal to authenticate your requests. Be sure the API key is granted the correct permissions to perform the necessary tasks.
  • If other people in your organization are participating in the POC or initial implementation process, refer to these instructions for adding users to the account, granting each user the appropriate permissions based on individual roles and responsibilities.

1. Create or import your DNS zones

You can create zones manually or import a zone file exported from another DNS provider, selecting the Managed DNS network on which to publish the zone. All IBM NS1 Connect® accounts can publish DNS zones and record data to the Managed DNS network. The Managed DNS is a shared, anycast network with 26 points of presence (PoPs) distributed globally, providing fast, reliable, authoritative DNS service.

Note: Publishing the zone to a DNS network makes the data available on the NS1 authoritative nameservers but does not initiate traffic flow. After creating your zones and records, you must update the nameserver delegation at the domain registrar for recursive resolvers to find the zone data during a DNS lookup.

2. Add or review the DNS records in your zones

When you create a zone and publish it to a DNS network, a start of authority (SOA) record and a nameserver (NS) record are automatically created, as these are critical for the DNS to function correctly. Add other DNS records containing information specific to your application endpoints and services as a next step. For example, add an A or AAAA (address) record containing the IP addresses of your application host servers.

  • If you are configuring DNS resources manually, refer to Create a DNS record for instructions and the Guide to DNS record types for details about the function and configuration for each supported record type.
  • If you imported a zone file, review the DNS records created based on the zone file to ensure the configuration is as desired.

3. Configure monitors to track the health of your endpoints

Monitoring the health of your application endpoints and services is critical to an intelligent traffic steering strategy that responds quickly to network changes and trends. There are three types of monitoring data sources you can use to automate updates to answers on the IBM NS1 Connect® platform:

  • The IBM NS1 Connect® platform provides native monitoring tools to track an endpoint's up/down status. The four types of NS1 monitors (or probes): DNS, HTTP/S, PING (ICMP), and TCP. You can connect these monitoring feeds directly to answer metadata.
  • If you are already monitoring your endpoints using a third-party monitoring service, you can configure a data source from one of the supported monitoring integrations or use an API webhook to push collected data from your preferred service to the IBM NS1 Connect® platform. After configuring the data source to establish the connection between the two platforms, you must create data feeds corresponding to individual monitors on the third-party service and connect those to answers via the answer metadata. Refer to Third-party data sources for details.
  • If your plan includes the RUM-based traffic steering solution, you can use real user monitoring (RUM) data collected from active application users to inform traffic steering decisions. Refer to Creating RUM (Pulsar) applications and jobs for details. RUM applications and jobs function similarly to data sources and feeds, but they leverage real-time data to optimize distribution across complex, globally distributed networks.

4. Connect monitors or feeds to the corresponding DNS answers

After configuring data collection from your endpoints or pushing third-party data to the IBM NS1 Connect® platform, you must connect the data feeds to the corresponding DNS answers via the answer metadata. This configuration enables automatic updates. For example:

  • Connect an NS1 monitor or third-party data feed to the Up/down metadata field within the corresponding DNS answer(s). If the monitor detects the endpoint is "down," it will change the metadata field to "false" (as in, up=false). Refer to this topic for instructions.
  • If you are collecting more advanced metrics, such as load-related measurements, using a third-party source, you can connect the third-party data feed to the relevant metadata field to enable automatic updates. In some cases, you will also need to define low and high watermark metadata values depending on the traffic steering filters you implement. Refer to this topic for instructions.
  • For RUM-based traffic steering configurations, connect the corresponding job feed to the Pulsar data metadata field, adjusting the other metadata settings as desired. Refer to this topic for details and instructions.

Connect the corresponding NS1 monitors, third-party data feeds, or RUM job feeds to every answer in a DNS record for which you plan to apply a Filter Chain.

5. Configure a Filter Chain

The Filter Chain enables advanced traffic steering technology to control and optimize traffic distribution across redundant application endpoints and services specified within a DNS record. Depending on the metrics that matter most, you can select from various traffic steering filters—combining and rearranging them to generate a custom routing logic. When the DNS record is queried, the list of answers is passed through each filter in the Filter Chain, from top to bottom, as each filter applies a unique processing method to either rearrange or eliminate answers based on some condition.

Refer to this topic to learn more about the Filter Chain and the topics in this section to learn more about the different types of traffic steering filters.

For quick reference, the Filter Chain configurations below represent common use cases we recommend using as you familiarize yourself with the different filter types. Note that the order of filters in the Filter Chain is important as answers are processed from top to bottom.

Up filter + Priority filter + Select First N filter
This Filter Chain supports automatic failover in an active-passive configuration, meaning one endpoint should take priority over others. If using this configuration, connect monitors to the Up/down metadata field for automatic updates and manually assign a priority value in the metadata for each (lower value = higher priority). When the record is queried, all down answers are eliminated, the list is rearranged in priority order, and all but the first answer in the prioritized list is eliminated before responding to the requesting client. Refer to Automatic failover for details.

Required answer metadata field(s): Up/down, Priority

Up filter + Shuffle filter + Select First N filter
Similar to above, this configuration also supports automatic failover—except, as part of an active-active configuration where all endpoints are equal. The Shuffle filter randomizes the answer list to avoid sending all traffic to a single endpoint. Refer to Automatic failover for details.

Required answer metadata field(s): Up/down

Up filter + (Geographic filter) + Select First N filter
Using one of the geographic filters in a Filter Chain allows you to direct requesting clients to the nearest available endpoint or for geofencing, where answers are eliminated based on the requester's location. Geographic filters function best when the EDNS client subnet (ECS) extension is enabled within the Filter Chain configuration and supported by the resolver. Refer to this topic to learn more about the geographic-based filters.

Required answer metadata field(s): Up/down, geolocation metadata (specific field varies depending on the filter you choose)

Up filter + Shed Load filter + Select First N filter
This Filter Chain supports an automatic load-shedding configuration based on load-related measurements collected by a third-party monitoring service and pushed to the IBM NS1 Connect® platform. Refer to Automatic load shedding for details.

Required answer metadata field(s): Up/down, load-related metadata (either load average, active requests, or active connections)

6. Update the nameserver delegation at the domain registrar

Once the zones and records are configured, you can update the nameserver delegation at the domain registrar to initiate traffic flow to the NS1 nameservers assigned to each zone. If preferred, you can wait until you've set up monitors and defined a traffic steering configuration before updating the delegation.

  • If the zones are published to the Managed DNS network, refer to Locating assigned nameservers to identify the hostnames for all nameservers assigned to an individual zone, and then follow the instructions provided by your domain registrar to update the nameserver delegation (NS record) to include all assigned NS1 nameservers.
  • If the zones are published to a Dedicated DNS network in addition to the standard Managed DNS network, refer to Getting started with Dedicated DNS for information about additional implementation steps and how to locate nameservers specific to that networks.

Next steps

  • Monitor incoming traffic behavior based on the query reports and traffic distribution maps, adjusting the configuration settings as needed.
  • Explore alternative or more advanced Filter Chain configurations based on your organization's traffic steering objectives.
  • Set up notifications related to NS1 monitors to be notified when a monitor status changes and account usage limits if you are approaching or have reached the maximum queries, records, Filter Chains, or monitors permitted for your organization's account.
  • If not already included in your plan, explore solutions like Dedicated DNS for network resiliency, RUM-based traffic steering for global server load balancing (GSLB) across complex networks, or DNS Insights for advanced observability into your DNS networks and traffic steering behavior.