DNS redundancy means two or more DNS providers answer for the same zone, so resolution continues when one goes down. Because only static records copy cleanly between providers, geo-routing and health checks are usually lost. With OpenResty Edge as the primary, intelligent routing stays on OpenResty Edge while other DNS providers act as secondaries, pull the zone over AXFR with TSIG, and answer alongside it.

On October 21, 2016, the DNS provider Dyn was hit by a DDoS attack from the Mirai botnet, and a long list of sites, including Twitter, GitHub, and Netflix, became unreachable for a time. The sites themselves were fine; users simply could not resolve their addresses. As long as your authoritative DNS is hosted in only one place, whether that place is a provider or your own servers, every service that depends on it goes down the moment that one place becomes unavailable.

This post explains how the split between OpenResty Edge and secondary providers works and which zones it suits. For configuration steps, see the OpenResty Edge documentation: DNS Zone Transfer and TSIG.

Request to try out OpenResty Edge

Why multi-provider DNS often means giving up intelligent routing

A recursive resolver picks one of the name servers in a domain’s NS set to query, usually favoring the one that responds fastest, and moves on to the next if it gets no answer. So when the NS set includes name servers from two providers and one provider goes down, resolvers switch to the other and resolution continues. This mechanism rests on one condition: both providers must return the same records. Otherwise the same name returns different answers at different times and to different users.

There are two common ways to keep several providers consistent:

  • Multi-primary: every provider acts as a primary server, and the same records are written to each one separately through its API or a sync tool. The trouble is that each provider supports different record types, has its own proprietary features, and exposes a different API, so their configurations tend to drift apart over time. And every additional provider means another API to integrate and maintain.
  • Single primary, multiple secondaries: records are written in one place only, and the other providers act as secondary servers that periodically pull the complete zone through zone transfer (AXFR). With a single write point, the protocol guarantees consistency.

Whichever you choose, the only thing that stays consistent across providers is the set of standard static records they all support. For capabilities such as geo-routing, health checks, and traffic steering, the server computes the answer on the spot when a query arrives, based on where the query comes from and on real-time state. Every provider implements these features differently and incompatibly, and zone data can carry the answers but not the logic that computes them. IBM NS1, for example, states in its documentation that Filter Chain traffic-steering configuration and proprietary record types such as ALIAS are not included in outgoing zone transfers. The result is that, for the sake of redundancy, teams often have to settle for the lowest common denominator of features and give up intelligent routing.

In business terms, this is a choice between two risks: rely on a single provider and accept that resolution stops entirely when it goes down, or drop back to static records for redundancy and give up nearest-node access and automatic removal of failed nodes, so some users are sent to addresses that are farther away, or even already down.

How OpenResty Edge adds DNS redundancy: primary for intelligent routing, secondary providers as fallback

If you already manage your zones in OpenResty Edge’s built-in authoritative DNS, enabling zone transfer gives you the following architecture:

                 You (Edge Admin console: edit → release)
                               │
          OpenResty Edge (primary server, single source of truth)
                  │                            │ AXFR over TCP + TSIG signature
                  │                  ┌─────────┴─────────┐
                  │             Secondary A         Secondary B
                  │                  │                   │
                  └──────────┬───────┴───────────────────┘
     Public NS delegation lists OpenResty Edge and every secondary provider
                             │
                  Recursive resolvers / users
  • You still add, edit, and delete records only in OpenResty Edge. Secondary providers pull the entire zone through AXFR, and the transfer can be authenticated with a TSIG key.
  • OpenResty Edge keeps answering public queries as before; enabling zone transfer does not affect existing resolution. The public NS delegation lists both OpenResty Edge and each secondary provider: keep OpenResty Edge’s name servers at your registrar and add those of each secondary provider.

With this division of labor:

  • Intelligent routing keeps working. Queries that reach OpenResty Edge still get answers shaped by geo-routing, gateway-node resolution, and health checks, based on where the query comes from and on real-time state: nodes that fail health checks are automatically removed from resolution, and GSLB can also shift traffic between clusters based on business metrics such as machine load and request rate.
  • Static records gain multi-provider redundancy. Every secondary provider answers with the same static records, so when OpenResty Edge or any one provider is unavailable, the others keep answering.
  • Secondary providers can be added, removed, or replaced as needed. Syncing relies only on AXFR zone transfer, a standard protocol, and not on any provider’s proprietary API. When you switch secondary providers, the new one simply pulls the entire zone through zone transfer.
  • Geo-routed records have a fallback too. Give each geo-routed record a default answer with no geo condition, and secondary providers can serve that default answer.
  • The fallback window is long. In the SOA record that OpenResty Edge generates, the expire value defaults to 604800 seconds (7 days) and can be adjusted as needed. After each successful refresh, a secondary server can keep answering from its copy for that long, even if OpenResty Edge is temporarily unavailable.

For the business, redundancy no longer has to come at the cost of user experience: in normal operation, users are still steered to the nearest healthy gateway cluster; an outage at any one provider can no longer take the whole business offline the way the Dyn incident did; switching providers requires no record migration or re-entry, so the business is not locked into any single provider; and even if OpenResty Edge itself fails, the team has ample time to investigate and recover while public resolution continues uninterrupted.

Keeping the single source of truth in OpenResty Edge brings four more benefits:

  1. Every change goes through access control. Access to DNS applications is granted per user group, and read and write permissions can be separated. By default, regular users cannot see the DNS section at all, or any DNS application not granted to their user group. See Control Access to DNS Applications in OpenResty Edge’s Admin Console for details.
  2. Changes are versioned and take effect only after release. Since version 25.9.17, OpenResty Edge has kept DNS configuration under version control. Zone transfer settings, like records, are pushed to nodes only after they are released.
  3. The serial is maintained automatically. A secondary server decides whether a zone has changed by comparing the serial in the SOA. With a self-hosted primary, a person or a script has to increment this number, and if an increment is ever missed, secondaries will not pull the new data. OpenResty Edge maintains the serial automatically and increments it on release only when the transferable content has actually changed, so secondary servers can reliably tell whether they need to pull again.
  4. The single source of truth is itself protected. DNS applications are stored in the Edge Admin database just like every other application’s configuration, and OpenResty Edge protects that database in three layers: scheduled off-host backups, primary–standby streaming replication, and automatic failover. See OpenResty Edge Database Backup and Failover for details.

For your team, this means DNS can be governed like any other production configuration: when several teams share one platform, each manages its own zones without accidentally changing anyone else’s records; edits do not affect live resolution until they are released, and every change can be traced afterward; secondary providers don’t silently get stuck serving stale data, which removes a class of failures that is hard to spot; and centralizing the data in one place does not mean concentrating the risk in one place.

Which zones suit this multi-provider DNS setup

  • Zones that must stay resolvable even if an entire DNS provider goes down
  • Zones made up mostly of static records, or whose geo-routed records all have a default answer

Conclusion: redundancy, intelligent routing, and governance, without having to pick two

DNS is the first hop of every service. In the past, building redundancy into that hop meant settling for the lowest common denominator shared by several providers, with intelligent routing and unified governance both taking a back seat. With OpenResty Edge as the single source of truth, the math works out differently:

  • Intelligent routing only has to be built in one place. Geo-routing, health checks, and GSLB are all centralized in OpenResty Edge. Secondary providers only need to offer a standard secondary DNS service, so there is no need to buy and configure intelligent DNS again at every provider.
  • No lock-in to any single provider. Secondary providers sync through a standard protocol and can be added, removed, or replaced as needed without migrating records.
  • Governance costs don’t grow with the number of providers. However many providers you connect, every change is made only in OpenResty Edge and goes through the same permissions, versioning, and release process.
  • DNS and the gateway live on the same platform. Records resolve directly to gateway clusters, node health is reflected directly in resolution results, and DNS flood protection is built in, so there is no need to keep two separate DNS and gateway systems in sync.

This architecture is especially well suited to:

  • Online businesses where a resolution outage means a revenue outage, such as e-commerce, online payments, and gaming: if a provider goes down, the others keep answering, and day to day, users still reach the nearest node.
  • Businesses deployed across multiple regions and clusters: geo-routing and cross-cluster disaster recovery are core capabilities that cannot be sacrificed for redundancy.
  • Enterprises running their own private CDN: OpenResty Edge serves as the authoritative DNS that fronts the private CDN, so multi-provider redundancy protects the very first hop of the entire edge network.
  • Organizations where multiple teams share the platform and change auditing is required, such as financial services and the public sector: each team manages only its own zones, and every change is recorded and traceable.

We recommend starting with a low-traffic zone made up mostly of static records. Connect one secondary provider, complete the configuration by following the documentation, and use dig to compare the answers from OpenResty Edge and the secondary provider. Once they match, add the secondary provider to the NS delegation at your registrar.

Frequently asked questions

Can OpenResty Edge act as the primary server for Cloudflare Secondary DNS?

Yes. OpenResty Edge supports AXFR zone transfer and TSIG authentication starting with version 26.9.1-1, so it can act as the primary server for secondary providers such as Cloudflare Secondary DNS. Cloudflare’s zone transfer feature is available only to Enterprise customers.

Do OpenResty Edge’s geo-routing and GSLB still work after I add secondary providers?

Yes. OpenResty Edge stays in the public NS set and keeps answering queries for geo-routed records, records that resolve to gateway nodes, and health-checked records based on where each query comes from and on real-time state. The secondary providers sync the zone’s static records and keep answering if any one provider goes down.

Why don’t geo-routing rules transfer to secondary DNS providers?

Because geo-routing and health-check answers are computed when each query arrives, based on where it comes from and on real-time state. Zone data can carry the answers but not the logic that computes them, and every provider implements these features differently. IBM NS1’s documentation, for example, states that Filter Chain configuration and ALIAS records are left out of outgoing zone transfers. Secondary providers therefore serve static records and default answers.

Do I need to run OpenResty Edge as a hidden primary once I add secondary providers?

No. Intelligent routing only applies when OpenResty Edge answers a query itself; secondary providers receive only static records and default answers. List OpenResty Edge alongside the secondary providers in the public NS delegation: queries that reach OpenResty Edge are routed to the nearest healthy node, and if OpenResty Edge or any one provider goes down, the rest keep answering.

What is OpenResty Edge

OpenResty Edge is our all-in-one gateway software for microservices and distributed traffic architectures, developed entirely in-house. It combines traffic management, private CDN construction, API gateway capabilities, security, and more so you can build, operate, and protect modern applications with less friction. OpenResty Edge delivers industry-leading performance and scalability for demanding high-concurrency, high-load scenarios. It can schedule traffic for containerized applications such as Kubernetes clusters and manage large domain portfolios, meeting the needs of large sites and complex applications.

→ Authoritative DNS is just one of OpenResty Edge’s capabilities. For the rest, see What Is OpenResty Edge.

Request to try out OpenResty Edge

About The Author

Yichun Zhang (GitHub handle: agentzh) is the original creator of the OpenResty® open-source project and the CEO of OpenResty Inc..

Born in Jiangsu, China, and now based in the San Francisco Bay Area, Yichun is among the earliest advocates and leaders of open-source technology and culture in China. He has worked at internationally renowned technology companies, including Cloudflare, Yahoo!, and Alibaba. He is a pioneer in “edge computing”, “dynamic tracing”, and “machine coding”, with more than 22 years of programming experience and 16 years in open source. As the leader of OpenResty®—a project on which more than 40 million domains worldwide rely—he founded OpenResty Inc., a technology company in the heart of Silicon Valley, on that open-source foundation. Its flagship offerings, OpenResty XRay (a non-invasive analysis and troubleshooting tool that uses dynamic tracing) and OpenResty Edge (a full-featured gateway for microservices and distributed traffic), are widely adopted by listed companies and large enterprises around the world.

As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.