Building a Simple CDN with NS1

The goal of a Content Delivery Network, or CDN, is to get your static content located as close to your end users as possible—which typically involves distributing multiple copies of your content in locations that are likely to be near clusters or groups of users, so that speed is maximized when a user goes to access your content. While there are many CDN service providers, such as MaxCDN, Highwinds, and Fastly, it is possible to use NS1 DNS to run your own simple CDN and realize many of the benefits without the high cost of using a CDN like Akamai or Edgecast. Note that a CDN which contains static content is different than a dynamic content acceleration network, such as Teridion.

Building your own CDN basically consists of three parts:

  • Setting up an origin server and satellite servers
  • Establishing a copying mechanism to distribute content from the origin to the satellite servers
  • Routing users to the closest available satellite server

Depending upon budget, there are a number of excellent options for your origin and satellite servers, including HostVirtual and AWS.

The copying mechanism can be as simple as executing rsync from within a cron job.

And routing users to the closest available satellite server is equally easy with NS1. Let’s take a look at some Filter Chain combinations that will get the job done.

First, let’s build a basic record (we’ll call it with three answers for three different satellite servers, with located on the west coast of the United States, located on the east coast, and located in Europe:

We’re using regions here instead of more granular location tagging like states, countries, or even latitude and longitude because our CDN consists of only three servers. The more servers you have, the more granular you will want to get; for example, if you had many servers located throughout the United States you would want to use states instead of regions.

Next, we need to setup monitoring of each server, because we do not want to route a user to a server that is offline:

Here we can see that our west coast server,, is currently offline. Our other two servers are online and healthy.

Now let’s associate our three monitors with our three answers within the record:

And finally, to make the magic happen, let’s add the UP filter, the GEOTARGET_REGIONAL filter, and finally the SELECT_FIRST_N filter with the number of answers set to 1:

Now if we query this record from, say, California we will be routed to the closest server that is healthy and online:

$ dig
; <<>> DiG 9.10.2 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9079
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
; EDNS: version: 0, flags:; udp: 4096
;        IN    A
;; ANSWER SECTION:    3600    IN    A
;; Query time: 34 msec
;; WHEN: Thu May 26 15:41:41 PDT 2016
;; MSG SIZE  rcvd: 60

The big drawback here is that if a server is physically closest to a user does not mean that the server is the most performant: for example, there may be a connectivity problem to the data center in which the server resides, or that particular server might be extremely busy serving other requests. This situation can be vastly improved by using NS1 Pulsar to actually measure performance from each end user to each satellite server—and then route users to the most performant satellite server regardless of location:

If you have a specific home Internet connectivity provider (such as Comcast or Verizon) with a peering arrangement to a particular data center that contains one of your satellite servers, then you can selectively route users from that Internet provider to the preferred answer, again regardless of physical location. To do this, you would employ the NETFENCE_ASN filter to return a specific answer, or set of answers, to users coming from one or more specific Autonomous System Numbers (ASNs):

It’s even possible to use a GEOTARGET filter and the PULSAR filter to optimize answers from within a restricted set established by NETFENCE_ASN.

With the NS1 Filter Chain, achieving intelligent traffic routing and building your own highly performant and resilient CDN is a snap!