Why Microsoft DNS Isn’t Appropriate for the JEDI Cloud

BY Hilary Vizel

Now that Microsoft has won the huge DOD JEDI contract, we're looking at the DNS options available for agencies looking to migrate.  While Azure DNS service is designed specifically for use in the cloud, it's far more likely that agencies will try to operate in the JEDI cloud using the Microsoft DNS they use on prem.

While this default 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 back-end, 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