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
Related
I'm having issue configuring my DNS to make all traffic routed from the root domain (no www) to the Azure front door. The below is what I have done so far:
Create the front door (frontend/backend/routing)
On-Board my custom domain (let's say hello.com) on front door
Now as per Microsoft guide I have to add a CNAME record to the DNS hosting provider (domain.com) to route the traffic to front door. But I have been told by domain.com that I cannot have A record and CNAME record named #
So I've found this solution https://learn.microsoft.com/en-gb/azure/frontdoor/front-door-how-to-onboard-apex-domain
Then I have created a DNS Zone on my Azure environment named "hello.com" and followed the guide.
Still I cannot see the traffic going through the front door.
Is that because I have 2 DNS servers? (one hosted on domain.com and another one on Azure)?
Can It be propagation time ?
Also how does azure know that I'm the owner of hello.com domain ?
As the linking document, to onboard a root or apex domain on your Front Door, you could use alias records in Azure DNS.
There are other DNS providers as well that support CNAME flattening or
DNS chasing, however, Azure Front Door recommends using Azure DNS for
its customers for hosting their domains.
If you select to use Azure DNS to host DNS domains, first you need to create an Azure DNS zone (hello.com) in Azure and delegate the domain to Azure DNS via changing the name server records for the domain in your original DNS registrar. You can verify the delegation by using a tool such as nslookup to query the Start of Authority (SOA) record for your zone. It can take up to 72 hours to propagate worldwide, although it typically takes a few hours.
Then, you can add an alias record for the zone apex in the DNS configuration for the domain to be onboarded. After this, you can add the apex domain name in the custom host name field on the Front Door designer tab.
To access your backend web app with the custom domain, ensure that you have created appropriate routing rules for your apex domain or added the domain to existing routing rules. Or, you may enable HTTPS on your custom domain.
I have static website on azure storage, it's connected to azure cdn to have https, and i have my custom domain folla.com.pl I want this domain to point to https://companywebsitecdn.azureedge.net/ which is address of my website on azure cdn. I chose custom domain on cdn configuration site, it asks me to make dns mapping to verify ownership, so i make CNAME cdnverify.folla.com.pl to cdnveriy.companywebsitecdn.azureedge.net and it get me to other window with custom doamin https config. And here's my problem, it get's stuck on second step
How I'm suppouse to configure another mapping to make it work, what i mean is to make folla.com.pl to point to https://companywebsitecdn.azureedge.net/ with https. I can't proivde what i already tried with my dns because it was a lot and i don't remember all of it. Also it's already second try and everytime after failure I have wait 8 hours for another try. Thanks in advance
This is my DNS config
When you try to add your custom domain folla.com.pl in the custom domains settings of Azure CDN endpoint. Before this step, you should have a CNAME record in the following format in the DNS zone.
When you turn on the custom domain https, you don't need to make a CNAME cdnverify.folla.com.pl to cdnveriy.companywebsitecdn.azureedge.net. Read here.
If that CNAME record still exists and does not contain the cdnverify
subdomain, the DigiCert CA uses it to automatically validate ownership
of your custom domain.
If the CNAME record entry contains the cdnverify subdomain, follow the rest of the instructions in this step.
DigiCert sends a verification email to the following email addresses. Verify that you can approve directly from one of the following addresses and read here.
admin#<your-domain-name.com>
administrator#<your-domain-name.com>
webmaster#<your-domain-name.com>
hostmaster#<your-domain-name.com>
postmaster#<your-domain-name.com>
Automatic validation typically takes a few hours. If you don’t see your domain validated in 24 hours, open a support ticket.
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.
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.
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.