DNS Failures in Apps on Consumption / Flex-Consumption Plans

Question

DNS Failures in Apps on Consumption / Flex-Consumption Plans

Sabyasachi Bose 30

Since a last few days, function apps deployed on consumption and flex-consumption plans are failing with "([Errno -3] Temporary failure in name resolution)" connecting to other azure services as well as external APIs. We have been managing handful of errors all the time but there is a surge of errors in last 7 days. These apps do not use VNet or any custom networking settings.

Is it a known issue? Is anyone else facing the problem?

Here is the count of DNS failures in this month by date.

User's image

Pashikanti Kumar 1,725 Reputation points Microsoft External Staff Moderator

2025-11-27T23:49:08.7066667+00:00

Hi Sabyasachi Bose,

Thank you for reaching out to Microsoft Q&A

This type of recurring DNS resolution error ([Errno -3] Temporary failure in name resolution) on Azure Function Apps in Consumption and Elastic Consumption plans without VNets has been reported intermittently by users, occasionally coinciding with platform incidents affecting DNS or network infrastructure in Azure regions.

Transient DNS issues within Azure platform DNS resolvers or underlying Fabric.

Temporary disruption or degradation in Azure-managed DNS caching infrastructure serving Consumption apps.

Potentially related to a broader regional or zone-level network incident impacting service connectivity temporarily.

Functions not using VNet rely on Azure public DNS infrastructure, which can be subject to platform-wide maintenance or transient faults.

Because you mention a surge of these errors specifically in the last week, it aligns with periodic service incidents or rolling updates that can degrade DNS.

Check the Azure Service Health dashboard or Azure Status page for recent DNS or Functions platform incident reports in your region. Microsoft publishes real-time issues and maintenance notifications.

Enable Application Insights dependencies tracking on your functions to get diagnostics on DNS failures and correlate with time of day or region.

Retry logic and exponential backoff in your DNS or HTTP client calls to handle transient failures.
Rakesh Mishra 3,870 Reputation points Microsoft External Staff Moderator

2025-11-28T12:11:51.06+00:00

Hi @Sabyasachi Bose , I have reached out to you over private message regarding some information. Could you please check and share the requested information to assist you further on this.
Luca Giorgi 5 Reputation points

2025-11-28T13:35:47.7333333+00:00
We have the same issue. We first noticed it around 3 weeks (precisely Nov 22) ago in our service bus triggered function app. Currently 1/3 of our invocations run into 'Temporary failure in name resolution' during the various URL calls they perform. What we tried:

reduce dns lookups as much as possible

reduce concurrently processed messages

use different DNS servers (configured via the DNS Configuration page in the Azure portal)

The error still persists. Both azure specific and external URLs are affected.
Sabyasachi Bose 30 Reputation points

2025-11-29T01:20:02.5466667+00:00

@luca giorgino I have opened a case with MS and engineers are investigating. We have exact same errors and they have also started to come exactly from Nov 22. Cannot be a coincidence.

I am hoping the engineers will find a solution. I will let you know the outcome.

2 answers

Your answer

Pashikanti Kumar 1,725 Reputation points Microsoft External Staff Moderator

2025-11-27T23:49:08.7066667+00:00

Hi Sabyasachi Bose,

Thank you for reaching out to Microsoft Q&A

This type of recurring DNS resolution error ([Errno -3] Temporary failure in name resolution) on Azure Function Apps in Consumption and Elastic Consumption plans without VNets has been reported intermittently by users, occasionally coinciding with platform incidents affecting DNS or network infrastructure in Azure regions.

Transient DNS issues within Azure platform DNS resolvers or underlying Fabric.

Temporary disruption or degradation in Azure-managed DNS caching infrastructure serving Consumption apps.

Potentially related to a broader regional or zone-level network incident impacting service connectivity temporarily.

Functions not using VNet rely on Azure public DNS infrastructure, which can be subject to platform-wide maintenance or transient faults.

Because you mention a surge of these errors specifically in the last week, it aligns with periodic service incidents or rolling updates that can degrade DNS.

Check the Azure Service Health dashboard or Azure Status page for recent DNS or Functions platform incident reports in your region. Microsoft publishes real-time issues and maintenance notifications.

Enable Application Insights dependencies tracking on your functions to get diagnostics on DNS failures and correlate with time of day or region.

Retry logic and exponential backoff in your DNS or HTTP client calls to handle transient failures.
Rakesh Mishra 3,870 Reputation points Microsoft External Staff Moderator

2025-11-28T12:11:51.06+00:00

Hi @Sabyasachi Bose , I have reached out to you over private message regarding some information. Could you please check and share the requested information to assist you further on this.
Luca Giorgi 5 Reputation points

2025-11-28T13:35:47.7333333+00:00

We have the same issue. We first noticed it around 3 weeks (precisely Nov 22) ago in our service bus triggered function app. Currently 1/3 of our invocations run into 'Temporary failure in name resolution' during the various URL calls they perform. What we tried:

reduce dns lookups as much as possible

reduce concurrently processed messages

use different DNS servers (configured via the DNS Configuration page in the Azure portal)

The error still persists. Both azure specific and external URLs are affected.
Sabyasachi Bose 30 Reputation points

2025-11-29T01:20:02.5466667+00:00

@luca giorgino I have opened a case with MS and engineers are investigating. We have exact same errors and they have also started to come exactly from Nov 22. Cannot be a coincidence.

I am hoping the engineers will find a solution. I will let you know the outcome.

Answer 1

Adam Zachary 2,105

I’ve dealt with this exact problem before on Consumption and Flex-Consumption plans.

When you see a sudden surge in “Temporary failure in name resolution” and you are not using VNets, the issue is almost always the same:

Azure rotates the underlying compute hosts for Consumption plans, and sometimes a batch of hosts ends up with broken or degraded DNS resolvers. It doesn’t show in Service Health because these issues are host-level**,** not region-wide, so Microsoft does not classify them as incidents.

How to confirm it: Restart the Function App (or force a redeploy). If the DNS errors disappear immediately after restart and then come back days later, you are landing on bad backend hosts.

What actually fixes it:

Restart the Function App to force your app onto a different backend host.
If it continues, switch the app temporarily between Consumption → Flex Consumption → back, which forces a full reallocation.
Add a simple DNS test in Application Insights to confirm if the resolver is failing before your code even runs.
If the issue persists for more than a few hours, open a support ticket with your timestamp and region. Microsoft will drain the faulty hosts manually. I had to do this last time.

Sabyasachi Bose 30 Reputation points

2025-11-28T02:32:29.2833333+00:00

Thank you Adam. I am going to try that now.
Adam Zachary 2,105 Reputation points

2025-11-28T02:41:08.97+00:00

You're welcome, try it and let me know! fingers crossed :)
Sabyasachi Bose 30 Reputation points

2025-11-28T07:02:35.23+00:00

I restarted a bunch of apps. I don't see the difference.

Going to struggle with MS Support now.
Adam Zachary 2,105 Reputation points

2025-11-28T17:38:06.4866667+00:00
Sorry to hear this, Sabyasachi!

Given that restarts did not move the needle at all, this looks less like a single bad host and more like a platform side DNS problem that you cannot fully fix from your code or app settings.

The only things that have made a real difference for my team are:

Switch one of the worst affected apps to a different hosting model as a test Move a copy of the function to a Premium plan or an App Service plan and point it to the same dependencies. There are several reports where the “Temporary failure in name resolution” issues disappeared completely after moving off Consumption, which strongly indicates a problem in the Consumption platform path, not your code.

Try custom outbound DNS on at least one of the affected apps In the Function App, go to Networking, then Outbound DNS, change from the default Azure provided DNS to Custom and add public resolvers, for example 8.8.8.8 and 1.1.1.1, save, then restart the app. This has immediately stopped the same class of errors for some customers, although not for everyone.

Make sure you have aggressive retries in your HTTP or client code Microsoft’s own guidance for these transient DNS failures is to treat them as retryable. Wrap outbound calls in retry with backoff rather than relying only on the platform level dnsRetryAttemptCount.
Sabyasachi Bose 30 Reputation points

2025-11-29T01:34:42.5033333+00:00
@Adam Zachary

None of my apps on basic/premium plan have reported problem. So I agree that the problem is with consumption plan. We tried moving to flex-consumption. That did not help either. Based on nature of the apps that are failing moving them to premium is not optimal. They just run few times a day at burst and sleep at all other times.

I tried adding WEBSITE_DNS_ALT_SERVER to 8.8.8.8 in app settings without success.

I am going to try custom DNS as you suggested.

We have retries and exponential backoffs. Default retries on linux is 5.
The approach has been working for occasional failures. With the thousands of DNS failures we are getting now, has created another problem - most DNS queries if successful are resolving after multiple attempts and they have become slow. As a result the overall app has become slow and is timing out in cases.

We increased the timeouts of the app so that at least what is able to process can process. I am tempted to increase the retry count but worried that it will makes the apps slower.

Are you facing these problems since Nov 22 or are these are your experiences from past?
Akash Talole 0 Reputation points

2025-12-03T17:37:24.5466667+00:00

I am also facing similar issue since Nov 21.

Answer 2

Sabyasachi Bose 30

Hello Pashikanti,

Thank you for the quick response. Azure Service Health isn’t reporting any global issues, including for Functions and DNS in our region. Application Insights is enabled, and our Linux-based apps are using the default dnsRetryAttemptCount of 5. The failures occur even after all retries are exhausted.

If there is an underlying problem, why isn’t it reflected in Service Health?

And if there isn’t a problem, what’s causing these errors?

Appreciate your help in getting to the root of this.

Regards

Sabya

Akash Talole 0 Reputation points

2025-12-05T04:28:29.2566667+00:00

Hi @Sabyasachi Bose just want to check wheather you received solution from microsoft for this issue? Thank you
Sabyasachi Bose 30 Reputation points

2025-12-05T06:03:20.7466667+00:00

Yes, there is issue MS is working on around NAT port exhaustion at the Host VM level (Flex functions share a host; each outbound request to a public IP holds a NAT port for ~4 minutes). During spikes of concurrent calls, this can impact connectivity.

The workaround suggested was to aggressively use http connection pools. We have also started to cache resource clients as much as possible.

We are gradually rolling out the changes to all components and have seen significant improvements after the changes.
Akash Talole 0 Reputation points

2025-12-05T06:32:06.0466667+00:00

Than you so much @Sabyasachi Bose for sharing the updates.

Share via

DNS Failures in Apps on Consumption / Flex-Consumption Plans

2 answers

Your answer