%kb_name - %short_descr - Knowledge Portal

Overview

Root or apex domains, such as example.com, require special DNS handling because they cannot use standard CNAME records in the same way as subdomains. DNS flattening, ALIAS records, ANAME records, Azure DNS alias records, or equivalent DNS provider features can be used to support apex-domain resolution.

This article explains root domain DNS configuration, the limitations of standard DNS records, and how DNS flattening can be used to support root domain scenarios in accordance with Microsoft guidance. It also covers a separate concern: confirming that requests cannot bypass the intended edge layer by reaching the origin service directly from the public internet. DNS flattening controls how the domain resolves, but it does not protect the origin from direct access.

Symptoms

Review the DNS and origin access configuration if one or more of the following apply:

An apex or root domain, such as example.com, for a Sitecore Managed Cloud environment required to be configured.
The DNS provider does not allow a CNAME record at the apex or root domain.
Azure Front Door, Application Gateway, a CDN, WAF, or another edge service is used as the public-facing entry point to the application.
The apex or root domain resolves correctly, but a verification that the backend origin cannot be reached directly from the public internet is required.
To clarify whether DNS flattening, ALIAS, or ANAME records protect the backend origin.

Cause

Apex or root domains have DNS limitations that do not apply to subdomains. A CNAME record can be created for a subdomain such as www.example.com, but DNS standards prevent assigning a CNAME directly at the zone apex, such as example.com.

There might be misunderstanding about the following concepts:

DNS flattening
DNS flattening, ALIAS records, or ANAME records can be used by some DNS providers to point an apex domain to a hostname while remaining DNS-compliant.
Origin access validation
Origin access validation confirms whether the backend origin can be reached directly outside the intended edge path. If the backend origin remains publicly reachable, requests might bypass the intended edge layer, such as Azure Front Door, CDN, WAF, or Application Gateway.

A domain can be correctly flattened and still expose its origin. Correcting the DNS record type does not automatically protect the origin service from direct internet access. Both concerns must be validated independently.

DNS Flattening and Origin Exposure

DNS flattening controls how the apex domain resolves. Origin protection controls whether the backend can be reached directly outside the intended edge path.

Architecture Considerations

The risk of origin exposure varies depending on the architecture used. Common deployment patterns and considerations are shown below:

Architecture	Exposure Considerations
Application Gateway → App Service	Validate that App Service is reachable only through the intended Application Gateway path.
Azure Front Door → App Service	Validate that the origin accepts only intended Azure Front Door traffic.
Azure Front Door → Application Gateway → App Service	Validate that both Application Gateway and App Service cannot be bypassed directly.
Third-party CDN/WAF → Application Gateway → App Service	Validate that ingress is limited to the provider's published IP ranges and the origin is not directly reachable.

Actions

For the aforementioned scenarios, follow these steps.

Confirm the DNS configuration for the apex or root domain
For an apex or root domain, do not configure a static A record that points to an Azure Front Door endpoint IP address. Azure Front Door does not expose a stable frontend public IP address for this purpose, and Microsoft warns that the endpoint IP address might change.

Use one of the following supported approaches instead:
- Azure DNS alias record.
- DNS provider functionality such as CNAME flattening, ALIAS records, ANAME records, or DNS chasing.
- A subdomain CNAME, if the customer can use a subdomain such as www.example.com instead of the apex domain.
Microsoft documentation confirms that Azure Front Door supports apex domains but requires special DNS handling, such as Azure DNS alias records or CNAME flattening from a provider that supports it.
Validate that DNS flattening is not being treated as an origin-security control
After DNS flattening or an equivalent apex-domain configuration is in place, validate origin exposure separately.

Confirm the following:
- The apex or root domain resolves through the intended edge service.
- The backend origin cannot be accessed directly from the public internet.
- Traffic reaches the application through the intended edge path.
- DNS propagation has completed.
- Origin access restrictions are configured where applicable.
Apply the relevant action based on the architecture
- Scenario A: Azure Front Door fronts the origin
  If Azure Front Door is the intended edge service, configure the origin so that it only accepts traffic that comes through Azure Front Door.
  
  Recommended controls include:
  - Use Azure Front Door Premium with Private Link where supported.
  - Restrict public origins by using the AzureFrontDoor.Backend service tag.
  - Validate the X-Azure-FDID header value where applicable.
  - Use WAF policies and rate limiting as defence-in-depth controls.
  Note: Available origin-protection options vary by Managed Cloud platform generation. PaaS 2.0 environments support Private Endpoint-based architectures, while PaaS 1.0 environments rely primarily on access restrictions and WAF controls.
- Scenario B: Azure Front Door fronts Application Gateway, and Application Gateway fronts App Service
  Validate potential bypass points:
  - Confirm that Application Gateway only accepts inbound traffic from the intended edge source, such as Azure Front Door.
  - Confirm that App Service is not publicly reachable outside the intended Application Gateway path.
  - If App Service uses Private Endpoint, confirm public network access is disabled and DNS resolves to the private endpoint as expected.
  Note: Available origin-protection options vary by Managed Cloud platform generation. PaaS 2.0 environments support Private Endpoint-based architectures, while PaaS 1.0 environments rely primarily on access restrictions and WAF controls.
- Scenario C: Application Gateway is the sole edge service
  If Application Gateway is intentionally used as the public-facing edge, confirm that App Service does not expose a separate reachable public endpoint outside Application Gateway.
  
  For App Service, use access restriction rules to control inbound access. Microsoft documentation states that App Service access restrictions define an allow/deny list that controls network access, and when entries exist, an implicit deny-all exists at the end of the list.
- Scenario D: A third-party CDN, WAF, or gateway fronts the origin
  If a third-party edge provider is used, confirm that:
  - The domain is proxied through the provider where required.
  - Backend ingress allows only the provider’s published IP ranges.
  - The origin cannot be reached directly outside the provider’s path.

Use the following validation checklist after updating the DNS or origin access configuration:

Confirm the root domain uses DNS flattening, ALIAS, ANAME, Azure DNS alias records, or equivalent functionality.
Confirm the origin cannot be reached directly from the public internet.
Confirm traffic reaches the application through the intended edge service.
Confirm DNS changes have propagated successfully.
Confirm origin access restrictions are configured where applicable.

Note:

DNS flattening, ALIAS records, ANAME records, and Azure DNS alias records solve apex-domain resolution constraints. They do not protect the backend origin from direct access.
Do not create a static A record that points to an Azure Front Door endpoint IP address. Azure Front Door endpoint IP addresses might change.
Available origin-protection options can vary by Managed Cloud architecture and platform generation. Confirm the environment architecture before recommending Private Link, internal-only frontend, NSG restrictions, or App Service access restrictions.
If availability tests are used, confirm whether monitoring traffic must also be allowed, for example through the applicable monitoring service tag such as ApplicationInsightsAvailability.
Service tags can simplify network access rules, but they should be used together with architecture-appropriate validation and restrictions. For Azure Front Door origins, review whether AzureFrontDoor.Backend and Front Door identifier validation are required.