Azure DNS

One of the biggest challenges in migrating to Office 365 is managing DNS changes.

Most of my migrations have been environments that manage their own internal DNS, and allow either their ISP or a known DNS provider to host their external zones. And that’s perfect--that’s the way it should be. But it introduces another set of variables into the mix, and that is: who’s going to update your public DNS records at go-live, do they support all of the required record-types necessary for a full implementation, how long will it take that data to replicate and propagate, and whose neck do you wring when it’s not working and users are itching to get back online?

I’ve had 3rd party hosting providers guarantee that they could support a 5pm Friday implementation, then vanish over the weekend. I’ve had providers make changes, only to discover that their internal replication partners had failed, and that the Internet was only resolving off the failed partner. I’ve seen propagation take 72 hours. I even once had a provider tell me they couldn’t parse a color-coded email with requested DNS changes…10 days after it was sent.

About 3 years ago, Microsoft took a swing at bridging the gap. When you add a domain to your Office 365 subscription, you get a very helpful page telling you some DNS changes have to be made. Originally, you could just sort through the list of providers until you found yours, then get step-by-step instructions for making the changes yourself…assuming you had credentials and access.

It made my job easier, but it apparently didn’t make the job easy enough, so some very intrepid engineers further developed the tool to enable Office 365 to make changes to your DNS provider on your behalf.

But now MS has come back to the quandary from a different angle: most of the stuff you’re presenting to the Internet is under your control, and probably a fair bit of it is in Azure…why not manage the DNS directly from Azure? Why not host your public DNS zones where you host and manage your data?

Maybe more importantly, why wait up to 70 hours to use a DNS record?

Azure DNS is generally available as of September 26, 2016. Pricing is cheap @ $.50/zone for the first 25 hosted zones and $.40/million for the first BILLION queries.

Implementation is super stinkin’ easy. Probably the easiest DNS interface I’ve seen, honestly, but then I do live in the Azure portal all the time.

Start by finding “DNS Zones” under “More Services” in the left-hand column of the Azure Portal, and star that puppy:

Create a new zone:

Control the zone properties, view logs, set restrictions & tags:

Create new entries by clicking on “+ Record Set” and filling out a few base properties:

And you can verify your records immediately without making Azure authoritative, so you can test before changing your public DNS delegation(s). To do this, simply query one of the listed name servers in the “Essentials” portion of the zone overview page:

The first query above is asking the Internet-at-large to resolve the record, which it cannot do because super-awesome-testing-set.com is not generally available. The second query targets the first listed Azure Name Server, and succeeds.

This is awesome for me because it significantly reduces the complexity of an Office 365 migration weekend. I can’t even imagine how awesome it would be for a dev-ops team, or a DR scenario where an admin has to make an emergency IP change in the middle of the night.

And of course, 100% of this can be done from PowerShell, which means it can all be automated, enabling integration points with other Azure capabilities like Site Recovery orchestrations.

 

Comments