What is our primary use case?
We are a marketing platform with a pretty wide range of customers around the world, from small businesses, like mom and pop shops that sell shirts, to enterprises like Salesforce or VMware, on the B2B side. Our JavaScript tags and our servers on the customer side generally have to answer requests very quickly, always be available, and not lose any data. Among our products is advertising, and that side is required to answer requests that come in from around the world. Usually they're geo-distributed when they come to us. There are many millions of requests a second that we need to handle.
On the customer side, our use case is simple. Requests coming in from an end user, from their browser, need to be routed to the closest endpoint so that the latency is consistently low. The other requirement is that if one of those regions, in a very rare occurrence, is experiencing problems, we need to be able to clear traffic to a secondary or tertiary region to avoid downtime. In that situation, a little bit more latency is fine, but downtime would not be. To do this, we've always used global service load balancing, or DNS anycast, to an extent.
How has it helped my organization?
NS1 has greatly reduced DNS maintenance work in our organization. I used to have to log in just to do user-provisioning. That would be something that took me an hour every time we needed to add or remove a couple of users from the old account. With Okta, I never have to deal with that anymore. And during failures, logging in to the account and searching for what was wrong was pathetic when we were using Dyn. With NS1, the interface is pretty fast.
For example, the other day we had an account customer complaining to us that for certain records we were serving, the necessary certificate was expired. I looked into it and it was because it was being sent to our old CDN vendor and I needed to figure out where this stuff was serviced. I went into NS1 and saw that the record name did not have any traffic on NS1. Instead, it was a record name served via Route 53 on a different account. I could not have done that inside Dyn because there was no reporting breakdown on a per-record or a per-node level. In this case, I just removed an entire DNS. The only thing that was left was Route 53 so I could go directly into Route 53 without losing my mind. It took me about 15 minutes while sitting on the couch to fix it. It easily saves us hours every month. And I rarely log in to NS1 anymore because it just works.
We do less manual stuff now. For instance, to deploy a new region for the advertising side of our business, it would take a lot of very manual work to add records. Now we can just Terraform it. That process has gone from taking the relatively long period of an entire day to being able to Terraform, apply, and be done with it. We don't create new regions very often, but if it has to be done manually it's prone to errors and takes a long time. Now, instead, it's automatic and there's no potential for errors anymore.
Going with NS1 has also improved the user experience for our users. We had more than one situation in which Dyn probes were monitoring from across the ocean and they would cause the data center not to be the one servicing requests anymore. That would cause an increased latency for our end-users and would make the experience worse for our customers. Now that I can select the probes and make sure that the ones that detect if something is up or down are the ones that are relevant for the user experience, that doesn't happen anymore.
What is most valuable?
For starters, it integrates with Terraform and a lot of our infrastructure is effectively built out using Terraform. That makes all this stuff extremely easy. With Dyn we had to have a separate process to update DNS entries, and only a person like me could do it. Even then, it was going to be a very delicate process. Now, we have it integrated with Terraform and when we deploy, all the entries are created and configuration is done.
As an API-first platform for DNS it is great. The one thing it needs to do for us is be integrated with our infrastructure-as-a-service setup, Terraform. In that regard it beats all of its competitors, including Dyn from Oracle and Route 53 from Amazon. Neither of them support integration with Terraform. Their support team is also great around this stuff.
Secondly, the user interface is pretty fast and it's very easy to get reporting on queries-per-second underneath each record. That means that if we misconfigure something we can very quickly see the results in the metrics. That wasn't the case with Dyn. Being able to see the metrics helps. It helps that the interface is really quick, and relatively easy to use, especially compared to other solutions that we've seen, including Route 53, which we also use.
Technically speaking, there is no one button to enable load balancing like the others, but you can customize the way load balancing works more, to your own specific needs. We took advantage of that for the particular way we want to run our infrastructure. It's a little bit harder to set up compared to what Dyn was, but it's certainly more flexible. That needed to be learned and we played around with it for a little while at the beginning, before doing the migration. But since the migration, everything has been going well.
Another thing that is pretty helpful is that every one of these entries has its own target probe, called "monitors" in NS1 parlance. Each one of these endpoints has a set of monitors and it's possible to choose the regions from which you check the times of an area and the policies. This wasn't possible with Dyn, unless you talked with the account manager, and it would still always be a little off. There were occasions in which Dyn decided that a server in Tokyo was down because it wasn't reachable from San Francisco, and no one cared. Considering that we have a data center in San Francisco, San Francisco traffic shouldn't determine what happens to the Tokyo data center. Using Dyn made things like that a pain to deal with, but with NS1 we have been able to select the specific region from which we are monitoring our endpoints to determine if they are up or down and if they need to be pulled out of rotation. And they have mostly been working fine.
There is also a Slack integration that we set up for our monitors. Whenever a monitor goes down, or there's a down and up, we get a notification in Slack. That means that the routing of requests to our team, for escalating any problem with the DNS, can be done more democratically than we used to be able to do with Dyn. With that solution, it would be sent to the email associated with the account.
In addition, there are the more intangible things, such as being on an exclusive, dedicated DNS network. I gather NS1 has both dedicated and shared DNS infrastructure, and I think we are on the dedicated. I've never tried the other one, and I don't know how Dyn was set up, but we've never had issues since switching. Everything has worked pretty well.
What needs improvement?
We use the geo load balancing functionality and there are a couple of things that are helpful there. But the language itself is something we had to get used to a little bit. Some of my folks made a few mistakes in rolling out the Filter Chain. It doesn't return all of the multiple results by default. It returns only one. So we have to add a bunch of operations, like geo-target by first selecting a group in terms of regional proximity and then shuffle the list of potential endpoints and then select the first one. The Filter Chain setup is a bit hard to grasp at first. It would also be nice to have a way to simulate changes in addition to staging.
Also, right now, as far as I understand, there is no way to do atomic changes to a DNS configuration. You need to make changes record by record and apply. But if someone wants to do more complex stuff like, for example, if I want to migrate from a CNAME to an A record being served, or vice versa, that's typically something that involves first taking out all of the CNAMEs and then adding all of the A records. That would require some downtime. It would be a lot easier if I could just have the new full record with the CNAME or A record, and then be able to replace the nodes directly in a single operation and I don't think they have that.
For how long have I used the solution?
We started using NS1 Managed DNS in 2018 or 2019.
What do I think about the stability of the solution?
Except for that one time that they had probe monitor issues, we've never had a single problem with it. It's pretty stable.
What do I think about the scalability of the solution?
We haven't had any issues with the scalability. The scalability helps meet SLAs and customers’ demands without adding complexity. We run more than 4.5 billion queries per month on our DNS, so it's pretty critical that they can handle that volume and it's been going pretty well so far.
How are customer service and support?
We used their tech support at the start a couple of times. We were trying to get onboarded and some of us were getting confused with the setup for load balancing DNS. The first or second time that we dealt with them they decided to just write out for us the way that the Filter Chain was supposed to be.
Another couple of times, they wrote to us first about issues.
There had been some kind of ongoing event and we wrote to them. They responded very quickly that there was an issue and that some of their probes were down. That told us not to go hunting for anything. Rather, I was able to go in the UI and force probes not to be considered for a period of time in the uptime and downtime of an area. As far as I remember, responses from NS1 were all well within one hour.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
When Dyn was bought by Oracle and then Oracle decided to flip everybody over to a new infrastructure, that was when we decided to switch. We had used Dyn since 2009, and it had been working fine.
Dyn didn't do any automatic migration for us from the old accounts to the new account. Oracle forced everybody to do that. And Dyn didn't develop the platform at all in the preceding six years or so, and there were many features we wanted that they didn't field. We decided that if we were going to have to do the migration by hand anyway, and whatever risk might be involved in that, we might as well consider NS1. NS1 reached out to us, as a customer of Dyn, knowing what was coming. Their sales team did a proper job. We talked about the plan from Dyn and when we talked about their platform we decided to switch.
User management was also a mess with Dyn. Truly the worst part of that solution was dealing with the user management. With NS1 it's integrated with our Okta. We gave access to folks that need access to DNS via Okta, so it's integrated with our permissions system, and Dyn was not.
When we switched from Dyn, one parameter that we used for determining our choice of infrastructure, going forward, was DNS response times. The response time with NS1 is fine. From my own computer it's not as fast as Dyn was, it's just a smidgen slower, but it's still pretty fast. We don't need it any faster than that.
How was the initial setup?
The initial setup of the solution was pretty straightforward. We did it within about 15 days. There was zero downtime in migrating to the solution. If there had been any downtime we would not have done it.
What about the implementation team?
We worked with their customer success team. They helped us set things up at the start, but it took very little time. We did almost all of it ourselves and they gave us a little bit of help on the Filter Chain stuff. I did the switchover myself and everything worked out.
What's my experience with pricing, setup cost, and licensing?
We promised NS1 that we would do the migration in a very short period of time and that we were open to being on their homepage for marketing purposes, and they gave us a good price at the time.
We pay about $30,000 a month. We used to pay about $20,000 with Dyn every month, for lower volume than we're doing right now, but it had none of the features that we have available with NS1, so it was worth it for us. It seems competitive for us, given that we're doing 4.5 billion requests. And when you do load balancing like that for downtime, all of your TTLs are very low. A lot of our TTLs are in the five-minute space. It generates a ton of extra load on the DNS when you do five-minute TTLs. If we wanted to decrease our bill we could just increase our TTLs, but we don't feel like risking that.
Which other solutions did I evaluate?
If someone were to say to me that they don't need to spend money on a solution like this because they have a free cloud provider or basic DNS, I would tell them that's not true. The free providers don't provide global load balancing. There are no free solutions that do geo load balancing.
If you try the other options like Amazon Route 53 or Dyn or Ultra DNS, the only way you can get geo load balancing is if you use something like Route 53's policy editor. It's graphical only, extremely slow, and there are a lot of limitations to what it can do.
I played around with Route 53 extensively. I have been a member of the customer advisory board of AWS for a very long time now. I really like a lot of their solutions and I tried to get Route 53 going, but it just wasn't good enough, and it wasn't free. It was expensive. There was no way to deal with it without the policy manager, as well.
Dyn is a pain. We had nine years of experience with it and I would not want to use it again.
If you have normal DNS needs that don't involve advanced features of a DNS, you may be able to deal with Route 53 or another simple DNS solution, although probably not a free DNS service. But if you have anything more complex than the simple stuff, I doubt those solutions will work for you.
