Azure DNS for Exchange Administrators (Part 3)

by [Published on 14 April 2016 / Last Updated on 14 April 2016]

In the previous two articles of this series, we went over the process to delegate DNS to Azure DNS and how to manage zone records using PowerShell. In this last article we are going over the process using Azure Portal.

If you would like to read the other parts in this article series please go to:

Azure Portal is great and has tons of features and it is really easy to use, however it does not provide us the same flexibility when using PowerShell. A good example is that nowadays (at least by the time this article was being written) we are not able to create the zone using Azure Portal and only that  task has to be done using PowerShell (we demonstrated the process on the first article of this series). After that, all management of Azure DNS can be done through the Azure Portal.

Azure DNS is based on Azure Resource Manager deployment model and such model uses Microsoft Azure portal to manage its resources. Logged as administrator on Microsoft Azure Portal (, we can click on Resource Groups and a list of all Resource Groups will be listed. Click on RG-DNS which was the name that we defined for the Resource Group (Figure 01).

Figure 01

In the new blade (Figure 02), we will have a list of all existent DNS Zones under Resources section. In this blade we are able to delegate permissions (Item 1), and Settings (Item 2) at Resource Group level, and those settings are: Audit Logs, Resource Costs, Alerts, User, Tags and so forth. Some of those settings we also have at the domain level and that allows more granularity.

Figure 02

When we click on any given domain from the previous blade, a new blade will show up with the domain information, as shown in Figure 03. We can create, delete, get more settings for this given domain and refresh (Item 1). We can also see all the Name Servers (NS) which is the information that we need to change in our Domain Name Registrar to move the domain to Microsoft Azure.

On the same picture (Figure 03), we have a list of all DNS entries listed. The administrator can click on any given entry (Item 3), and a new blade with properties will show up on the right side, the administrator can change/delete entries.

Figure 03

In order to add a new entry, just click on Add (Figure 04), and a new blade with several options (Name, Type, TTL and pertinent information for the type of record) will be displayed.

Figure 04

Auditing DNS changes…

There are several advantages when using Azure DNS, but the built-in Audit logs is one of the top 3. We can check the Audit Logs from the Resource Group level or from the domain level. In the example below (Figure 05), we are going to click on All settings at the Resource Group level, and then Audit logs on the new blade.

Figure 05

The Audit Logs has an extensive set of tools to help the administrator and the security team of your company. For starters, we can filter all the information by clicking on Filter (Figure 06). The chart showing all events per hour can be managed through the button Hide Chart.

Figure 06

If we look right below the chart, we will see a detailed list of all events related to DNS. By just glancing at it we can see the Operation, Level of the event, status and when that happened (Figure 07, on the left side which is the Events blade). If we click on any given entry on the left side we will have detailed information on the new blade that will show up on the right side. Besides the information about the event we have the caller which means who was responsible for such change.

Figure 07

In case of an error, the detailed information (Figure 08) is able to provide the error that was displayed to the end user. I was testing a script and that was the output that I was getting using PowerShell. Another nice piece of information is the IP address from where the change was originated.

Figure 08

Delegating DNS administration…

Another killer feature of Microsoft Azure and Azure DNS is the ability to delegate administration. The beauty is that depending on how your integration between on-premises and Microsoft Azure is configured, you can have SSO (Single Sign-On) or at least sharing the same password between the environments.

That is a huge security improvement, nowadays when the administrator that manages the DNS leaves the company, his replacement has to call the DNS registrar, find out a way to reset the password in order to manage the Public DNS. Using Microsoft Azure is just a matter of delegation, and when the current owner has his account disabled, we know for sure that account will no longer have access to manage DNS.

The delegation may be done at two different levels: at Resource Group level which any delegated account has ability to manage all domain zones of that Resource Group, or a more restrictive way, at the zone level where the delegated account is able to manage DNS records only on that specific zone, and the other zones will not be even visible to the same account.

In order to delegate the administration of our domain zone to a user, go to the zone and then click on All Settings/Settings and then click on Users on the blade located on the right side (Figure 09)

Figure 09

In the new Users blade (Figure 10), a list of all existent users that are able to manage the current zone will be listed. In order to create a delegation, click on Add (Item 1), then on the new Add Access blade, click first on Select a role (Item 2), and on the new blade Select a role, click on DNS Zone Contributor (item 3), back to the Add access blade, click on Add Users and select a user from the list, and finally click on Okay.

Figure 10

The final result will be similar to Figure 11, where a new user (in this case has the role of DNS Zone Contributor.

Figure 11

In order to test the delegation that has just occurred, logoff with the current user and use the new delegated account. In Figure 12, we can see that the user has a single resource being listed although the Microsoft Azure subscription has tons of resources. The user is not aware of their existence due to the delegation in place.

Figure 12

Having delegation at zone level is useful when you have test domains and developers trying new stuff, and we can allow them to manage and play around with non-production domains.

The user has the DNS Zone Contributor role and that role is not able to assign permissions, if he tries (Figure 13), we will notice that there is no button on the Users blade to add accounts.

Figure 13


In this final article of our series about Azure DNS for Exchange administrators we explored the Azure Portal managing DNS Zones, Auditing and Security delegation.

If you would like to read the other parts in this article series please go to:

See Also

The Author — Anderson Patricio

Anderson Patricio avatar

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at,, and Anderson (Portuguese).


Featured Links