The other day I did a post about using Azure Frontdoor with GoDaddy managing the DNS and implementing a couple of scenarios and I mentioned that I would do a follow up post covering another way to implement the same requirements but this time using Azure DNS. For this demo ill use another domain I already had from when I used to run an Azure training course called

My requirements are the same that ill use my blog for the backend and ill use frontdoor in front of it with the domain and implement the following requirements.

  • I have an existing domain I bought from GoDaddy but I want to manage my domain in Azure DNS
  • I want requests to to be redirected to
  • I want all requests over HTTP to be redirected to HTTPS

My Azure front door instance is setup and is the same one as in the previous post called mikesblogfrontdoor with the address

Configure Azure DNS Zone

In the Azure Portal I will create a new DNS zone called

When it appears in the portal I will go to the nameserver list and copy all of the addresses for the name servers and copy them to Go Daddy. The ones in Azure are shown below and are at the top right of the DNS Zone resource overview page.

Next I will go to the Go Daddy domain settings page for your domain and find the nameservers section. It will look something like below

You need to change the nameservers for the domain to use the ones listed above for Azure so you will need to click the change button. You will get a list to add the nameservers from Azure and you should add all of them from Azure and save it like shown below.

Points to Note:

  • When you click the copy icon in Azure it adds a dot (.) at the env of the server name which you might have noticed in the earlier picture. I removed the dot when adding the names to go daddy
  • When you save it, it seems to take quick a long time for this to take effect and its not really clear what is happening behind the scenes so I personally waited a good few hours when I got an email from Go Daddy confirming the change had been made so im not sure if they do this manually behind the scenes or if they have an automated process which takes a while so bear this in mind.
  • Also note it seemed to take a while before the effects actually worked so just bear this in mind.

This is the only bit you need to change at Go Daddy on the domain, once you have changed the name servers most of the settings go away and you will be managing the records in Azure now.

Configure Azure DNS Zone

Next we will need to configure Azure DNS to setup a CNAME for our www subdomain and also an A record for the apex/root domain.

1. Setup CNAME

In Azure DNS you will need to click to add a new record set on the overview page of your dns zone. In the below picture you will see the settings for adding the CNAME. I have already set mine up which is why I get the red error that it already exists in this screen shot but I wanted to show you the configuration you need.

If the name is set as www then this indicates its for the www subdomain.

If you choose the set an Alias record then Azure DNS will allow you to choose the frontdoor resource as the one you will use for this record.

If you save to add this record then it will be added to your DNS.

2. Setup A record

Next we will add the A record for the root domain. If you click add record set in the overview you will again be presented with the screen to add a new record to the DNS. This time you want to choose A as the type of record.

Leave the name blank and it will show up in the list as @ which indicates it is for the root

You can also set an alias record again and choose the frontdoor resource.

The settings for adding this look like below.

3. Azure DNS Overview

If you want to check everything looks ok then you will see the overview screen looks like below when you are done, note ive put arrows to highlight the bits to be aware of.

Configure Frontdoor

Next up we need to configure Azure Frontdoor.

1. Add the www domain front end

On the frontdoor designer you will want to add a new frontend with the add button, then do the following:

  • On the custom host name field use the value This will then query your cname configuration.
  • Choose to enable custom HTTPS domain
  • Leave the TLS version
  • In my case im choosing to let frontdoor manage the certificate
  • You may do other settings like WAF and Session affinity. These are outside of the scope of this post so im leaving them at the default

Once you have OK’d the change if you open it again it will look like below:

2. Add the root domain front end

I repeated the above steps for adding the root domain (without www) as another front end, but this time I also didnt enable custom domain HTTPS either. When I OK’d these changes, if I open them up it should look like below:

I have now got both the root and www domains added to my frontdoor. In my list of front ends ill see them both registered. Note that in the picture below I also have other front ends registered from the previous post but you can see the new ones added.

You may choose to save your changes here if you want.

3. Add the HTTP to HTTPs routing rule

In the previous post I walked through how to setup the http to https routing rule. I am now going to modify that rule to add HTTP to HTTPS routing for the two new domains as shown below.

If you remember from the first post I added a redirect with the protocol changed to HTTPs and preserved everything else as shown below.

4. Add the forward to backend routing rule

Next up I am going to modify the rule called 02-Forward-To-Backend which forwards traffic to the backend. I am now going to add the domain to that rule as shown below.

Points to note:

  • I do not add the root domain to this rule because we are going to add a new rule in a minute specific to the root domain.
  • This rule is only capturing HTTPS traffic because the earlier HTTP to HTTPS rule would have redirected any traffic we sent over http

If you remember from the first post the routings for this rule was to send traffic to the backend using HTTPS as shown below.

5. Add the root domain to www routing rule

Next we need to add a rule to handle the root domain. We will add a new rule called 01-Redirect-TestMike2-Root-to-WWW this rule will capture traffic on the root domain and redirect it to the www subdomain. We dont need to worry about http traffic here as the earlier rule will have redirected any non https traffic.

We will add this rule only looking at the frontend domain as shown below:

With this rule we want to choose the redirect routing type and we will replace the destination host with as shown below. The rest of the parts of the url can be preserved.

Now we need to save our frontdoor designer changes.


One of the challenges with this approach is it took a while before it started working. I am not fully clear if it was due to the Go Daddy side of things or the Azure DNS or if it was something on my client machine. Just be aware that it did take a while to all take affect.


Test 1 – using

The aim of this test is to check out default scenario works. If this doesnt work then none of the other tests will work. I pop the url in the browser and get the below in the network trace. We can see that the test worked first time and frontdoor responsed with content from the backend.

Test 2 – using

Next up I hit up the non https url and get the below result which shows frontdoor redirected my to the https url and then I was served the content from my blog

Test 3 – using

This time I will use the root domain name without the www subdomain but will use https. You can see I will get redirected to the https address on the www subdomain. Because it was already on https only the 2nd rule we have kicked in. This was the one which redirected from the root domain to the www sub domain.

Test 4 – using

Finally I will use the root domain without https. This is the test that differs in behaviour from the previous post. If you look at the trace below you will notice that there are 2 redirects.

In the earlier post Go Daddy had used a forwarding rule to redirect our sub domain to the www subdomain and set https in one go.

Here Azure DNS doesnt have that forwarding option so on frontdoor we configure it differently because we can now add both the www domain and root domain because its an Azure managed DNS. Whats happening here is:

  1. is resolving to our frontdoor directly and frontdoor spots its not HTTPS so our HTTPS redirect rule kicks in and redirects to
  2. then hits frontdoor again and our 2nd rule kicks in and redirects the root domain to
  3. then hits our frontdoor again and the forward to backend rule kicks in which hits my blog and returns content to the browser


We now have two posts showing two of the ways you can configure Azure Frontdoor to work with https and www mapping from the root domain which work depending on how you want to manage your DNS.

I think for me there were significant benefits in the 1st blog post because the amount of time it took for the domain nameservers to swap over to Azure and for the solution to then work was significant and would be a concern for migrating a side which already existed. I am not sure that it was in my control to make this happen quicker but maybe someone has thoughts to add on this topic.

At the end of the day, both approaches worked and longer term I guess it boils down to where you are most comfortable managing your dns but dont forget that migration time for option 2.


Buy Me A Coffee