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.
Related
I have a SaaS application where by default customers get their own url on our domain like saas.application.com/company-a. They can however configure a "vanity domain" using a subdomain on their own domain by setting up a CNAME record pointing to us. Something like this:
saas.company-a.com CNAME saas.application.com
We validate that the record indeed points to us and generate a certificate (current setup is using cert-manager and Traefik in Kubernetes).
We want to start using Azure Front Door and let it handle cert generation/renewal. However, when setting up custom domains in Front Door, we need to validate each custom domain using a TXT record.
This will complicate the setup process for our customers (currently they only need to add a CNAME record), and we will have to ask existing customers to setup TXT records so that their domains can be validated when we migrate to Front Door. This is a show stopper for us, is there an alternative that I'm not seeing?
Unfortunately with the new Azure Front Door product this is no longer possible. A TXT record is required to obtain an SSL certificate.
Even when bringing your own certificate, the custom domain will stay on the status 'Pending' until the TXT record is added. While the status is 'Pending', I found that the site will respond with HTTP 502: MismatchCert (Hostname mismatch) Blocked by SSL_HOST_MISMATCH.
Another option is to use the older version of Azure Front Door (Classic).
This tier allows you to verify the domain using only a CNAME record.
You can compare the features between Standard, Premium and Classic here:
https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/tier-comparison#feature-comparison-between-tiers
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 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.
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.
When we tried to add a custom domain to our current Azure CDN endpoint, the CDN was down while it was trying to verify and issue an SSL certificate for the custom domain. I cancelled the process and everything came back after a few minutes.
I know that in the instructions it states to map the custom domain to the temporary cdnverify subdomain,https://learn.microsoft.com/en-us/azure/cdn/cdn-map-content-to-custom-domain#map-the-temporary-cdnverify-subdomain, but I think this is only if the URL we are using for the custom domain is in use. Is this correct?
Is there any way to avoid this downtime or should this not happen?
but I think this is only if the URL we are using for the custom domain
is in use. Is this correct?
Correct. The link states that when you map an existing domain that is in production. First map your custom domain to your CDN endpoint hostname with the Azure cdnverify subdomain to create a temporary CNAME mapping. so you can access your custom domain URL without interruption while the DNS mapping occurs.
Is there any way to avoid this downtime or should this not happen?
If you have verified that the cdnverify subdomain has been successfully mapped to your endpoint, you can then map the custom domain directly to your CDN endpoint hostname. After creating CNAME for your custom domain, you can delete the temporary cdnverify subdomain CNAME record. It should avoid this downtime.