Articles
profile image
Lauren Malhoit

How is DNS Downtime Still a Problem?

With DNS being a redundant protocol, and the onslaught of multicloud DNS, how is it still an issue? The problem is not with technology or people, but with operations. If an operational model is too difficult, it's not sustainable.

Sep 26th, 2022

With DNS being a redundant protocol, and the onslaught of multicloud DNS, how is it still an issue? The problem is not with technology or people, but with operations. If an operational model is too difficult, it's not sustainable.

We've examined the information before in previous DNS redundancy blogs. Only 11.5% of Fortune 500 companies are practicing multicloud or hybrid cloud DNS redundancy, supporting our assertion that DNS redundancy is too complex to maintain in a multi-provider context.

Making DNS Redundancy Operationally Sustainable

This operational complexity is the exact reason Men&Mice have created xDNS, a multi-provider DNS redundancy capability within the Micetro solution. Micetro is able to offer this capability because it does not take authoritative control of DNS zones. Other DNS, DHCP, and IPAM (DDI) solutions, such as Infoblox or BlueCat, require use of their solution as the authoritative DNS service. While they can offer some redundancy, it’s still based on a single vendor solution.

This is achieved in Micetro through the use of simple profiles.

xDNS Profiles

xDNS Profiles are groupings of at least two DNS services, on-premises or external/cloud services, which will share authority for specified zones. Creating a profile is simple and will be done in the Admin tab of Micetro.

Built-in to these profiles will be user specified conflict strategies for the case that changes might be made when one more more services are down.

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

  • Overwrite existing zones -  records will be overwritten with the record data from the zone instance which is being added to the xDNS profile.
  • Merge Records -  contents will be merged with the contents of the zone on the primary service.

Services will be added to the profile as well and the user may choose whether 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.

Adding Zones to xDNS Profiles

It's also very simple to add your critical, or even your non-critical zones to an xDNS profile as you choose. By simply selecting one or multiple zones and then clicking on the meatball menu, you can click on "Add to xDNS Profile" and then see if it's possible to add that zone.

You may receive warnings or errors which may need to be remediated before you can click Add. This will give you full confidence that everything is up-to-date and able to sync.

At this point you will have multi-vendor/multi-provider DNS redundancy.

Other Use Cases

Of course avoiding downtime is key, but there are a few other use cases for xDNS.

  • DNS service migration between clouds or on and off-premises
  • Prevention of downtime from DDOS and other attacks
  • Cost control and avoiding vendor lock-in

Give it a Try!

If you'd like to read more about xDNS, you can check out our whitepaper here. This whitepaper will not only tell you more about what xDNS will do for you, but also go into configuration details. If you'd like to give it a try, you can download a Free Trial of Micetro and get started anytime.