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 azurecoach.com
My requirements are the same that ill use my blog for the backend and ill use frontdoor in front of it with the testmike2.com 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 testmike2.com to be redirected to www.testmike2.com
- 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 mikesblogfrontdoor.azurefd.net.
Configure Azure DNS Zone
In the Azure Portal I will create a new DNS zone called testmike2.com
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 www.testmike2.com. 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 www.testmike2.com to that rule as shown below.
Points to note:
- I do not add the root domain testmike2.com 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 testmike2.com frontend domain as shown below:
With this rule we want to choose the redirect routing type and we will replace the destination host with www.testmike2.com as shown below. The rest of the parts of the url can be preserved.
Now we need to save our frontdoor designer changes.
Waiting
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.
Testing
Test 1 – using https://www.testmike2.com
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 http://www.testmike2.com
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 https://testmike2.com
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 http://testmike2.com
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:
- http://testmike2.com is resolving to our frontdoor directly and frontdoor spots its not HTTPS so our HTTPS redirect rule kicks in and redirects to https://testmike2.com
- https://testmike2.com then hits frontdoor again and our 2nd rule kicks in and redirects the root domain to https://www.testmike2.com
- https://www.testmike2.com then hits our frontdoor again and the forward to backend rule kicks in which hits my blog and returns content to the browser
Conclusion
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.
