How to point the root record to the FQDN of application gateway for containers??

Question

How to point the root record to the FQDN of application gateway for containers??

Maddi Srivardhan 0

We are using Azure Application Gateway for Containers to expose our AKS workloads. Unlike the standard Application Gateway, Application Gateway for Containers provides an Azure-managed frontend FQDN rather than a static public IP address.

We need to map our apex/root domain, for example example.com, to this Application Gateway for Containers frontend FQDN.

For a subdomain, such as www.example.com, we can create a CNAME record pointing to the Application Gateway for Containers frontend FQDN. However, Azure DNS does not allow a CNAME record at the apex/root domain. We also cannot create an Azure DNS alias record at the apex that directly targets the Application Gateway for Containers FQDN.

To work around this limitation, we tried the following design:

Apex domain → Azure DNS alias → Traffic Manager Profile 1 → nested endpoint → Traffic Manager Profile 2 → external endpoint → Application Gateway for Containers frontend FQDN

This configuration resolves successfully in some regions, but the apex domain intermittently fails DNS resolution in other regions. The Traffic Manager profile FQDNs and the Application Gateway for Containers frontend FQDN resolve successfully when queried directly.

We also observed that if we use the currently resolved IP address instead of the Application Gateway for Containers FQDN in the second Traffic Manager profile, the apex domain resolves successfully. However, this is not suitable for production because the IP address behind the Azure-managed Application Gateway for Containers frontend can change.

Could you please advise on the supported and reliable way to map an apex/root domain to an Application Gateway for Containers frontend FQDN?

0 comments

1 answer

Your answer

Answer 1

the apex problem is a DNS limitation, rather than one specific to Application Gateway for Containers. Your Traffic Manager approach is conceptually valid, but the nested Traffic Manager design is probably unnecessarily complicated and introduces another DNS-resolution layer. You might consider a simpler approach :

example.com → Azure DNS alias (A/AAAA) → Traffic Manager profile → External endpoint → Application Gateway for Containers FQDN

In other words, use a single Traffic Manager profile whose external endpoint target is the Application Gateway for Containers frontend FQDN. Traffic Manager is capable of using an FQDN as an external endpoint target, so you should not need Profile 1 → nested Profile 2 just to get from the apex to the Application Gateway for Containers hostname.

The Azure DNS portion would be an alias A record at the zone apex targeting the Traffic Manager profile. Traffic Manager then resolves its external endpoint, for example xxxx.<region>.alb.azure.com, and returns the resulting address to the client. Because the Application Gateway for Containers FQDN remains the Traffic Manager endpoint target, changes to the underlying Azure-managed IP address do not require you to modify DNS manually.

I would avoid the current Profile 1 → nested Profile 2 → external endpoint chain unless you have a specific requirement for two independent Traffic Manager policies. The fact that substituting the currently resolved IP address makes your configuration work seems to indicate that the failure is occurring while Traffic Manager is resolving or processing the FQDN used as the external endpoint, rather than at Azure DNS or at Application Gateway for Containers itself.

Note that there is a distinction between DNS resolution and HTTP/S routing here. Traffic Manager is DNS-based. It does not proxy the HTTP request to Application Gateway for Containers. Once the client receives the IP address returned through the Traffic Manager resolution process, the client connects directly to that IP. Effectively your Application Gateway for Containers configuration must still have example.com configured as an appropriate hostname/listener and the corresponding TLS certificate must cover example.com.

If a single Traffic Manager profile with an external endpoint whose target is the Application Gateway for Containers FQDN still exhibits intermittent regional failures, I would still advise against hard-coding the current IP. The IP behind the Azure-managed frontend is not a stable contract, so doing that defeats the purpose of using the managed FQDN.

For a production deployment, I would use:

example.com → Azure DNS alias A/AAAA record → Traffic Manager profile → External endpoint with target <Application-Gateway-for-Containers-FQDN> → Application Gateway for Containers → AKS

and separately:

www.example.com → CNAME → <Application-Gateway-for-Containers-FQDN>

If you need Traffic Manager's health-based routing, priority/weighted routing, or multiple Application Gateway for Containers frontends, you can still use those capabilities, but I would keep the Traffic Manager hierarchy as shallow as possible.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Maddi Srivardhan 0 Reputation points

2026-09-10T05:24:12.8933333+00:00

Thanks for the response but we dont have any requirement of using second traffic manager this is the workaround suggested by azure only. And we have already tried the method which you are suggesting that is to use single Traffic manager but azure is having limitation of attaching root record to a traffic manager which is pointing to fqdn instead of static ip.
Marcin Policht 106.8K Reputation points MVP Volunteer Moderator

2026-09-10T11:57:19.8666667+00:00

Appreciate the clarification - that's a valid point.

Have you considered placing Azure Front Door in front of Application Gateway for Containers. As far as I understand, the apex domain could use an Azure DNS alias record targeting the Front Door profile, which provides native support for the root domain without requiring the nested Traffic Manager workaround. Front Door can then route/proxy requests to the Application Gateway for Containers frontend as its origin.

Another alternative might be to use the apex domain only for an HTTP redirect. An Azure-hosted redirect service, such as Azure Static Web Apps or another suitable endpoint, can serve example.com and return a 301/308 redirect to www.example.com. The www.example.com record can then be a standard CNAME pointing directly to the Application Gateway

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin