Map a specific Web App Service Path to a Custom Domain - azure

I am looking for a way in Azure to map Web App Service paths to domain names I own.
For example
Map xyz.com to .azurewebsites.net/Views?id=xyz
Map abc.com to .azurewebsites.net/Views?id=abc
Is this possible ?
I know I can map xyz.com to .azurewebsites.net and use the custom domain feature to do so.

You can do this, just not with straight DNS. Easiest way in Azure to do this, in my opinion is to create a Front Door - which is a really easy-to-configure and fully-featured HTTP load balancer (note I call out HTTP here, as this is the level on which Front Door works - if you need lower-level protocol support you'll need another solution).
Front Door allows you to register custom domains ("front end") addresses and then map them to different web apps ("back end services") using routing rules. Those routing rules allow you to either forward (which would act similarly to a reverse proxy) or redirect to your desired path.

Related

Azure front door to support multiple web app by path under same domain

I have a question about azure front door potential for this. So I have 2 web site running by Azure App Services and I need then under same domain name but different path of URL like this:
App Service A -> www.something.com
App Service B -> www.something.com/b-product
I'm not sure this is possible to use Azure front door or I should use another service to solve this problem.
Do somebody can suggestion to me?
Yes you can do this fairly easily, when you create your routing rule you have the option tom specify patterns to match, there you can specify /foo and have this forwarded to pool A where app service A lives
Then you create a different routing rule with /bar pattern to match and forward that to pool B
Then you can repeat this until you get what you need.
you can also have one routing rule match the / domain as per your example you don't have to use a /foo pattern you can also do /* but I always found it easier to use /foo/* and /bar/* to keep the same URL structure
As suggested by Junnas , you can use the front door rules engine
Alternatively , you can use application gateway listeners
If you want all of your requests (for any domain) to be accepted and forwarded to backend pools, choose basic. Learn how to create an application gateway with a basic listener.
If you want to forward requests to different backend pools based on the host header or host names, choose multi-site listener, where you must also specify a host name that matches with the incoming request. This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. To learn more, see hosting multiple sites using Application Gateway.

Azure storage containers and routing from wildcard root domain

I have a storage account in Azure with a container named clients. Inside the container I have folders for various clients, i.e:
mysite.blob.core.windows.net/clients/one
mysite.blob.core.windows.net/clients/two
I also have my own site set up as a static website, i.e:
mysite.z33.web.core.windows.net
On top of that, I have a custom domain: mysite.com. Is it possible, using Azure CDN or Azure Front Door/Application Gateway to route traffic like so (in a way that doesn't require further configuration per client):
one.mysite.com -> mysite.blob.core.windows.net/clients/one
two.mysite.com -> mysite.blob.core.windows.net/clients/two
mysite.com -> mysite.z33.web.core.windows.net
So far I have tried doing this with Azure CDN but I don't think it's possible, it has a rules engine that seems quite flexible but I don't think they support wildcard domains, unless I'm (hopefully) wrong. Ideally I'd like it to be done in some sort of wildcard way, so that is maps:
<client>.mysite.com -> mysite.blob.core.windows.net/clients/<client>
I don't really want to have to add more rules or configuration every time I have a new client.
In fact, you could use an alias record to add a root domain as the custom domains in your CDN endpoints if you use Azure CDN to host your DNS zone. In this case, you need to set up multiple endpoints for each custom domain. See this document for more details. But Pointing a zone apex to CDN endpoints for Azure CDN from Akamai is currently not supported. You can use other CDN price tier.
If you use the Azure application gateway, you may configure multiple sites listener to receive different incoming host traffic and use path-based URL rules to route the traffic to the backends. It looks like a complex configuration and hard to troubleshoot the app gw related issue.
The azure front door should also do this trick, it supports onboard a root domain on your Front Door also allows wildcard domains. The route path is also easy to configure. See path matching for more details.
Hope this information could help you.

How to replicate SSL Certificates for a custom domain in different regions

TL;DR;
What's the way to distribute an SSL certificate across regions, so that no matter which region the application is hosted - it will serve the SSL certificate for the requested custom domains.
Explanation:
We have an Azure Web app where we add custom domains per user. We want to scale the app in different geographic regions behind a traffic manager so that when the website is accessed from Australia - it will be served from the Auatralia's Web App, and when the request comes from Europe - the web app in Europe will serve the request. So, in current situation, regardless of where the request is coming from it will always be served from one location, for example: Europe.
The challenge here is we can add the custom domain in only one of the web app, due to the fact that you need a CNAME entry pointing to an individual URL. It cannot point at two different URLs at the same time. It is possible to route the requests to individual apps but the other web app will not be able to serve the SSL certificate if it's mapped on App1 in region1.
How to distribute or maintain the pool of certificates which can be access by the web apps in different regions? Is there any way with Microsoft Azure?
Update:
We are going to have N number of custom domains, and so N number of SSL certs to handle. AFAIK, Azure Front Door and Azure Traffic Manager - we can map a custom domain to their own endpoints, and is limited to one custom domain. Here I'm talking about handling thousands of external custom domains/SSL Certs.
Thanks in Advance! 🙏
Instead of using Traffic Manager, I would use Azure Front Door. This has a built-in SSL certificate management. You don't even need to purchase the certificate yourself.
What I understood from the question is basically you would like to address the request from the same region rather than from one location. In that case, I would suggest have a look at azure application gateway. Here, you can define path-based load-balancing rules. In that path based, basically you can have one attribute which identifies location say /api/emea/images, /api/apac/images. Off-course you need to first define API on these lines to accommodate some kind of identifier. Once done, then based on this you can create this load-balancing rule in application gateway. Then, you can have different backend pools say one sitting in EMEA region with four-five virtual machines, that can handle traffic from EMEA region. Similarly, it goes for another region as well. Try implementing the same on these lines. You can also explore front door option as well as it handles load-balancing globally and your certificate related stuff should also get addressed. It should address your problem.

Azure front door custom domain downtime

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.

Azure Front Door and DNS Configuration for SSL "bare" (without www) Custom Domain

I've successfully configured SSL / HTTPS for my custom domain - with a "www" in the URL - using the Azure Front Door product. That configuration required a DNS CNAME entry that forwards "www.cutegoat.com" to "cutegoat.azurefd.net"
I still have an SLL problem when I go to the same URL without the "www" prefix: "https://cutegoat.com"
My A Type DNS record still points to an IP address that Azure gave me for my App Service. I thought about changing that, but the Azure Front Door designer is pretty clear that my "Custom host name" must have a corresponding CNAME record:
I'm using GoDaddy for my domains and I've added a CNAME record with a source of "cutegoat.com", but I still get the Azure Front Door "CNAME record required" error. That entry let's me add a mapping to "cutegoat.com.cutegoat.com"
I think the Azure Front Door service is looking for a CNAME record with a source value of "#". But I can't enter that CNAME record, my guess is, because I have an A Type record with a source of "#" already.
Does anyone know the proper DNS / Azure Front Door configuration to get SSL working for my "bare" custom domain?
This appears to be working now, using an Alias type.
I use Azure DNS, so image is from there.
Added a new A record for the # apex
Set it to an Alias
The Frontdoor service now shows up under the Azure Resource.
Back in Frontdoor, finished up, creating a frontend host for the apex domain then worked.
Yes, since you must have an A Type record with a source of # already. You could not add such host # in the CNAME record as the CNAME limitation in RFC1034
If a CNAME RR is present at a node, no other data should be present; this ensures that
the data for a canonical name and its aliases cannot be
different.
As far as I know, currently Azure front door does not support to add Naked or root Domains to the custom host name. If you want to improve this service, you can request feedbacks or upvote this feedback--- Add Custom Apex (Naked) Domains as front end hosts for Azure Front Door Service
This is an old question but I struggled a lot with this.
I had this issue with a static web app. I needed this website to be PCI compliant so Azure Front Door was a requirement, but I couldn't make front-door accept the apex domain, and anyone typing the bare domain was getting a "this is not a secure site" (or whatever) message, so what I did is to add the apex domain (example.com) as custom domain at the static web app (this way Azure provided the SSL), and www.example.com at Azure Frond Door. Btw this last one always worked fine. A redirect at the apex domain does not work if the user types https://example.com instead of http://example.com, so you do need an SSL even for the redirection. At least this was my case.
Anyway, so I handled the redirection by code at the index.html file (Angular) with vanilla javascript at the header
<script>
let loc = window.location.href;
loc = loc.replace(/^https?:\/\//, '');
loc = loc.replace(/\/.*$/, '');
if (loc != 'www.example.com') {
window.location.href = 'https://www.example.com';
}
</script>
It may not be the best solution, but I guess the problem was solved cause we got PCI compliant.

Resources