'How to create Azure Front Door Standard/Premium with custom domain using Bicep?

In the classic Azure Front Door you can just point a DNS CNAME to your Front Door and validate it. In the new Azure Front Door Standard/Premium a CNAME must be validated using a TXT record on your DNS.

When creating a domain with a Bicep script in a build pipeline, the pipeline will run until terminated by timeout. The domain is, however, created. After that we would need to go in to the Azure Portal, get a validation value and put that into a TXT record in our DNS.

Is TXT record validation the only way and is how can this be done without the build pipeline timeouting?

azurearm-templateinfrastructure-as-codeazure-front-doorazure-bicep


Solution 1:[1]

The timeout cannot be avoided today due to a bug in ARM / Front Door.

According to these GitHub Issues, the issue should be resolved "in a few weeks".

They also contain some Bicep samples. I did not copy any code to the answer since it is not working at this point in time.

Solution 2:[2]

Solution for Constant Custom Domains

If you don't need to associate new domains on the fly, there is a viable solution because _dnsauth TXT validation for domain ownership must be performed only once. Using ARM template export and ARM to bicep converter az bicep decompile --file arm.json helped us to design this solution.

In our setup, we first linked the domain manually via Azure Portal and added it to bicep after successful validation. This way we can redeploy and update FrontDoor Standard/Premium via bicep without losing our manually added custom domain. For this, the resource in bicep must have the same name as the manually created domain as displayed in the endpoint manager:

resource myCustomDomain 'Microsoft.Cdn/profiles/customdomains@2021-06-01' = {
  parent: profile
  name: 'my-custom-domain-example-com'
  properties: {
    hostName: 'my-custom-domain.example.com'
    tlsSettings: {
      certificateType: 'ManagedCertificate'
      minimumTlsVersion: 'TLS12'
    }
  }
}

In addition, the id of the custom domain must be added to each route that should be associated with it:


resource myRoute 'Microsoft.Cdn/profiles/afdEndpoints/routes@2020-09-01' = {
  name: 'myRoute'
  properties: {
    customDomains: [
      {
        id: myCustomDomain.id
      }
    ]
    // ...
  }
}

A Web Application Firewall (WAF) can be linked in the same way via security policy:

resource securityPolicy 'Microsoft.Cdn/profiles/securityPolicies@2020-09-01' = {
  parent: profile
  name: 'mySecurityPolicy'
  properties: {
    parameters: {
      type: 'WebApplicationFirewall'
      wafPolicy: {
        id: myWafPolicy.id
      }
      associations: [
        {
          domains: [
            {
              id: endpoint.id // the default endpoint
            },
            {
              id: myCustomDomain.id 
            }
          ]
          patternsToMatch: [
            '/*'
          ]
        }
      ]
    }
  }
}

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Alex AIT
Solution 2

Related Questions