Azure App Service: How to configure a custom domain
[Updated on 2nd May 2016]
Azure App Service provides a default hostname on site creation. It is of the format <SITENAME>.azurewebsites.net. So when I create a website called Kaushalz then the hostname would be Kaushalz.azurewebsites.net.
Now the users can buy a custom domain via Azure portal. See this article: https://azure.microsoft.com/en-in/documentation/articles/custom-dns-web-site-buydomains-web-app/
If you decide to buy a custom domain externally then you would have to configure it. There is one requirement though, the pricing tier of the Web App needs to be in either SHARED or higher tiers .
There is an article on www.windowsazure.com on how to configure custom domain. Below is the URL:
https://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name
However, I have still seen few customers running into issues in spite of this. In this post we will discuss adding custom domains to a MAWS site in detail.
There are 2 ways to configure domain names:
- Add an A Record.
- Add a CNAME.
NOTE: A records map a domain name to one or more IP addresses. They are used when the IP is not bound to change. Example: kaushalz.com points to 65.52.168.214. On the other hand CNAME (CANONICAL NAME) records map one domain name to another domain name. It is typically used when there are multiple hosted services. Example: ftp.kaushalz.com or www.kaushalz.com points to kaushalz.com |
I have purchased the domain kaushal.co.in from GoDaddy. Here kaushal.co.in is also referred to as ROOT/NAKED domain. By design, ROOT domains have to be an A record, so they will point to an IP always.
Anything that is prefixed before this is referred to as sub-domain. Examples are www.kaushal.co.in, ftp.kaushal.co.in, *.kaushal.co.in.
As per DNS best practices, it is always recommended to point your sub-domains to CNAME records. This is because IP address can change dynamically for certain sites and this is not apt in case of an internet facing website.
STEP 1: Create a Website and scale it to SHARED/BASIC/STANDARD |
- In the Azure portal create a web app and scale this to a minimum of SHARED tier in order to be able to configure a Custom Domain.
- Refer this link for scaling Microsoft Azure Web Sites: Configure your web sites for basic, shared or standard mode
Once the web app has been scaled to SHARED or higher tier, we can proceed further.
STEP 2: Configuration on the DNS Service Provider /DNS Server |
In the Azure portal, select the web app and under settings browse to Custom Domains and SSL. In the Custom Domains and SSL blade, click on Bring External Domains. This will launch a new blade as shown below.
It specifies an IP (Front-end VIP) which is to be used while configuring A Records on the DNS server. Additionally it also suggests that before we add custom domains for the site, Azure needs to verify that the user is authorized to use the domain name or not.
Add an A record pointing to the IP as seen above.
NOTE: Entering " @ " for the host name is the same as entering your domain name, minus the "www". Entering "www" for the host name is the same as entering your domain name, including the "www". To create a wildcard A record, enter an asterisk (" * ") for the host name. The wildcard makes the server respond with the IP address specified instead of an error, if the subdomain queried does not exist within your zone file. |
Additionally for the ROOT DOMAIN (kaushalz.org) you will have to add another CNAME entry. Here you will point awverify.kaushal.com to awverify.kaushal.azurewebsites.net.
My DNS service provider is GoDaddy, so I need to point www to kaushal.azurewebsites.net. Below is a snapshot of my DNS Manager. I have a CNAME entry pointing to the <sitename>.azurewebsites.net.
NOTE: Above step is only for verification purpose. Once the ROOT DOMAIN (kaushalz.com) has been mapped to the site in Azure Portal, the awverify entry can be removed. |
STEP 3: Map the domain name in the Azure Portal |
Once the DNS entries have been made the DNS record propagation can take time. This depends on the DNS Provider. Once the records have been propagated, you could proceed with mapping this domain name to the specific website in Azure.
In the Azure portal, select the web app and under settings browse to Custom Domains and SSL. In the Custom Domains and SSL blade, click on Bring External Domains. This will launch a new blade as shown below.
Enter the domain name and give it some time to verify. If it succeeds, then you would see something as shown below:
If the verification fails then you would get a corresponding warning message:
Verifying DNS Propagation
You can verify the DNS propagation by going to this URL https://digwebinterface.com/
Specify the hostnames in the textbox and click on Dig. Verify the results to confirm if the recent changes have taken effect.
NOTE: The propagation of the DNS entries takes up to 48 hours or sometimes even more than that. In these cases you may have to wait for the propagation to succeed. The user needs to ensure that the awverify entry resolves to the corresponding entry which has been added in the DNS server while performing the look up. |
I have observed that the DNS propagation is quicker with GoDaddy. This is my personal experience.
MIGRATION FROM ON-PREMISE PRODUCTION TO MAWS
Now consider a scenario where the user wants to migrate his production website, which is on premise, to MICROSOFT AZURE WEB SITE, without affecting any of his existing sites. He would want to map the hostname (verification) to MAWS and then would modify his DNS records. What should he do?
For this he would have to create CNAME records on the DNS service provider as shown below:
HOST |
RECORD TYPE |
POINTS TO |
awverify.kaushalz.org |
CNAME |
awverify.kaushalz.azurewebsites.net |
awverify.www.kaushalz.org |
CNAME |
awverify.kaushalz.azurewebsites.net |
We add 2 entries:
- One for the ROOT DOMAIN (kaushalz.com)
- One for the domain containing WWW (www.kaushalz.com)
Below is a snapshot on the DNS Provider (GoDaddy):
After adding the above 2 entries you could map the domain name to a site hosted on AZURE.
DNS VERIFICATION LOGIC
The Microsoft Azure Web Sites DNS verification logic has 2 steps:
- First we try to validate using CNAME. That means we look whether the custom domain provided is a CNAME record. If it is, then it is expanded. If the next record in the chain is also a CNAME, it is further expanded. The expansion goes on until we get an A record or something ending with "azurewebsites.net". If it is found that the custom domain is eventually pointing to <SITENAME>.azurewebsites.net, it is verified that the <SITENAME> is really the site for which the custom domain is being added and verification is done.
- If for some reason the validation of the CNAME fails, it proceeds with the alternative validation. That is useful for users when they want to just test their sites, but not really point the record to AZURE, or if it is a naked domain (some DNS registrars don't support a CNAME for such hostname). The alternative validation puts "awverify" in front of the provided hostname and follows up the similar logic as above. The only difference is that this time the target has to be the awverify.<SITENAME>.azurewebsites.net.
TXT records are also supported. It is another alternative, because some DNS registrars don't support CNAME's pointing to invalid hostnames (the "awverify" version doesn't truly exist). So one can also create just a TXT record instead of a CNAME (otherwise it is completely same setup as in validations above).
Thanks to Petr Podhorsky (DEV on MICROSOFT AZURE WEB SITES) for sharing the DNS verification logicwith us.
Comments
Anonymous
December 02, 2013
Thanks for explaining so well. Helped a lot!Anonymous
February 28, 2014
The comment has been removedAnonymous
March 14, 2014
The comment has been removedAnonymous
March 15, 2014
Never mind, sorted now - just needed to have a bit more patience with the CNAME update propagation!Anonymous
April 12, 2014
Thanks so much for this post! I was wondering how to resolve this issue and your article helped greatly!Anonymous
May 10, 2014
Thanks so much, very helpfulAnonymous
May 14, 2014
That was so helpful. All of my azure websites were configured incorrectly and thanks to you article I could rectify all of them...Anonymous
May 29, 2014
Very helpful - especially the handling the root domain part.Anonymous
June 25, 2014
http://www.kaushalz.com/ Is giving 404, but http://kaushalz.com is working (you may have some PHP errors) Same is happening on my site with www as prefix - any idea?Anonymous
June 27, 2014
I have removed my mapping for www.kaushalz.com. So I expect the 404 error. Regarding your site I'm not sure. Could you share your domain name?Anonymous
December 04, 2014
Great tutorial. i was having trouble because I had not mapped www as well.Anonymous
February 04, 2015
This is still helpful. I'd love it if this complete example was in the documentation. Adding a CName for awverify.www (as well as awverify) was the missing piece of the puzzle for me...Anonymous
March 06, 2015
on Manage Domains under the DASHBOARD management page, you also need to add your domain name e.g example.com. Heck no where they mentioned this.Anonymous
March 28, 2015
It is very very useful for me .I really say thanx to you.Anonymous
April 02, 2015
Great article! Just the information I was looking for regarding the 'awverify' bit.Anonymous
May 31, 2015
Great article and nice screenshots, Kaushal!Anonymous
June 10, 2015
This is a nice article....very helpful...thanks a lot. <3Anonymous
August 06, 2015
The article helped in setting up the custom domain really quickly. Thanks a lot, Kaushal!Anonymous
August 27, 2015
I understand that the Azure websites support TXT records and you mentioned. I would need the TXT value to map on to the custom domain. I can see CNAME value and A record which is the IP address. Any idea how can I find the TXT value?Anonymous
September 22, 2015
The solution covers all the possible questions. I was able to resolve the issue by just following the instructions. Cheers!Anonymous
December 17, 2015
Thanks you so much Kaushal. You are a blessing in disguise :)Anonymous
March 25, 2016
Very helpful! Thanks. I have a question. If I want to redirect a "live" subdomain, how can I do that with minimum interruption? If I set up both CNAME and AWVERIFY records then it shows Azure 404 page till the propagation happens and I bring the custom subdomain to Azure. Can I just set up awverify first and wait for its propagation to just add the custom subdomain to Azure? Or, it always wants the CNAME record too to set it up. If yes, that's a problem.- Anonymous
January 23, 2017
Unfortunately, there is only so much you can do control this. The best way to do this is to map the awverify entries so that the domain is mapped ot azure and then update the CNAME or A records to point to the Azure front-ends. Do this during non-business hours to avoid user inconvenience.
- Anonymous
Anonymous
April 19, 2016
thanx buddy. helped a lotAnonymous
May 02, 2016
Hi i have only on answer. I have configured 1 forest in Acitve Direcory Windows server 2012 on azure cloud virtual machine. If i want to integrate my forest installed on Azure active directory for single-sign on on office 365 and other cloud app it is possible without public domain?Anonymous
August 31, 2016
Excellent article. Thanks for sharing and especially for updating it.Cheers,SteveC.Anonymous
January 31, 2018
Can you please explain how to add a 2nd subdomain? For instance, following this instructions I was able to setup correctly the www.mydomain.com with app1. Now I want to relate app2 to mydomain but cannot add cname or another verify because it tells me the records are repeated. I'd appreciate if anyone can shed some light.- Anonymous
February 12, 2018
Are you planning to add the same domain to 2 different web apps? If Yes, then this is possible only if you are using a Traffic manager to offload requests to both of these web apps. If you are facing issues then create a support ticket and someone should be able to help you.
- Anonymous