December 18, 2023 By Ben Ball 4 min read

Anycast is a standard, table-stakes feature of every authoritative DNS service. It makes sense: inbound queries should always be routed to the best available servers—usually the ones that are geographically closest. Yet, there is one glaring exception: China.

The internet in mainland China is walled off from the rest of the world. Any DNS query that crosses into or out of mainland China must pass through a series of filters and other controls before it can be passed along for resolution. These filters and controls impose a gigantic performance hit—if the query is allowed to resolve at all. 

The risks of Global Anycast DNS in China

Several authoritative DNS providers deal with this issue by extending their network into mainland China so they can resolve traffic inside mainland China. These additional points of presence (PoPs) are attached to a global anycasted network but primarily serve users in mainland China due to the use of geographic traffic steering.

At first look, this approach seems logical. Since anycast DNS queries in mainland China will be answered by the nearest server, the more PoPs in China you have, the more likely you are to respond from a server that sits inside the system of filters and controls.

This approach isn’t foolproof. Global brands serve up applications, services and content from nearby countries as well. Even with a large number of PoPs in mainland China, the Border Gateway Protocol (BGP) often sends users in mainland China to resolving servers in neighboring countries based on prevailing internet conditions and the number and cost of “hops” needed to find the resolver. When that traffic goes across the system of filters and controls, the performance hit is significant.

In this sense, anycasting an authoritative DNS service in mainland China is a bit of a crapshoot. If you’re not deliberately directing users in China to a domestic server, there’s always going to be a risk of poor performance.

The NS1 Connect approach: Nameserver Acceleration

IBM® NS1® offers a distinctive approach to resolving DNS queries in China—one that removes the risk of anycast-induced performance issues by geolocating the query source. We call it Nameserver Acceleration.

NS1’s DNS infrastructure is essentially two separate but related networks: NS1’s anycasted Managed DNS service and our Managed DNS for China offering. Instead of blindly relying upon BGP to find a resolver, we use our own traffic steering technology to figure out which network should respond to a query. 

If a request comes from China (as determined by geolocating the source IP), it is answered by one of our DNS servers in China. If not, the request is answered by a server on our global anycasted network.

How Nameserver Acceleration works

When a user in mainland China initiates a DNS query, the first “hop” goes to a local resolver. In the second “hop”, the resolver does an IP address lookup.

This second hop is where BGP often routes traffic to a nearby country. NS1 adds a step to the resolution process to ensure that doesn’t happen. 

Normally, the nameserver for the top-level domain (TLD) returns both a domain name and an IP address, stored in a “glue record”, to reduce the number of lookups. Nameserver acceleration is configured to remove this glue record.

When the recursive resolver doesn’t get the glue record it needs, it performs a separate lookup to find the missing IP address. When the resolver looks up the IP address of the authoritative nameserver at NS1, we respond with an IP address based on the resolver’s location. 

If that resolver is in China, NS1 responds with an IP address of a China-based nameserver. If the resolver is outside of China, the response goes back with an IP address for a server on NS1’s global anycast network.

Performance impact

Now, you may be asking, “doesn’t that extra lookup actually degrade performance?” It is true that inserting an additional step into the query resolution process takes extra time. However, we’ve found that the impact on performance is so negligible that it’s hardly worth mentioning. And in comparison to the drag on performance produced by the system of filters and controls, it’s clearly worth doing.

The numbers clearly bear this out. Here’s some data we pulled on DNS response times in mainland China from IBM NS1 Connect® and its primary competitors. As you can see, our approach yields significant dividends—on average, our service is over three times faster than any other network.

The DNS management angle

If you’re a global business with a significant user base in mainland China, Nameserver Acceleration makes NS1 the clear choice for DNS services. But it’s not the only reason. 

NS1’s Managed DNS for China does all of this through a single control plane. All of the technical magic and fancy traffic steering happens within our platform. From a management perspective, queries from China sit right alongside the rest of your network. 

Not all DNS providers can say that. Due to Chinese regulations around serving content, many of them require entirely separate accounts and credentials to specifically manage queries that originate in China. Since NS1 is a pure play DNS provider, we can offer a single control plane without the need for an ICP license.

Learn more about the distinctive benefits of NS1 Managed DNS for China.

Explore NSI Managed DNS for China here
Was this article helpful?
YesNo

More from Automation

Generate Ansible Playbooks faster by using watsonx Code Assistant for Red Hat Ansible Lightspeed

2 min read - IBM watsonx™ Code Assistant is a suite of products designed to support AI-assisted code development and application modernization. Within this suite, IBM watsonx Code Assistant for Red Hat® Ansible® Lightspeed equips developers with generative AI (gen AI) capabilities, accelerating the creation of Ansible Playbooks. In early 2024, IBM watsonx Code Assistant for Red Hat Ansible Lightspeed introduced model customization and a no-cost 30-day trial. Building on this momentum, we are excited to announce the on-premises release of watsonx Code Assistant for Red Hat Ansible Lightspeed,…

4 key metrics to know when monitoring microservices applications running on Kubernetes

3 min read - Understanding how microservice applications works on Kubernetes is important in software development. In this article, we will discuss why observing microservice applications on Kubernetes is crucial and several metrics that you should focus on as part of your observability strategy. Why should you observe microservice health running on Kubernetes and what are the Kubernetes metrics you should monitor? Consider a large e-commerce platform that utilizes microservices architecture deployed on Kubernetes clusters. Each microservice, responsible for specific functionalities such as inventory…

Deployable architecture on IBM Cloud: A look at the IaC aspects of VPC landing zone 

5 min read - In the ever-evolving landscape of cloud infrastructure, creating a customizable and secure virtual private cloud (VPC) environment within a single region has become a necessity for many organizations. The VPC landing zone deployable architectures offers a solution to this need through a set of starting templates that can be quickly adapted to fit your specific requirements. The VPC Landing Zone deployable architecture leverages Infrastructure as Code (IaC) principles, that allow you to define your infrastructure in code and automate its…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters