I'm trying to set up multiple custom domains for our web app.
Basically it's a dynamic website that checks the url and displays specific content based on the customer determined by the url.
Let's say we have contoso.com our customer.
In order for the website to work we need and A record poiting to our server ip provided by Azure and a TXT record poiting to mywebsite.azurewebsites.net.
But this is not enough, we also have to go to Azure portal, and add the Hostname there, 'contoso.com', otherwise our customer will get a 404 error.
My question is, can we tell Azure, our web app, to accept any hostname, not only the ones defined in the Azure portal?
I know we can add hostnames via powershell or rest api, but we have thousands of customers and is just too much to maintain.
No that's not possible. Just think, you can have multiple sites running on the same VM and they'll all have the same IP address. The service requires each site to register it's hostname ahead of time so that when a request comes in, the service knows which site the request should be routed to.
Related
Some of my apps are not working from some customers site, I later discovered that this was because I am using the default websites for my app hosting that is the url is myapp.azurewebsites.net which was not whitelisted on the customers firewall. The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.
If i were to create CNAME record which has a CNAME pointer to the azure default web app for example myapp.mywebsite.com points to myapp.azurewebsites.net, will this get around the issue ? Or do I need to whitelist myapp.azurewebsites.net Or its IP address that is the IP address of myapp.azurewebsites.net ?
Firstly, by default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. So, typically, anyone with the URL without any specific local network/firewall/proxy restrictions can access the WebApp URL.
As I understand, your WebApp is open to the public and only a few users (on a specific network), have trouble accessing the site. Plus, there are no access restrictions that you have implemented from the WebApp side.
Just to highlight,
Network administrators often deploy proxy servers, firewalls, or other
devices, which can help secure and give control over how users access
the internet. Rules designed to protect users can sometimes block or
slow down legitimate business-related internet traffic. This traffic
includes communications between you and Azure over the URLs listed
here.
Reference : Allow the Azure portal URLs on your firewall or proxy server
So, on case-case basis, for the affected network, you may have them add appservice.azure.com (Azure App Services) in the allowed list.
Or
As your customer performed – “The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.” have them add the URLs to allowedlist.
Or
Since IP address of your WebApp (see the reasons for the change), the best route would be for you to set up a custom domain for your WebApp.
Kindly check this doc - Tutorial: Map an existing custom DNS name to Azure App Service
The CNAME maps to the app's default hostname instead, which is less susceptible to change. | | Wildcard | *.contoso.com | CNAME record. |
-- As a side note (as indicated above), by setting up access restrictions, you can define a priority-ordered allow/deny list that controls network access to your app. Which is the opposite of your scenario, just sharing as FYI, in case you wish to know about access restrictions from WebApp side. Set up Azure App Service access restrictions
So I'm working on building scripts to deploy Azure resources using the Az modules in PowerShell. I am new to Azure Traffic Manager, so I'm wondering if what we are looking to do is even possible, and if so, how.
We have an API Management Service (APIMS) with a handful of APIs in it that point to a few different web apps within Azure. So the way it works currently is we have a client application that will post to a specific API operation via its APIMS URL.
We are looking at the idea of using Traffic Manager purely for moving traffic from one APIMS to a another in the event that we need to create a new APIMS. I can add the existing APIMS as an endpoint to the Traffic Manager as an external endpoint using its public IP address. But beyond that, here's what I'm unsure of:
How exactly would traffic actually get routed through the traffic manager, through the APIMS, to the specific API post? (as in, what would the client application need to specify as where it's sending its post?). Or would this even work??
If we create a new APIMS, can we then simply add that as a new endpoint to the traffic manager (again, as an external endpoint via its IP address), and then delete the old APIMS endpoint?
I did find this question that's similar, but that answer is using Add-AzureTrafficManagerEndpoint as opposed to New-AzTrafficManagerEndpoint, which is what I'm using and apparently does not support -DomainName as a parameter.
Traffic manager does not route traffic, it only does domain name resolution. You could use TM for that. For your custom domain in traffic manager (say contoso.com) you can add CNAME record pointing to contoso.azure-api.net (it's preferable to use CNAME instead of A and APIM service IP may change in certain scenarios). And add SSL certificate in APIM for contoso.com. What will happen in that setup:
Client wants to make request to https://contoso.com/myapi
Client will perform DNS lookup for contoso.com and see CNAME record pointing to contoso.azure-api.net
Client will perform DNS lookup for contoso.azure-api.net and see APIM IP address
Client will try to open SSL connection to APIM
APIM having SSL certificate available will accept the connection
Client will send request.
All this does not require any special configuration from your client apart from setting it up to use "contoso.com" as a hostname for your API. Later if you want to switch to a different APIM service you could go and update TM. Client will not require any changes.
The one thing to know is that this particular setup does not require TM per se. As all you really need is a custom domain from any DNS provider because all you need to do to switch traffic from one APIM to another is update CNAME record.
I am on a project that is re-platforming a site from a web server to an Azure PaaS web app, in addition the site will have all new content and in some cases new URLs. We have some redirects in place to handle the mapping of old URL's to new ones. I would like to test that these redirects work correctly on my new azure web app. Normally I would update my hosts file to point at the new server, add an IIS binding so the correct website picks it up and go from there. However I don't seem to be able to bind a new hostname ("custom domain") without verifying that I own the new host name. It will just be my internal DNS that I will be altering to re-route my requests. Does anyone know how to add a custom domain in the azure web apps without validating? This doesn't sound like a big ask to me.
Thanks
Will
You can't do it without any verification, but you can do it without pointing traffic away from your existing site to your new site.
To verify you own the domain without redirecting traffic to it yet, create a DNS record called a TXT record with your domain registrar.
the "TXT host" should be
awverify.mysubdomain.mydomain.com
or
awverify.mydomain.com
The "value" should be
myapp.azurewebsites.net
just replace "mysubdomain" and "mydomain" and "myapp" with your specific info.
After you do this, the verification should succeed and you can add the custom hostname.
Here is more info about this: https://learn.microsoft.com/en-us/azure/app-service/manage-custom-dns-migrate-domain
You can use either a CNAME record or an A record to map a custom DNS name to App Service.
We recommend that you use a CNAME for all custom DNS names except a root domain.
If you missed a step or made a typo somewhere earlier, you see a verification error at the bottom of the page.
If you will use A record, you can create a TXT record to map to the app's default hostname .azurewebsites.net. App Service uses this record only at configuration time, to verify that you own the custom domain. After your custom domain is validated and configured in App Service, you can delete this TXT record.
Reference: https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain.
I have a website on Azure Cloud Services, and I have enabled a wildcard for my website like: *.mywebsite.com
Then if a customer registers and select as his subdomain: client1.mywebsite.com, I only save the subdomain associated with my customer in the database. I don't need to do anything on the portal. This works as well on Azure Web Apps (Azure Websites).
Now, if my client goes to his domain provider and sets a DNS entry like:
www.client1.com CNAME client1.mywebsite.com
I can handle that correctly in Cloud Services without having to register "www.client1.com" in the Azure Portal. Is that possible in Azure Websites without having to add www.client1.com to the Azure Portal?
Short answer, no, it is not possible.
Explanation.
What you type in the address bar is the name that is presented to a web server in the HTTP request. Regardless of the underlying DNS responses. If a DNS look up of www.example.com provides an IP Address, whether a CNAME or an A record, that is where it will go and get data from. The only way to change that is with a HTTP Redirect.
In Azure the incoming server name is used to direct traffic to the correct web app (On the same set of IP Addresses there might be thousands of other websites registered) The only way it knows how to distinguish where to send the request is from the incoming server name.
Why this worked on Cloud Services.
Behind a cloud service was an IP Address that was unique to your servers behind it. When a cloud service got a HTTP request, it would process it, because there was nowhere else to send it.
In the next several months we will be going live with a web app ('MyApp') that is being hosted on Azure. We have purchased the MyApp.com domain and our Azure domain name is MyApp.azurewebsites.net.
We do not want our users to ever see the azure domain name in any form. We want them to see www.MyApp.com or www.MyApp.com/Sales/ViewSale etc.
I think I know how to map www.MyApp.com to MyApp.azurewebsites.net based on this article. We won't be able to set this up for a while, so I'd like to know what the user will see in their browser URL when they go to www.MyApp.com. Will they see www.MyApp.com or MyApp.azurewebsites.net? And then what will they see as they navigate various pages in the app?
Your azure website needs to be at least at the 'shared' level. This is the first tier of 'paid' azure website hosting. You do this under website > scale.
app service plan pricing tier = shared.
then you would choose 'configure' and look for 'domains' and add your www.myapp.com domain.
Then you head out to your DNS manager and add a CNAME record that directs traffic from www.myapp.com to myapp.azurewebsites.com, OR you can lookup up the Virtual (public) IP of your azure website and update the A record in your DNS manager.
Either route, your visitors will see www.myapp.com/mypage, www.myapp.com/mypage2, etc.
Once you have the proper hosting level (the control panel will tell you, look for custom domains) and configuration, they can access it as www.myapp.com. You may need to provide your own SSL cert in order to configure it as well.
When it comes time to SSL, check out this post (Azure SSL Certificate) that I made regarding uploading of SSL certs in the control panel. It will save you a headache.
The article you linked appears to have solid information based upon my recent experiences. One thing to note: It has screen shots from the old configuration panel, so some things may look different in the new one.
I haven't found a way to hide the myapp.azurewebsites.com method to access a page, other than maybe doing a redirect inside your code. However, until you have your DNS setup it might be nice to see things working under that domain to start.