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 interprets a list of DNS answers as the 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):
- 220.127.116.11 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 data center or some other east coast facility.)
- 18.104.22.168 with "Up" set to true and "Geographic region" set to US-WEST.
(Let's say this is a server in some west coast facility.)
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 22.214.171.124. 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 [126.96.36.199, 188.8.131.52].
- The UP filter executes first. It examines the up/down metadata field for 184.108.40.206, and then for 220.127.116.11. If either is marked down, the answer is removed from the list. (If all answers are marked down, the UP filter is skipped completely so as not to eliminate all answers.)
- The resulting list from the up filter is passed to the Geotarget Regional filter. This filter looks up the requester's IP address ( 18.104.22.168) in a GeoIP database. If they're in California, for example, the filter goes through the current list of answers and computes the 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 22.214.171.124 is 0. The distance between the requester and 126.96.36.199 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: [188.8.131.52, 184.108.40.206] 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 Filter Chain is configured with N=1, so we choose the first answer, 220.127.116.11, and ignore 18.104.22.168.
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 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.
NS1 has a growing collection of filter algorithms. You can mix and match any of them together to pull off traffic management algorithms perfectly tailored to your application.