Custom domain orphaned after failed add + parent app deletion: every re-add fails with unknown error (legal.greaterbergen.org)

[SLeitner2540]

Describe the bug

Custom domain legal.greaterbergen.org cannot be added to any Static Web App. Every attempt fails with:

An unknown error has occurred while adding your custom domain. Please try again later.

and the failed customDomains child resource then hangs in Deleting state for many hours.

The hostname appears to be orphaned in the SWA backend: the very first add attempt (2026-08-11, app gbca-legal in gbca-web-rg, East US 2) failed with the same unknown error, its delete hung, and the parent app was deleted while the child was still Deleting. Since then, every add of this hostname on a freshly created app fails identically. Requesting release of the stale hostname registration for legal.greaterbergen.org.

Evidence that client-side config is correct

• CNAME legal.greaterbergen.org -> delightful-glacier-00a9cda0f.7.azurestaticapps.net verified on the authoritative name servers (GoDaddy ns07/ns08.domaincontrol.com) and public resolvers (8.8.8.8, 1.1.1.1) before each attempt
• No CAA records on the zone, no DNSSEC (no DS record), no conflicting A/TXT records
• Two sibling subdomains on the SAME zone with identical CNAME configuration (hsrp.greaterbergen.org, unityday.greaterbergen.org) attached to sibling SWAs without issue
• Both cname-delegation and dns-txt-token validation methods fail the same way (dns-txt-token never returns a validation token; the record goes straight to Deleting)
• Reproduced across two different app instances (original app deleted; current app gbca-legal, default hostname delightful-glacier-00a9cda0f.7.azurestaticapps.net)

Current state

• App: gbca-legal, resource group gbca-web-rg, East US 2, Free tier
• az staticwebapp hostname list shows the domain stuck in Deleting with errorMessage "An unknown error has occurred while adding your custom domain."
• Retried roughly every 30 minutes for 14+ hours; no change

What we are asking

Please locate and release the orphaned/stale backend registration for legal.greaterbergen.org so it can be added to app gbca-legal. Happy to provide subscription/correlation IDs privately if needed.

[SLeitner2540]

Follow-up with investigation results, to make this actionable rather than just a report:

Ruled out: CAA / certificate authorization (the #163 diagnosis). DigiCert-style CAA resolution is healthy at every level of both trees: legal.greaterbergen.org, greaterbergen.org, org, the CNAME target delightful-glacier-00a9cda0f.7.azurestaticapps.net, 7.azurestaticapps.net, and azurestaticapps.net all return NOERROR, and the only CAA record anywhere is the non-restrictive contactemail marker on azurestaticapps.net. No SERVFAILs, so certificate issuance is not being blocked client-side.

Ruled out: DNS misconfiguration. CNAME verified on authoritative GoDaddy NS + 8.8.8.8 + 1.1.1.1 before every attempt; no DNSSEC; sibling subdomains hsrp / unityday on the same zone attach fine to sibling apps.

Consistent with: stale backend hostname state. The failure began when the FIRST add crashed mid-operation ("unknown error"), its customDomains child hung in Deleting, and the parent app was deleted while the child was still Deleting. Every subsequent add of this hostname, on a brand-new app, fails identically, and every delete hangs in Deleting for hours. This matches the "leave it Failed for a few days, then delete and re-add works" observations from #1468, which look like backend state decaying on its own schedule.

Ask for the team: correlation window for the original crashed add is 2026-08-11 ~19:40-19:56 UTC, region East US 2, original app also named gbca-legal (since deleted), current app gbca-legal / delightful-glacier-00a9cda0f. Could someone check the certificate/hostname provisioning logs for that window and release the stale registration for legal.greaterbergen.org? Happy to provide subscription and correlation IDs privately.

Meanwhile I have stopped recycling the record (per #1468 the thrashing may prolong it) and will retry once daily.

[SLeitner2540]

Correction to my previous comment, for anyone landing here later: "no CAA records" should NOT be treated as ruling out the certificate path. Two confirmed resolutions of this exact symptom both ended with adding an explicit DigiCert CAA record even though none existed before:

• Can't add a custom domain #163, diagnosed by miwebst (certificate provisioning blocked; fixed by allowing DigiCert)
• https://learn.microsoft.com/en-us/answers/questions/5762480/ (Microsoft staff answer; user confirmed "The Problem were missing CAA records for digicert"), with the working recipe: add CAA @ 0 issue "digicert.com", remove the failed domain, wait 5-10 minutes, re-add using TXT validation.

In theory an empty CAA set permits all issuers; in practice the issuance path here appears to want the record present. We are applying that recipe next and I will report back whether it clears the "unknown error" for a hostname in this orphaned/stuck-Deleting state.

[SLeitner2540]

Further data point that should conclusively rule out every client-side cause: applied the full recipe from the linked Q&A and it still fails.

• Added CAA records to the zone permitting digicert.com (plus pki.goog, letsencrypt.org, sectigo.com, godaddy.com) - verified live on authoritative NS before the attempt
• Created a SECOND fresh Static Web App (never touched this hostname before)
• Added the hostname with dns-txt-token validation; the validation token was issued, placed as a TXT record at legal.greaterbergen.org, and verified live on authoritative NS (the conflicting CNAME was removed first)
• Status went Validating for ~40 minutes, then Failed with the same "unknown error has occurred while adding your custom domain"

So: two different apps, both validation methods, correct DNS confirmed before every attempt, CAA explicitly permitting DigiCert. Everything a customer can control has been eliminated. This hostname's registration appears wedged in the East US 2 backend since the original crashed add (2026-08-11 ~19:40-19:56 UTC). Could someone from the team release it? Happy to share subscription/correlation IDs privately.