NS1's Filter Chain technology allows you to easily make a series of decisions in real time for each DNS query so your users always receive the best possible answer. It is a configurable sequence of filters that are applied in real time—dynamically choosing the best answers for DNS queries.
When NS1 receives a DNS query, we first look up the list of potential answers, and then apply the filter chain to that list before serving an answer. Each filter takes a list of DNS answers as its input, performs a simple transformation (e.g. sorting by geographical proximity, or removing down answers), and then passes the modified list to the next filter in the chain. This allows you to implement complex decision-making logic very easily by chaining together simple, single-purpose components—similar to the Unix pipeline.
Here's an example. For simple content delivery networks (CDNs), a common filter chain configuration contains three filters in the following order:
- Up (true or false)
- Geotarget Regional, and
- Select First N (with N=1).
Suppose you have the following answers configured in an A record (say, geotarget.example.com):
- 188.8.131.52 with two metadata fields set: "Up" set to true and "Geographic region" set to US-EAST. (Let's say this server is in Digital Ocean's NYC2 datacenter or some other east coast facility.)
- 184.108.40.206 with "Up" set to true and "Geographic region" set to US-WEST.
(Let's say this is a server in some west coast facility.)
Note: You can also connect data feeds to each answer—say, from a monitoring service or NS1 monitoring tools—to connect the "up/down" metadata to health checks. Refer to this article about failover for more information.
Now, let's walk through the query resolution process:
Suppose a query arrives for geotarget.example.com from a DNS recursive resolver with IP address 220.127.116.11. Then the query is resolved as follows:
- NS1 loads the configuration for geotarget.example.com. It initiates the filter chain with an initial answer list like: [18.104.22.168, 22.214.171.124].
- The UP filter executes first. It examines the up/down metadata field for 126.96.36.199, and then for 188.8.131.52. If either is marked down, the answer is removed from the list. (If all answers are marked down, the UP filter does nothing as it is better to return some answer than none at all.)
- The resulting list from the up filter is passed to the Geotarget Regional filter. This filter looks up the requester's IP address ( 184.108.40.206) in a GeoIP database. If they're in California, for example, the filter goes through the current list of answers and computes distance between the requester and each answer—using the "Geographic region" metadata field. Since California is in the US-WEST region, the distance between the requester and 220.127.116.11 is 0. The distance between the requester and 18.104.22.168 is greater since the requester isn't in the US-EAST region. The filter sorts the answers by proximity to the requester—so, if both answers are up, then (in this example) what pops out of Geotarget Regional filter is a list like: [22.214.171.124, 126.96.36.199] reflecting proximity to the requester of each answer.
- Finally, we want to choose an answer to return to the requester. The SELECT_FIRST_N filter keeps the first N answers from the list, and discards the rest. The NS1 Filter Chain is configured with N=1, so we choose the first answer, 188.8.131.52, and ignore 184.108.40.206.
Users can use the Simulate Filters tool in the NS1 portal to preview the effects of various configurations for a specific record. For example:
This is a really basic example, but it generalizes well. If you add 220.127.116.11 in the "EUROPE" region, and 18.104.22.168 in the "ASIAPAC" region, the filter chain can remain the same and NS1 will select the "closest" server to the requester that is up.
If you have multiple servers in each of your data centers, it's useful to group them together using "regions" in the metadata. The filter chain resolves metadata by checking for the value of a field in the answer itself, and then the region (if any) to which the answer is assigned, and then in the metadata for the entire record. All of these metadata "tables" can be managed on the configuration page for the DNS record.
While the examples shown here are basic three-filter configurations, the NS1 Filter Chain is powerful and easy enough to pull off complex logic that, with many other DNS providers, usually requires a tangled collection of cascading record or is just impossible to execute.
NS1 has a growing collection of filter algorithms. You can mix and match any of them together into to pull off traffic management algorithms perfectly tailored to your application.