Azure Container App Environment making DNS queries to Certificate Revocation List URLs which don't exist

Question

Azure Container App Environment making DNS queries to Certificate Revocation List URLs which don't exist

RajivBansal-2486 331

We are using Azure Container Apps hosted in a Azure Container App Environment - using dedicated workload profile (instead of consumption workload profile). We have provided our own subnet for container app environment. Peer to peer encryption is also enabled. All outbound traffic is routed through Azure Firewall. Azure Firewall is also acting as DNS proxy. So all DNS requests are also sent to Azure Firewall.

Firewall logs shows that Container App Environment is sending DNS resolution requests for URLs which don't exist so the response is NXDOMAIN (Non-existent domain). As these requests are in a very large number, this is reported as security issue in SENTINEL - "These unsuccessful responses can be an indication of C2 communication." URLs are listed below.

Please tell which component of container apps or environments is sending these requests and why are they being sent to a non-existent domain. How can this be fixed.

URLs seen:

crl4.ame.gbl
crl3.ame.gbl
crl1.ame.gbl
crl2.ame.gbl
crl3.ame.gbl.blfwa1micajexil5bwga4cq5fd.fx.internal.cloudapp.net
crl2.ame.gbl.blfwa1micajexil5bwga4cq5fd.fx.internal.cloudapp.net

Khadeer Ali 5,985 Reputation points Microsoft External Staff Moderator

2025-05-21T09:55:21.7633333+00:00

@RajivBansal-2486 ,

Thanks for reaching out.

The DNS queries you're seeing (e.g., crl1.ame.gbl, crl2.ame.gbl, etc.) are likely triggered by the Azure Container App Environment itself. These are part of standard certificate revocation checks that Azure services perform to validate the status of SSL/TLS certificates — specifically through Certificate Revocation Lists (CRLs).

The *.ame.gbl domains appear to be internal to Microsoft’s infrastructure, used for verifying certificate validity. Since these domains aren't resolvable in private DNS or through your Azure Firewall DNS proxy, the lookups result in NXDOMAIN responses — which is expected in this setup and not typically a sign of malicious behavior.

To better understand which exact component is initiating the requests, we recommend:

Reviewing Azure Firewall logs for source IPs or hostnames associated with these DNS queries.

Filtering by request frequency and destination domain to narrow it down to specific pods or containers if possible.

This may help confirm whether these queries stem from infrastructure-level processes (such as sidecars or system containers), or any workload you’ve deployed.
RajivBansal-2486 331 Reputation points

2025-05-21T10:25:21.67+00:00

Khadeer Ali, Thanks for the response. As .ame.gbl is an internal Azure domain, shouldn't DNS queries be resolved by Azure DNS servers. Do we need to make any changes to DNS traffic so that these URIs are resolved by internal Azure DNS servers.

Concern from security team is that if these domains are not resolved how will the certificate revocation be checked.
Khadeer Ali 5,985 Reputation points Microsoft External Staff Moderator

2025-05-22T10:12:13.5166667+00:00

@RajivBansal-2486 .

Thanks for your patience, could you please check the private message and provide us with the requested details.

Here is the reference link on How to access & Data Privacy policy of private messages in Microsoft Q&A.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-05-27T07:32:08.9333333+00:00

RajivBansal-2486 What you're observing is expected behavior in certain Azure environments. The DNS queries to domains like crl1.ame.gbl, crl2.ame.gbl, and similar internal subdomains are part of certificate revocation checks initiated by the Azure Container Apps infrastructure itself — not by your deployed workloads. These CRL (Certificate Revocation List) lookups help verify the validity of SSL/TLS certificates used by underlying platform components.

Since your environment is configured to route all DNS traffic through Azure Firewall as a DNS proxy, these internal Azure domains fail to resolve — leading to NXDOMAIN responses. While these are harmless and expected in such setups, security tools like Microsoft Sentinel may flag them due to the high volume and unresolved domain nature.

To clarify these CRL URLs are internal to Microsoft's infrastructure and are not resolvable via public DNS or DNS proxies like Azure Firewall. this is not indicative of malware or command-and-control (C2) activity, and the platform behavior has been confirmed internally as part of routine certificate validation. Please share the details which I have requested in private message so that I can look into your environment from backend and narrow down /confirm on the RCA.
Thanks
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-05-29T05:29:05.52+00:00

Hello RajivBansal-2486, is your issue resolved? If not, please respond on Private Message.
Alex Burlachenko 9,585 Reputation points

2025-05-29T08:35:47.99+00:00

Arko ) hi, seems it is not solved )))) and in my answer is how to fix it )

rgds,

Alex

1 answer

Your answer

Khadeer Ali 5,985 Reputation points Microsoft External Staff Moderator

2025-05-21T09:55:21.7633333+00:00

@RajivBansal-2486 ,

Thanks for reaching out.

The DNS queries you're seeing (e.g., crl1.ame.gbl, crl2.ame.gbl, etc.) are likely triggered by the Azure Container App Environment itself. These are part of standard certificate revocation checks that Azure services perform to validate the status of SSL/TLS certificates — specifically through Certificate Revocation Lists (CRLs).

The *.ame.gbl domains appear to be internal to Microsoft’s infrastructure, used for verifying certificate validity. Since these domains aren't resolvable in private DNS or through your Azure Firewall DNS proxy, the lookups result in NXDOMAIN responses — which is expected in this setup and not typically a sign of malicious behavior.

To better understand which exact component is initiating the requests, we recommend:

Reviewing Azure Firewall logs for source IPs or hostnames associated with these DNS queries.

Filtering by request frequency and destination domain to narrow it down to specific pods or containers if possible.

This may help confirm whether these queries stem from infrastructure-level processes (such as sidecars or system containers), or any workload you’ve deployed.
RajivBansal-2486 331 Reputation points

2025-05-21T10:25:21.67+00:00

Khadeer Ali, Thanks for the response. As .ame.gbl is an internal Azure domain, shouldn't DNS queries be resolved by Azure DNS servers. Do we need to make any changes to DNS traffic so that these URIs are resolved by internal Azure DNS servers.

Concern from security team is that if these domains are not resolved how will the certificate revocation be checked.
Khadeer Ali 5,985 Reputation points Microsoft External Staff Moderator

2025-05-22T10:12:13.5166667+00:00

@RajivBansal-2486 .

Thanks for your patience, could you please check the private message and provide us with the requested details.

Here is the reference link on How to access & Data Privacy policy of private messages in Microsoft Q&A.
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-05-27T07:32:08.9333333+00:00

RajivBansal-2486 What you're observing is expected behavior in certain Azure environments. The DNS queries to domains like crl1.ame.gbl, crl2.ame.gbl, and similar internal subdomains are part of certificate revocation checks initiated by the Azure Container Apps infrastructure itself — not by your deployed workloads. These CRL (Certificate Revocation List) lookups help verify the validity of SSL/TLS certificates used by underlying platform components.

Since your environment is configured to route all DNS traffic through Azure Firewall as a DNS proxy, these internal Azure domains fail to resolve — leading to NXDOMAIN responses. While these are harmless and expected in such setups, security tools like Microsoft Sentinel may flag them due to the high volume and unresolved domain nature.

To clarify these CRL URLs are internal to Microsoft's infrastructure and are not resolvable via public DNS or DNS proxies like Azure Firewall. this is not indicative of malware or command-and-control (C2) activity, and the platform behavior has been confirmed internally as part of routine certificate validation. Please share the details which I have requested in private message so that I can look into your environment from backend and narrow down /confirm on the RCA.
Thanks
Arko 4,150 Reputation points Microsoft External Staff Moderator

2025-05-29T05:29:05.52+00:00

Hello RajivBansal-2486, is your issue resolved? If not, please respond on Private Message.
Alex Burlachenko 9,585 Reputation points

2025-05-29T08:35:47.99+00:00

Arko ) hi, seems it is not solved )))) and in my answer is how to fix it )

rgds,

Alex

Answer 1

RajivBansal-2486 hi thanks for posting this, man!

so ur seeing a ton of dns queries to certificate revocation list urls that don’t exist, and it’s tripping up sentinel thinking it’s some shady c2 traffic… sorry for that...

ok, these crl.ame.gbl urls are actually microsoft’s old-school cert revocation check endpoints. they’re used by windows components to verify if certs are revoked. but here’s the thing azure container apps (and the underlying infra) sometimes still try to hit them, even if they’re not really needed or even valid anymore. that’s why u get nxdomain those domains straight up don’t resolve.

why’s this happening? good question, at least for me ;) when ur container apps spin up or do their thing, some internal processes (like the k8s control plane or azure’s own services) might still have legacy code that tries to check cert revocation status. and since ur traffic’s going through azure firewall with dns proxy, every failed lookup gets logged… and ups sentinel freaks out ;)

So u have a few options fo fix it like just ignore it (if u can)). if this isn’t causing actual issues, u might just whitelist these urls in sentinel or tweak the alert rules. but i get it if security teams are breathing down ur neck, that might not fly. block the dns queries at the firewall. since these urls are dead anyway, u can create a dns rule in azure firewall to straight up drop requests to *.ame.gbl and *.fx.internal.cloudapp.net. here’s microsoft’s doc on azure firewall dns settings to help u out.

Disable cert revocation checks (careful with this one!). if ur apps don’t rely on strict cert checks, u could tweak the underlying nodes to skip crl lookups. but this is kinda nuclear only do it if u know what ur sacrificing security-wise. but fair warning, this might not apply cleanly to container apps.

check if ur workload profiles need updating. since ur using dedicated profiles, maybe there’s a config hiccup. peep the container apps networking docs to see if something’s misaligned.

honestly, blocking at firewall is the cleanest fix. those crl urls are ghosts of the past, and stopping the queries will shut sentinel up ;)) let me know if u hit snags.

Best regards,

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer
PPS That is my Answer and not a Comment

https://ctrlaltdel.blog/

RajivBansal-2486 331 Reputation points

2025-06-03T08:39:23.9766667+00:00

HI Alex, Thanks for the detailed response. Only viable solution I see is "block the dns queries at the firewall." But I don't see any possibility in Azure firewall policy to define rules for DNS queries. Rules can be defined for Network, Application and DNAT, but not for DNS queries.

Am I missing something. If this is possible, please point me to some documentation

Regards

RB

Share via

Azure Container App Environment making DNS queries to Certificate Revocation List URLs which don't exist

1 answer

Your answer