JEDI Episode III: Why Microsoft DNS Isn’t Appropriate for the Cloud

BY Hilary Vizel

Reading the third installment of the JEDI series, you are. If you would like, you can check out our first post and second post to find out more about JEDI cloud.  

Last week, we looked into what JEDI means for your DNS. This week, we’ll be hopping in our starships and exploring all of the reasons why Microsoft DNS just won’t cut it in the JEDI cloud. While Microsoft DNS may be functioning just fine for your on-prem needs, you’ll soon find yourself running into problems if you use it for your cloud migration, and you’ll run into plenty afterwards.

Here is a breakdown of the reasons why Microsoft DNS isn’t the best choice for a cloud deployment.

It wasn’t designed with complexity in mind

What do Microsoft DNS and the prequel trilogy  have in common? They both sound good in theory, but don’t exactly work out in practice. A main issue with Microsoft DNS is its connection with  Active Directory – they were looking for a backend, and DNS was the technology that fit the bill. Unfortunately, many network administrators assume that this connection makes Microsoft DNS appropriate for large networks at scale, when Microsoft never intended to use it in the complicated network architectures of today.

This is not to say that Microsoft DNS can’t serve DNS records; it still works as it should in a simple, single-use environment. When your network starts heading into the cloud, you’re going to need something far more sophisticated to deal with new layers of complexity.

Raaaaahghuuhuhgh? (That’s Wookie for “Want

to learn more about JEDI cloud migration?”)

It leaves you stuck between a carbonite block and a hard place

When you start compute in the cloud, where do the DNS records go? Do you want them to live only in the cloud, or only on-prem, or everywhere? Ideally, everyone working across your network will have access to all of your DNS records. However, with Microsoft DNS you run into the dilemma of internal vs external access – if you’re storing your DNS on-prem, then it’s inaccessible for those working with the cloud, and vice versa.

DNS management becomes an issue the second your work has to go beyond on-prem.  How do you decide which part of your team gets to stay in the loop? Centralized DNS is really the best way for everyone to gain visibility into assets across on-prem and cloud environments. If everyone on the team is able to see what’s happening, and have the benefit of changes updating automatically, you save yourself (and your team) plenty of time and frustration – which you would inevitably run into with Microsoft DNS in the cloud.

It’s disparate

Microsoft DNS operates on disparate systems and disparate networks, which isn’t ideal if you’re trying to get your DNS under control. Only a centralized DNS management platform can sync with your entire ecosystem of cloud applications, empowering the DevOps cycle by allowing for the automation and API calls which Microsoft DNS cannot support. For anyone heading from on-prem to the cloud, it’s key to embrace centralized DNS. If you have automation, visibility and leveraging, then you’re also guaranteeing yourself another strong component of proper DNS management – a more secure environment.

The perfect prevention, of course, is Enterprise DNS. If you want to learn more about how this could ease your migration to JEDI cloud, fly on over to Cloud City.

Jabba the Hutt saying "Your decentralized DNS won't work on me, boy"

Hilary Vizel

Hilary has worked as a copywriter in digital advertising and the FinTech startup world. She is now working as a Digital Copywriter at BlueCat and learning more every day.

View more articles by Hilary Vizel