Occasionally receiving 421 response code from Azure Front Door when using wildcard route

Question

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).

Rebec

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. – Rebec

I had this exact same problem using App Services as the back-end. Support is supposedly turning off the blocking for me tonight. I fundamentally don't understand the root cause of this issue as the browser's request should only contain the one domain. I'm not sure what other one it would use. – Azurite

Answer 1

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.

Rebec

Because of the stance they've taken on it I'd wager this will only be temporary and they'll eventually give a deadline before disabling the block is no longer an option. Who knows? – Skite

Azure has turned off the domain fronting block for our services and now all is well. However, they said they will re-enable it on November 8, 2023, so we'll need to figure out the root cause before then. It appears to be mostly happening to our clients on iPhones. – Azurite

As a follow-up, the issue was caused by us loading a script from cdn.ourdomain.com, but then doing a post to tenant.ourdomain.com, both using the same wildcard certificate on the same Front Door instance. From what I understand, the HTTP2 connection is reused on the POST, thus having the SNI name of cdn.ourdomain.com and the HTTP request of tenant.ourdomain.com be mismatched. This is what Front Door was detecting and blocking. – Azurite

@BrianVallelunga, what was the solution you ended up with that Azure support has suggested? Turning on HTTP2 is not optimal. – Rexford

@GabrielKohen In our case, we simply changed the domain the script was loading from cdn. to tenant. This way both were connecting to the same FD instance with the same HTTP 2 connection. – Azurite

Answer 2

Interesting that AFD is a reverse proxy, and RFC 7540 9.1.2. states proxies should NOT be generating this response. MS as of November banned domain fronting and supposedly had given warning as of I think April last year to get users to move away from it.

From other research it looks like the reason why Safari doesn't handle this correctly is that the same RFC section referenced above says the client "MAY try the request -- whether the request method is idempotent or not -- over a different connection." Safari doesn't appear to retry this TLS connection with correct SNI, whereas other browsers will.

What I'm curious about though is how this looks in a trace. For your other browsers that are working, do the Dev Tools show this 421 being returned followed by an immediate attempt to retrieve the resource again?

https://www.rfc-editor.org/rfc/rfc7540#section-9.1.2

Skite

Answer 3

I have the same problem for our frontend app. I am hosting it on Azure Storage with Azure CDN for custom domain. Everything works properly for instances created during last year, but we are facing the issue for instance created during the February. I have tried to use dedicated SNI based certificate managed by Azure, but it has not worked. I think only solution to contact Microsoft Support is left to switch off the feature

Nonintervention

Answer 4

After some experiments, we found different solution for this issue - apparently adding <preconnect> tags in HTML header makes Safari establish new HTTPS connection to each origin.

While this is not a perfect solution, you might add preconnect hints to specific domains, if there are not too many of them

Mither

Answer 5

The situation for today is that MS declines requests for disabling domain fronting block "feature". In our case this issue mostly affects Safari users (but not only). Luckly adding custom domain with CDN managed certificate solved the problem for us.

Our config now is:

• Website: app.ourdomain.com (A record in CF)
• CDN: cdn.ourdomain.com (CNAME record in CF poiting to Azure CDN (<your_url>.azureedge.net))

Women