We are using Azure Front Door to serve our white-labeled static website, which means we need our customers to be able to access it through unique subdomains (e.g., cust1.domain.com and cust2.domain.com).
We CNAME *.domain.com to our Front Door instance via DNS, map a route for *.domain.com and have bound it to a custom *.domain.com wildcard certificate (not managed, which is unsupported). The route is pointing to an origin group that in turn points to a "Storage (Static website)" origin similar to prod-storage.z14.web.core.windows.net.
Occasionally on Safari, we receive a response that looks like:
<h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>0a1LIYwAAAADIYjiE3LgzTLfw86bqHEd5Q0hHRURHRTE2MTAAYTk0OGVmNjEtMTk3NS00ZjA0LTkwMjgtOTgwY2I4YzllYzFl
When reviewing the network tab, we're seeing that response is actually a 421 Misdirected Request. My assumption is that it has to do with this update: https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq#how-does-front-door-handle--domain-fronting--behavior--
What is the correct way to set up this flow to avoid this new issue from Front Door? Our case is somewhat unique and not documented as far as I can tell.
I have seen solutions that include turning off HTTP/2, creating a separate cert per domain and using different IPs - none of which are effective nor will scale with our solution because we need to create new subdomains on the fly with no limitations (i.e., it's not realistic to programmatically add them to AFD).
I ended up solving this by contacting Microsoft support and asking them to turn off the domain fronting block, which appears to have completely resolved the issue on Safari based on our follow up testing. Was hoping for a better solution but this works for us for now.