In Azure App Services I run a web app handling multiple tenants web traffic. Most of the traffic goes to one single slot. But a few run in separate slots. I wish to consolidate all traffic to the single slot that is accepting traffic with a wildcard expression and consequently removing slots running specific tenants. Moreover ARRAffinity is used.
Example
someapp.somehostname.com (somaapp slot)
*.somehostname.com (production slot)
Preconditions
The DNS-records are external to Azure. Azure DNS is not used.
As a previous post suggest, removing the CNAME has no impact on which slots that servers incoming requests. It's still the same slot serving the requests. Remove CNAME after Azure has verified the domain
The main slot (production) is configured to receive 100% of the incoming traffic per previous configuration.
Questions
Should I remove the custom domain and expect the main slot to take over the traffic?
Or, should I add a new custom domain "someapp.somehostname.com" to the production slot?
Or both of the above?
To be honest, not sure what you are trying to do. However, I think these points might help you when you add a custom domain in the app service.
Deployment slots are live apps with their own host names. You have individual hostnames for each app on each own slots. The SSL certificate in SSL Binding should match the selected custom domain in each slot. If you want to configure the custom domains as your example,
app1.somehostname.com (somaapp slot)
*.somehostname.com (production slot)
For example, you'll create the DNS records like this on Azure DNS(or your DNS zone provider).
After my validation, If you remove the awverify.app1 CNAME in the DNS zone, you should still access the web app in the separate slot with hostname app1.somehostname.com because the awverify.app1 is used for domain validation and hostname app1.somehostname.com still can be resolved to your separate slot as there is a CNAME app1 mapping. The result from the DNS checker here.
But, if you remove the CNAME records both app1 and awverify.app1 for the hostname app1.somehostname.com, the hostname app1.somehostname.com will be resolved to your production slot as it has wildcard custom domain.
In conclusion, If you want to access the web app in the slot, you should have configured a CNAME record mapping to that hostname of the slot URL.
Let me know if you need further help.
If I recall correctly removing the one CNAME without a wildcard made that particular slot to stop respond to web requests. It didn’t automatically redistribute the traffic, I think. Additionally, the ARRAffinity token was set.
The solution for me turned out be the following; remove both of them add and the wildcard one again. Obviously this isn’t something you want to do during peak hours.
Related
Let me get this out of the way, I am not that familiar with DNS setup. But I am wondering if I can have this setup. I cannot test this right now because I control the our Azure portal but not the domain name provider.
We will have 2 subdomains. For example, api.contoso.com and app.contoso.com
We currently have a single Azure App Service Plan with two apps inside. One is the frontend SPA, and the other is the backend.
Checking the IP address and Custom Domain Verification ID of the two services, they are the same! So I am wondering if the setup of the two subdomains is possible. If not I'll consider moving out one of the App Service to its own App Service Plan or maybe Just map a single custom domain to the frontend. Any tips or suggestion?
Yes this is completely possible and a very standard setup. You will use CNAME records in your DNS setup which means you won’t use the IP address of the VM that your app service plan is on. Instead a CNAME DNS record maps your custom domain to another domain - in this case the domain name of an app service.
You will configure a different custom domain on each app service (and ideally a certificate to protect it).
E.g. your DNS might look like this:
app.contoso.com CNAME myapp.azurewebsites.net
api.contoso.com CNAME myapi.azurewebsites.net
I.e. when a request is made for a domain on the left it will be forwarded to the domain on the right.
When a request is made for either of your custom domains the custom domain will be in the host header. This request will be routed to the app service gateway which will look at the host header in order to know which VM to route the request to and once on the correct VM which app service to serve the actual request.
Once you have the above setup you can query the DNS system to see the complete route that a request would take, e.g.:
nslookup app.contoso.com
may return:
Name: waws-prod-xyz-123-1234.uksouth.cloudapp.azure.com
Address: 99.99.99.99
Aliases: app.contoso.com
myapp.azurewebsites.net
waws-prod-xyz-123-1234.uksouth.cloudapp.azure.com
With this command you'll see the actual VM that your app service plan is on (I've made up the IP and VM name here!).
Background
I have two websites:
- web1.azurewebsites.net
- web2.azurewebsites.net
I have added a traffic manager called webtm.trafficmanager.net.
web1.azurewebsites.net is configured with a custom domain web.example.com. I've also added a wildcard SSL certificate to it (i.e., *.example.com). If I request web.example.com it serves the website without any issues.
Requirement
I need to setup Traffic Manager on top of these two sites. So, if web1.azurewebsites.net is down/offline, then Traffic Manager can switch to web2.azurewebsites.net automatically.
Implementation question
I've read these SO answers (SO 1, SO 2) and this docs article, however, I have some doubts. I would really appreciate if someone can confirm my understanding outlined below, please?
Step 1: I understand that I'll have to update DNS records to something like: web.example.com. 60 IN CNAME webtm.trafficmanager.net.. Remove other DNS/CNAME records that point web.example.com to web1.azurewebsites.net.
Step 2: I'll need to remove the current custom domain mapping from web1.azurewebsites.net and then re-add it. Set custom domain to web.example.com and the CNAME configuration will show the traffic manager endpoint. No DNS changes required in this step?
Step 3: Add a custom domain to web2.azurewebsites.net set the custom domain to web.example.com and the CNAME configuration will show the traffic manager endpoint. No DNS changes required in this step?
Step 4: No changes to the SSL certificate added to web1.azurewebsites.net.
Step 5: Add the SSL certificate to web2.azurewebsites.net.
Now, accessing https://web.example.com should hit the traffic manager. It will see that web1.azurewebsites.net is online, so it will direct users to that. If web1.azurewebsites.net goes down, it will auto redirect users to web2.azurewebsites.net.
Thanks!
Your steps are mostly correct. What you want to do is to follow this document---Configure a custom domain name in Azure App Service with Traffic Manager integration
In step 3 and step 4, the traffic manager domain name will show under CNAME configuration. Select it and click Add custom domain. No other steps are required.
If a record is already in use and you need to preemptively bind your
apps to it, you can create an additional CNAME record. For example, to
preemptively bind www.contoso.com to your app, create a CNAME record
from awverify.www to contoso.trafficmanager.net. You can then add
www.contoso.com to your app without the need to change the www
CNAME record. For more information, see Migrate an active DNS name to
Azure App Service.
You also could see the full steps in this blog. In this blog, it uses a second web app in a different subscription, so it selects an external endpoint for that. If your first web app and your Traffic Manager instance are in the same subscription, use an Azure Endpoint, as you would normally, and choose the web app in that subscription.
Let me know if you face any questions.
my team and I are currently exploring using Azure static site blobs and CDN endpoints to host several web apps.
We have successfully deployed our static files to the blog storage and our entire test app loads on both the primary (name.abc.web.core.windows.net) and CDN (name.azureedge.net) endpoints. When it comes to mapping a custom subdomain via the “cdnverify” temporary step, however, I am unsuccessful.
I have very carefully followed and quintuple-checked all steps in the support doc "Tutorial: Add a custom domain to your Azure CDN endpoint" (here).
This is my current DNS config (via Namecheap).
When I skip the cdnverify step, e.g. assign the azureedge CNAME value directly to a host called “v2”, and add that as a custom domain in my Azure portal CDN blade, the subdomain begins loading the CDN endpoint and can even have a CDN-managed HTTPS cert deployed with no manual verification. A dig command to this host (v2.ourdomain.org) finds an expected response (view here).
Here's the rub, though. If I assign a CNAME host of “cdnverify.static” to “cdnverify.name.azureedge.net.” and add it as a custom domain in the portal’s CDN blade, however, this secondary subdomain never loads our endpoint, and cannot deploy an HTTPS cert. The Azure portal verified this host when added to the endpoint and a dig command to “cdnverify.static.ourdomain.org” shows this answer, which looks good.
A dig command to “static.ourdomain.org” returns no answer and a ping command says “unknown host”. This is expected since I’ve not created such a record yet, and so I am wondering how we’re meant to ensure this subdomain is verified as per the “Verify the custom domain” section in the above-mentioned doc.
It’s very important for us that the cdnverify host works and can be assigned a certificate before we permanently re-locate our domains as these apps are already in production. At this point, I am at a loss over what to try next. If possible, I’d love to know what step(s) I am missing, or what can further be done to diagnose the issue.
Many thanks to anybody who might have some advice!
The cdnverify subdomain is to create a temporary CNAME mapping to avoid interruption of web traffic. With this method, users can access your domain without interruption while the DNS mapping occurs. If you have not any existing web app work, you can skip the cdnverify step.
From your description, "a dig command to cdnverify.static.ourdomain.org shows this answer, which looks good." It indicates that the cdnverify host works and you have verified that. You just need to associate the custom domain with your CDN endpoint.
In this step, you enter your custom domain like static.ourdomain.org, including the subdomain. Do not use the cdnverify subdomain name.
After you have added the custom domain static.ourdomain.org successfully in the CDN endpoint.
At this point, your custom domain has been verified by Azure, but
traffic to your domain is not yet being routed to your CDN endpoint.
After waiting long enough to allow the custom domain settings to
propagate to the CDN edge nodes (90 minutes for Azure CDN from
Verizon, 1-2 minutes for Azure CDN from Akamai), return to your DNS
registrar's web site and create another CNAME record that maps your
subdomain to your CDN endpoint. For example, specify the subdomain as
www or cdn, and the hostname as .azureedge.net. With
this step, the registration of your custom domain is complete.
After you have completed the registration of your custom domain, verify that custom domain references your CDN endpoint.
Finally, you could freely remove the cdnverify CNAME record in your domain provider as it was necessary only as an intermediary step..
Ref: https://github.com/uglide/azure-content/blob/master/articles/cdn/cdn-map-content-to-custom-domain.md#how-to-map-custom-domain-to-content-delivery-network-cdn-endpoint
In a bid to reduce our Azure costs we are looking to remove unused resources.
We have an app service that is part of a traffic manager setup, reachable when users type x.com in their browser. Two app services exist:
eus-x-com.azurewebsites.net
wus-x-com.azurewebsites.net
These are added to a traffic manager profile, and when they were added to TM they were configured to have custom domains to both be x.com
DNS for x.com points to x-com.trafficmanager.net, the name of the traffic manager endpoint that manages these two sites.
This means there is now:
//sites under Traffic Manager control of x.com
EastUS App Service Plan 1
eus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
WestUS App Service Plan 1
wus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
//sites not assigned to a traffic manager
EastUS App Service Plan 2
y-com.azurewebsites.net (with custom domain y.com -> y-com.azurewebsites.net)
z-com.azurewebsites.net (with custom domain z.com -> z-com.azurewebsites.net)
After some years it seems that eus-x-com.azurewebsites.net has never failed and it's not used much, so we're looking at having East US Service Plan 2 host one instance of x.com, plus the other sites it hosts and getting rid of the traffic manager, and the east/west service plan 1 leaving just service plan 2
The idea was to:
create a new app service in EastUS App Service Plan 2 called x-com.azurewebsites.net
deploy the code to it so it will work
give it a custom domain of x.com (i.e. the equivalent of adding a host header in IIS)
change DNS to point to x-com.azurewebsites.net so that traffic gradually starts coming to the new web app as DNS servers around the world update
delete the whole TM infrastructure at some point
I hit a problem: even though I can validate DNS domain ownership I come up against a restriction that two different app services, even in different app service plans, cannot have the same custom domain setting unless they're part of a traffic manager setup. I get a "x.com custom domain is already in use on an app service eus-x-com.azurewebsites.net" when trying to add a custom domain of x.com to x-com.azurewebsites.net
This is a bit annoying as I foresee no reason why it should be technically impossible to have the same custom domain on two app services in different plans, if all it is (in old IIS terms) is a host header/binding; which app service is actually in use depends on which IP address traffic arrives at based on DNS. The custom domain binding is a routing mechanism to know which app service to pass traffic to when it arrives at an IIS hosting multiple sites. While I think it sensible that azure prevents multiple app services within the same plan from having the same custom domain assigned, I cannot see how it is logical to prohibit app services in different app service plans from having the same custom domain setting
Instead I looked at doing:
create a new site in EastUS App Service Plan 2 called x-com.azurewebsites.net
deploy the code to it so it will work
add it to the traffic manager so that I can then set the custom domain of x.com on it (because it's allowed to re-use custom domains if sites are on the same traffic manager profile)
change DNS so that traffic gradually starts coming to the new web app directly, bypassing TM
delete the whole TM infrastructure at some point
This is where I get another problem:
Two app services in the same region (regardless of whether they're on a different app service plan) cannot belong to the same traffic manager profile. Even though these sites are on different app service plans, those plans are in the same region (EUS) and the error message in the portal is:
Traffic manager configuration is not valid because one or more domains do not belong to subscription 'xxx'
A github discussion from an MSFT employee said that this is a bogus error message that should be interpreted as "you can't have two app services in the same region be part of the same TM". You can have it if one of them is an external endpoint, but then it doesn't add the custom domain for you, which is the only thing I wanted out of adding the new site to TM
I then found out that I can, instead, edit the TM and change where the endpoint points to:
//existing setup
TM
east-us-x-endpoint -> eus-x-com.azurewebsites.net
west-us-x-endpoint -> wus-x-com.azurewebsites.net
//proposed setup
TM
east-us-x-endpoint -> x-com.azurewebsites.net //edit it to point to the new x-com
//delete the west US one
I've done this, and edited the endpoint to target a different app service. Though the portal says the change has been made there are problems:
the traffic manager is definitely still sending traffic to the old app service, because the site works even though the new app service doesn't have any code on it yet
stopping the old eus-x-com.azurewebsites.net app service (not configured in any TM endpoint any more) causes the web site to stop working with HTTP 503
Things might have worked out if I hadn't deleted west us already. Though not ideal because it was slower (database in East US) I could probably have deleted eus-x-com out of TM and let wus-x-com take the load, then added x-com (which is in EUS) to TM and made it priority 1, it would have got a custom domain, all good.. except there is no west us setup any more. I might have to add it back
I'm now stuck; I basically need two app services, in the same region, on different service plans, to have the same custom domain for a while so I can switch over the DNS then dismantle one of them. Or I need another way to set up a new app service so that it ready to take traffic, get all traffic to start going to it, and then remove the old setup
What steps can I take to get a new app service up and running, give a custom domain to it and then switch DNS over so that all traffic goes to the new site, without causing any downtime?
As far as I know, either the DNS name of Traffic Manager or App service is globally unique. We can not have the same custom domain to use for two different app services. Read ICANN.
So you still need a load balancer to route upper DNS level incoming traffic for your backend app services when you want to use the same custom domain. I also don't think you can switch DNS for app services in Azure without traffic manager. If you want to route traffic to app services in the same region, you could use nested Traffic Manager profiles. Read this answer for more details.
In the azure tutorial for setting up a custom domain for the azure front door, few areas got me confused
A brief period of downtime for the domain can occur.
A custom domain and its sub-domain can be associated with only a single Front Door at a time.
The custom domain also must have routing rule with a default path ('/*') associated with it
We have a production site running that has multiple subdomains. I need to map one subdomain with one front door. For example, we have https://web.contoso.com, https://api.contoso.com, https://admin.constoso.com. We have created a frontend for APIs services. https://busymonk.azurefd.net.
Now we need to CNAME only api.contoso.com with busymonk.azurefd.net. Is the said domain downtime going to occur for the main domain and other subdomains?
How I should add the routing for the custom domain. Even this example got me confused. Do I need to add routing between custom domain and my backend pool, or do I need to make a backend pool of https://busymonk.azurefd.net and then add routing between api.contoso.com to busymonk.azurefd.net?
When you need only api.contoso.com with your CDN endpoint, only the subdomain api.contoso.com may have downtime.
To avoid interruption of web traffic, you could first map the temporary afdverify sub-domain. With this method, users can access your domain without interruption while the DNS mapping occurs.
Source Type Destination
afdverify.api.contoso.com CNAME afdverify.busymonk.azurefd.net
If you have verified that the afdverify subdomain has been successfully mapped to your Front Door. Then you could map the permanent custom domain. After this, you could delete the temporary afdverify subdomain CNAME record.
Once you add the custom domain for api.contoso.com with the front door. It's up to you. You only need to make sure there is a path from the frontend hosts to the backend pools via valid routing rules.
For example, to make the custom domain api.contoso.com work, you need to add a new routing rule or change existing routing rule to point to the domain api.contoso.com as the frontend hosts with a default path /* associated with it and select the existing the backend pool of your backend web app host like app service xxx.azurewebsites.net.
Hope this could help you.
Be aware that if you use the afdverify approach and enable HTTPS using an AFD managed certificate, you'll be waiting an excessive amount of time for Digicert to validate the domain for certificate provisioning (24+ hours). It appears to be a manual process on their end, and if your domain's WHOIS registrant email is not displayed b/c it's private, then you'll need to receive email at X#customdomain where X = admin, administrator, hostmaster, postmaster, or webmaster. You'll be better off opening a ticket with Microsoft support over it, they'll work directly with Digicert to get your certificate provisioned.