See how to secure your DNS with xDNS Redundancy - it provides a simple way for companies to manage their DNS on multiple external platforms.

xDNS for Multi-Provider DNS Redundancy and Resilience

Secure your DNS with xDNS Redundancy - it provides a simple way for companies to manage their DNS on multiple external platforms.

See how to secure your DNS with xDNS Redundancy - it provides a simple way for companies to manage their DNS on multiple external platforms. 

More about this whitepaper

Prevent DNS downtime due to human error and DDOS attacks

Easily set up xDNS Redundancy Profiles for your critical domains

Stop relying on a single vendor for DNS uptime

What you get

Get access to whitepaper.

Secure your DNS across multiple DNS service platforms with Men&Mice xDNS Redundancy.

Multi-Provider DNS Management and DNS Redundancy

Who Needs DNS Management and Redundancy from multiple vendors?

What happens when DNS becomes unavailable?

DNS is often grouped in with several services called “common services” or “core services” due to every communication both inside and outside your organization being dependent on DNS being up and performant. DNS is one of those protocols that has the most amount of people and services dependent upon it and yet the least amount of people managing it. Therefore, it’s often an afterthought until it goes down.

We’ve all seen this happen in very recent history, when a monolith DNS provider goes down, even just for a few minutes. When this happens, any company reliant on a single DNS provider will experience service outages, most importantly outages for revenue-generating services. Even if you don’t depend on revenue from services made available over the internet, just having your web presence disappear for a time can be detrimental to your business. When this happens, companies have no control over when these services might come back, and simply must wait to hear back from their managed DNS solution provider.

There are several examples of these large outages, such as:

Each of these outages brought the internet provided services to their knees and while the problem was DNS, the root cause of the problem was often either due to route/switch protocol communication issues (human error) or Denial of Service (DoS) attacks (human malice).

It may be more often the case that internal DNS servers go down, in which case IT teams have a similar issue in that company employees may no longer have access to employee services, applications break down, and IT teams must drop everything to identify and fix the DNS management issue internally while coworkers look over their shoulders awaiting a solution. Many of these internal issues will also be due to route/switch problems, malicious attacks, or simple human error.

To discover the true impact of a potential loss of DNS availability, enterprises need to properly assess the business risk associated with relying on a sole source provider, and compare that with the cost of a second source DNS service. What would a 30-minute loss of DNS cost the business in terms of revenue loss, reputation damage, support costs and recovery? What does it cost to maintain a second source DNS service?

Research amongst enterprises for whom online services are mission critical generally concludes that the cost ratios are in the range of 10:1 – one order of magnitude. Put another way, the cost of one outage is roughly estimated to be ten times the annual cost of a maintaining a second service. A business would have to have second source DNS for ten years to equal the cost of one major DNS outage.

Looking at the odds and costs of outages, many enterprises are opting to bring in a second, or even a third, DNS service to hold copies of critical DNS master zones (Diagram 1). This system of external DNS redundancy boosts DNS availability by:

Removing the danger of exposure to a single point of DNS failure.

Reducing traditional primary-secondary DNS redundancy vulnerabilities, where secondary zones can’t be changed if the master becomes unavailable.

Improving infrastructure resilience by hosting critical zones with multiple providers, ensuring continued service availability and updates of changes if one DNS service provider becomes unavailable.

DNS, when set up correctly, is highly redundant. No matter which vendor or provider you’re using, failover configurations are a best practice. These configurations are often setup in a “primary” and “secondary” DNS server model. In this model, changes made to DNS zones are done via the primary services, and the primary service will update the secondary. The primary DNS servers are traditionally the only servers that hold a read/write copy of the zone and where the zone can be updated. The only way for a secondary zone file to be updated is by updating the primary zone files. This is the operational model often used with Microsoft DNS or BIND DNS servers.

Many companies will also use traditional hosted DNS, which essentially puts the onus on someone else. This is a legitimate model, but not without faults as these providers are still subject to all of the same security and operational issues.

Cloud DNS services have become very popular in the last decade. While there are several out there, some of the most popular providers are:

Cloud DNS providers have not implemented DNS in a primary/secondary style model and as noted in the examples at the beginning of this whitepaper, outages have occurred and will likely occur again.

Whether you’re managing DNS software internally or using an external service provider, there is one thing all of these services have in common.

They require their service to be authoritative for your DNS zone.

We now know, though, that any dependence on a single vendor for DNS will surely result in a DNS outage at some point.

Hybrid DNS means that you’re hosting DNS zones in two or more locations. One option would be that you’re hosting a DNS zone on-premises for example with Windows DNS and you’re hosting that same zone in the cloud with Amazon Route 53. Another option could be that you’re hosting the same zone in two clouds, such as Azure DNS and Akamai Edge DNS.

Both services are authoritative for your zone in these cases and are not capable of any sort of built-in replication or synchronization. This means that there is no simple way to ensure the DNS zone files are the same between the two services. Any sort of multi-vendor or multi-provider DNS redundancy must be done manually or with do-it-yourself automation.

Let’s take a look at how DNS is currently being managed at Fortune 500 companies.

From the above image we can see that 28.5% of companies are hosting their own DNS services internally. As of 2022, a large portion, 52.5%, of companies are using cloud DNS services, with Akamai Edge DNS being the most popular. Only 7.5% of Fortune 500 companies are using Hosted DNS, which may offer a bit more redundancy that hosting your own internally depending on the configuration.

Finally, we see that 7% of these companies have a hybrid solution, meaning they are providing DNS management via an on-premises solution like Microsoft of BIND and a cloud solution like Route 53 and Azure DNS. Followed by 4.5% of companies which have two or more cloud solutions for DNS management services. These configurations deliver the most highly redundant DNS.

Why are Companies Still Only Relying on a Single Provider?

While it seems like common sense to take a hybrid or multicloud approach to DNS, it seems counterintuitive that so few companies, especially Fortune 500 companies, have embraced this model. This is explained by the operational complexity of having to support multiple zones with multiple providers.

Imagine the complexity involved with just one zone containing 10 DNS records, and you’re using AWS Edge as well as BIND DNS to host this zone. First, is the same team responsible for this or do you have a cloud team managing one and a different ops team managing the other? If one goes down, and you make changes to the other, will those changes be replicated once the service comes back up?

Now if we consider a multicloud situation, where you’re relying on public cloud providers exclusively, these providers are competitors with each other. Their goal is to keep you contained within their cloud instances rather than help you use their competitors’ cloud instances. This becomes even more complex to manage, even though it’s the most secure and redundant model.

Using automation tools, such as Ansible or Terraform are one way to combat complexity, but you’ll still run into complexity issues because all of your vendors are using different APIs which are subject to change with any release. Therefore, you must have multiple automation workflows to accomplish the same goal with different providers. You must also consider having to maintain and update those workflows as the API changes for each provider you’re using, on and off-premises.

In the rest of this paper we’ll discuss how we can solve the issue of DNS redundancy using a capability called xDNS provided by Micetro, by Men&Mice. If you’d like to follow along, please install the free trial any time. We’ll take a look at configuring xDNS within Micetro from a technical perspective as well. If you’d like to watch our webinar, in partnership with Paessler and their monitoring product, PRTG, check that out here.

Once you install the free trial, there is a full set of REST API (Swagger) documentation available directly on your Men&Mice web application accessed via the path /mmws/api/doc/, and the latest documentation is available at https://menandmice.com/docs.

Micetro is an overlay and orchestration solution for DDI (DNS, DHCP, and IPAM) environments, including on-premises and cloud-based assets. Micetro allows you to take advantage of a unified and consolidated System of Record (SoR) that encompasses all your DNS footprints (and their associated Sources of Truth (SoT)).

Micetro also provides workflows, reporting, and a fully-featured API layer. This simplifies all DNS, DHCP, and IPAM operations within a unified platform, integrating heterogeneous environments rather than replacing them. Micetro uses an overlay architecture to minimize upheaval, maximize efficiency, and reduce stress.

Download: The following technical sections used version 10.3 of the Micetro solution. A fully functioning version is available as a free trial  and does not require payment details.

Micetro is a suite of software services. The most important element of that suite is called Central. Central is the heart and soul of Micetro. All the other elements leverage it or connect to it. The following four elements will facilitate integration with your DNS services.

Central runs on Windows or Linux and is the main hub of Micetro. It performs roles such as Identity and Access Management, database, and API access, among others.

Running Central on Windows will provide additional insight into on-premises AD Sites and Subnets.

Web Application is the primary UI (User Interface). It is common practice to run it on the same host as Central and it does require a web server like Apache or IIS to be running on the same host. It also runs on Windows or Linux.

Console is required for the initial Micetro setup (after software installation), some system administration, and certain features. All functionality is currently being integrated into the Web Application. Console only runs on Windows.

Micetro Agent (AKA Controller) is required to help broker the connection to your DNS servers. These DNS Server Agents co-locate with BIND, Active Directory, or other DNS servers such as AWS Route 53 on the relevant underlying operating system

**Note: **We will not be walking through the basic installation of each element (1-4) above. If you need any additional installation help, the detailed walk-through guides are available here. We will link to more detailed documentation where applicable, but https://menandmice.com/docs will always point to the latest version. Please pay particular attention to the required UDP and TCP port communication between elements.

Note_II: We also need to ensure that the correct licenses are installed for the DNS and IPAM modules. Additional licenses (all available and provided with the free trial) are required for the advanced Workflow and Reporting modules.

xDNS offers service level, platform agnostic DNS redundancy. This type of multi-vendor redundancy is only possible with Micetro because Micetro does not take authoritative control of DNS. Other DNS, DHCP, and IPAM (DDI) solutions, such as Infoblox or EfficientIP, require you to use their solution as the authoritative DNS service. While they can offer some redundancy, it’s still based on a single vendor solution.

While xDNS has been a capability of Micetro for a few years now, in version 10.3 it’s even easier to implement and maintain using the web UI using xDNS profiles.

xDNS Profiles may be created within Micetro without any extra licensing. They are built-in to the base product with the DNS module. A profile will group together two or more DNS services which will share authority of specified zones. In the above example you can see two zones have been created, “Critical Zones” and “Non-critical zones” but the naming of these profiles is left up to the administrator.

In order to create an xDNS Profile you must be under the Admin >> Configuration>>xDNS Profiles tab in the Micetro Web UI.

Once you click on “Create Profile” you’ll be presented with a dialog window.

Here you’ll specify the Profile name, Conflict Strategy, and Servers.  Changes within and outside of Micetro are automatically replicated to all DNS services which have been added to the profile. If a conflict arises, Micetro will try to resolve it automatically using by default the conflict resolution strategy set on the profile.

In the case of a conflict there are two possible conflict strategies.

Overwrite existing zones - if a zone with the same name exists on any of the other DNS services which make up the xDNS profile, its records will be overwritten with the record data from the zone instance which is being added to the xDNS profile.

Merge Records -  if a zone with the same name exists on any secondary service, its contents will be merged with the contents of the zone on the primary service.

Under Servers you’ll see all of the DNS services you’ve connected to Micetro. You may choose any of these services which make sense for your environment. Once you’ve’ chosen a service you may also choose whether you’d like to reject external changes. For example, if you have an a BIND DNS server and an AuthServe DNS service running, as shown in the image above, you may choose to reject changes made directly to your BIND DNS server which means it will not replicate to your AuthServe DNS service.

It is important to note that one a profile has been created, the list of DNS services may not be changed. You can simply create a new profile with the correct list of services that you would like to include within that profile.

To add and manage the DNS zones, a user will need to have administrative access within Micetro to the DNS services as well. Micetro uses role-based access control (RBAC) to give users granular management at a system-wide level as well as a granular DDI object level. For more information on RBAC within Micetro, please read the documentation found here.

Once the profile has been created you can start adding as many of your DNS zones as you like to the appropriate xDNS profiles. Want to see it in action? Check out this video from the lead developer of xDNS.

Once you’ve created xDNS Profiles according to your use cases, you can easily add in the proper DNS zones to the profiles. Under the DNS tab you can highlight a zone or multiple zones at the same time and then click on the meatball menu to view the available options. One of the options will be “Add to xDNS Profile.”

Here you can select the correct profile to add your zone(s) to and you’ll also receive a pre-flight check which will tell you of any warnings or errors which may occur. This will give you the confidence to ensure you’re picking the correct profile and that the domain name will be accessible even if one of your DNS providers goes down.

Now to easily navigate to the zones which have been added to xDNS Profile and therefore made redundant, we can click on the xDNS zones in the left sidebar under the DNS tab. Here again we can click on the meatball menu and choose whether we need to edit this zone or remove it from the xDNS Profile.

To ensure you can remain confident that your domain names will remain accessible there is an xDNS status contained in the UI which lets us know whether the zone is in sync, out of sync, offline, or missing.

If you see all green dots for your xDNS status that means all your DNS servers are up and the zones are in sync with all the providers.

Once you install the free trial, there is a full set of REST API documentation available directly on your Men&Mice web application accessed via the path /mmws/api/doc/, and the latest product guides are always available at https://menandmice.com/docs.

xDNS for Multi-Provider DNS Redundancy and Resilience

More about this whitepaper

What you get

Trusted by

Get access to whitepaper.

Products

About Us

Support

Learn More

Legal