The provisioning is great. They have an API service that is simple to use and very quick. The changes that we make are replicated worldwide in a matter of usually milliseconds, sometimes seconds. They are done very rapidly. That's something that's obviously priceless when we're dealing with things like DNS.

It is great as an API-first platform for DNS and application traffic management. It is very simple to use. It allows us to rapidly provision and deprovision things. We are all around happy with the solution.

From a metrics standpoint, the solution that we came from had no metrics. So, it has been great. Their service team is excellent in taking the time to provide reports for both growth and strategic planning. It has been great.

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.

The most valuable features are the DNSSEC and the general reliability and speed of the service. We find that the low latency access to DNS queries has a direct effect on the customer experience. Visiting a site, whether it's an AdTech-based solution or marketing tech, the fact that whatever we're rendering on a page can be rendered better than the industry standard, in terms of time, ensures a better user experience.

The Application Telemetry feature is awesome. This includes latency detection and it allows us to detect where a customer may run into latency on the internet, giving us the opportunity to route around it. It contributes to providing the best user experience for our clients.

Using the Pulsar feature has certainly improved our user experience. Using Pulsar with telemetry monitoring between the customer and the endpoint, we are able to detect traffic and route it appropriately, which ensures the uptime of our applications and web properties. It also ensures that the lowest latency experience is possible.

One of the features that is non-standard and that is very useful is the filtered DNS. We have set up our external VPN, which is what all our employees connect through, to use this feature. It's geolocation-aware. In that way, for India we set it up so that these are the servers that should be supporting things, and in the UK these servers, in the U.S. these servers, and in Sweden these ones. If a server is down, it will automatically use a server that is up instead. It's like a load balancer that manages the redirecting of traffic depending on where you are.

The filtered records mean we can set up the rules so that DNS requests are answered exactly the way we want them to be. For example, if my request comes from Sweden, we can have a rule in the filtered DNS setup to go to sslvpnsc.ourcompany.com if it's up. Otherwise, it uses another one. 

The solution has other features where you can import and export data, but we don't use them. We use the more fundamental things, but NS1 is a big help for us thanks to the filtered records.

Another reason we use it is that we use a management tool, where you can update DNS records called Micetro from Men&Mice. It has an integration with NS1 and, for us, this was the perfect combination.

NS1 Managed DNS also has a REST API which makes it easy to integrate things yourself. We collect some statistics by using the REST API. And even if we don't know if we will need it, from time to time we take a backup of all the data records by using that API. It is helpful for automation. The API also made it possible for Micetro to integrate with NS1. Men&Mice used it to integrate their management tool to update, manage, delete, and report, and do everything else you would normally do with DNS from within their platform. The NS1 API is good and flexible.

As for maintaining uptime during a DDoS attack, we haven't noticed anything, so it has been fine from our perspective.

Collection RUM (Real User Metrics) and using them in NS1 Pulsar filters. This has been really valuable as it allows us to determine the best, and most performant CDNs for our users. It has proven valuable at responding to and recovering from unexpected downtime from any of our multiple CDNs.

We also use their Terraform plugins to do our deployment, instead of going through their CLI or their console. We find Terraform to be a really powerful tool when using NS1. Terraform allows us to track infrastructure changes and push large scales changes more easily.

The fact that it is an API-first platform for DNS and application traffic management is what makes their Terraform solution possible. We haven't directly integrated with their APIs from any of our solutions. I know I really appreciate a company that adheres to an API-first approach, because it unlocks a lot of potential to really customize tools to meet our needs.

• Ease of use 
• Stability - We haven't had any issues at all with the service.

Also, the fact that it's an API-first platform for DNS and application traffic management is one of the reasons we looked into NS1. We use it for a lot of automation and metrics gathering and it's been great.

Its real-time telemetry and ecosystem of integrations are very easy to use. We haven't taken advantage of much of that, but the fact that we know those capabilities are there, and that they're pretty straightforward, is key. We have done a few things using their routing protocols that are provided as part of the service and that has been really nice. We can actually do automation around that as needed.

The ability to automate DNS creation is definitely paramount.

The solution is an API-first platform for DNS and application traffic management. This is exactly what we needed it for since most DNS services don't come with an API. Whereas, being API-driven, NS1 allows us to create automation against it. We can create pipelines, deploy software, and automatically integrate with NS1 in an automated fashion, which is definitely great.

NS1 Managed DNS has helped improve our end user experience, which has sped up our time to market.

The Filter Chain is one of the most valuable features, for geo-load balancing and geo-fencing. The Filter Chain is the most useful because it allows us to do several things. With geo-fencing we can redirect a particular user to a particular answer. That's very valuable for us. Filter Chains with monitoring is our strategy to provide redundancy.

We also use the automation extensively, with Terraform.

From the get-go, we have used the API from NS1. We have hardly used the solution's UI. For any major changes, we use the API and that works brilliantly for us. As an infrastructure team and organization, we heavily value infrastructure as code, so this is a great approach. Any feature that comes into the Filter Chain gets exposed first to the API, before it even goes to the human resources. It works very well and enables us to adapt a complete infrastructure-as-code approach.

The real-time telemetry and ecosystem of integrations were also a key part for us when choosing among multiple vendors, because of geo-location. It's very crucial for us. Choosing which server to use, in case of an emergency, for example, we depend on NS1's monitors. It's reliable and hasn't caused us any trouble. Another advantage is that there are multiple regions for the telemetry collections so, even if one of them has an issue, we are confident that there is enough redundancy to let us sail through the problem.

We leverage two things from Managed DNS that we couldn't do with any other solution. One is their filter chain technology, which allows us to shift some of the intelligence we need for the traffic steering to the DNS. The second one is data sources, which enables us to manipulate multiple records simultaneously using NS1's internal message DOS. In our case, we are trying to direct the traffic in over 150,000 different NS1 records to an arbitrary set of repeating responses. 

If we have about 1,000 endpoints, that translates to around 150,000 records. Assuming there's an even distribution, so every time a server fails or an endpoint goes on a level, we would have 150 updates. With NS1, we have one, so this had an even more significant effect. There are situations where we have thousands of specific records sharing the same responses. In that case, there is one update instead of thousands and thousands.

When we chose Managed DNS in 2014, it was the only solution that could do what we wanted, but I'm not sure about the current state of the market. The NS1 API is an API on top of a managed DNS. It's not an afterthought. It's not like the solution existed. 

Someone was sending updates by email. Then a product manager came along and said, "Hey, there is this cool thing. It's called an API. Maybe we should do it?" And they are like, "Okay. Let's do it."  In the case of NS1, they thought about how to use an API to manipulate and retrieve the stuff. It's supposed to be API-driven. Also, NS1 doesn't have hidden features that would not be available over the API. Even their dashboard is built on top of the API. You can leverage all the functionality programmatically. That's what we do.

We don't use their native integrations because we have been customers before these integrations and real-time telemetry existed. Our solution isn't leveraging either of those. Instead, we leveraged their API integration, which was the first thing that existed. Indeed, the API is at the core of how we use Managed DNS. No one goes to the dashboard or manually clicks anything. Everything goes via the API, and we perform hundreds of changes every minute. The API automatically drives everything, so that's the integration we leverage.

We don't use the Pulsar Active Steering feature because we don't have a website. Our solution is being used as an API for other solutions. You can put the Pulsar agent on the website and feed NS1 the information. In our case, we are integrating into third-party sites. We cannot put our JavaScript on their websites for NS1 to provide the data, so we don't.

The Pulsar functionality, map uploading, and real user maps around DNS are some of the valuable things for us.

Another valuable feature is how easily we can interact with their API. We run our infrastructure as a code, so it is really easy for us to describe the whole configuration of the NS1 service by using our service configuration and interact with their API. We like this functionality a lot.

Monitoring is really important for us. We really care about reliability, and we want to make sure that we can remove some points of presence in our sector and in our edge network really fast when we experience any problems. So, monitoring that NS1 provides for DNS is really important for us.

The ability to manage traffic, what's called Smart Domains or Smart Record, enables us to provide our customers the relevant, closest data center by providing the correct IP address according to geography or other logic. The ability to see real-time performance is also very useful. 

Everything we download into our observability platform so that we can also track any changes in traffic behavior or things like that is also something that we use quite a lot. I'd say traffic management, the speed of updates, and observability are the top three things that we use.

Observability means monitoring the API, the ability to see the traffic at the different levels, the ability to connect the right record to the right place, and then see everything within the platform or within our observability platform. It is really useful. The automation and the fact that they provide the connectivity into Terraform, for example, is very useful because it allows for ease of integration. I don't have to write the right API integrations myself. We can actually use industry standards that are available out there.