Azure http function Timeout while contacting DNS servers

Question

Azure http function Timeout while contacting DNS servers

Sean Doherty 50

I have a python Azure storage queue function running on consumption plan accessing a separate Azure HTTP function on a flex consumption plan connected to a vnet. I am regularly seeing errors like the following:

Result: Failure Type: Exception: ClientConnectorDNSError: Cannot connect to host xxx.azurewebsites.net:443 ssl:default [Timeout while contacting DNS servers]

Where xxx.azurewebsites.net is the flex consumption plan Azure function app hosting the HTTP end point.

We have set up retry attempts within the python code, but given the frequency of these errors we see long processing times on our Azure storage queue function.

We are using the default Azure DNS.

Zark Khan 0

Hi Sean,

Thank you for sharing the details. The ClientConnectorDNSError: Timeout while contacting DNS servers usually happens when a function in a consumption plan tries to access a VNet-integrated flex consumption function using default DNS. Here’s a step-by-step approach to address the issue:

Understand the Cause

Consumption plan functions use dynamic outbound IPs and the default Azure DNS.

  When the target function is inside a VNet (flex consumption), DNS resolution can fail intermittently because the default DNS cannot always reach the private endpoints.
  
  **Configure Proper DNS for VNet Access**
  
     If the flex function is in a VNet, you need to configure **custom DNS** that can resolve the VNet-integrated function app.
     
        Options include:
        
              Use **Azure-provided DNS** with a private endpoint.
              
                    Or deploy a **private DNS zone** linked to the VNet hosting the flex function.
                    
                    **Use Private Endpoints / VNet Integration**
                    
                       For reliable communication, consider adding a **private endpoint** to the flex function and configure the queue function to access the private DNS zone.
                       
                          This avoids relying on public DNS resolution, which can fail intermittently.
                          
                          **Check Function App Networking**
                          
                             Ensure the flex function allows inbound traffic from your consumption plan (or any service using a managed identity if needed).
                             
                                Consider enabling **Service Endpoints** or **VNet rules** if required.
                                
                                **Optional: Implement Exponential Backoff Retries**
                                
                                   Since DNS timeouts may still occasionally occur, ensure your Python function uses **exponential backoff** with retries to handle transient failures gracefully.
                                   
                                   **Monitoring**
                                   
                                      Monitor DNS resolution errors using **Application Insights** and **Azure Monitor** to verify if changes reduce timeout frequency.

Following these steps should significantly reduce DNS timeouts and improve processing times on your storage queue function.

Sean Doherty 50 Reputation points

2025-12-30T06:29:01.2+00:00

Thanks, Zark for the suggestions. Given the consumption plan cannot connect to a vnet, then I imagine it won't be able to connect to a private DNS zone, right?

We have enabled public network access on the flex consumption hosted http function. We don't have any issues accessing from a public network.

2 answers

Your answer

Zark Khan 0 Reputation points

2025-12-30T05:47:23.86+00:00

Hi Sean,

Thank you for sharing the details. The ClientConnectorDNSError: Timeout while contacting DNS servers usually happens when a function in a consumption plan tries to access a VNet-integrated flex consumption function using default DNS. Here’s a step-by-step approach to address the issue:

Understand the Cause

Consumption plan functions use dynamic outbound IPs and the default Azure DNS.

When the target function is inside a VNet (flex consumption), DNS resolution can fail intermittently because the default DNS cannot always reach the private endpoints. **Configure Proper DNS for VNet Access** If the flex function is in a VNet, you need to configure **custom DNS** that can resolve the VNet-integrated function app. Options include: Use **Azure-provided DNS** with a private endpoint. Or deploy a **private DNS zone** linked to the VNet hosting the flex function. **Use Private Endpoints / VNet Integration** For reliable communication, consider adding a **private endpoint** to the flex function and configure the queue function to access the private DNS zone. This avoids relying on public DNS resolution, which can fail intermittently. **Check Function App Networking** Ensure the flex function allows inbound traffic from your consumption plan (or any service using a managed identity if needed). Consider enabling **Service Endpoints** or **VNet rules** if required. **Optional: Implement Exponential Backoff Retries** Since DNS timeouts may still occasionally occur, ensure your Python function uses **exponential backoff** with retries to handle transient failures gracefully. **Monitoring** Monitor DNS resolution errors using **Application Insights** and **Azure Monitor** to verify if changes reduce timeout frequency.

Following these steps should significantly reduce DNS timeouts and improve processing times on your storage queue function.
Sean Doherty 50 Reputation points

2025-12-30T06:29:01.2+00:00

Thanks, Zark for the suggestions. Given the consumption plan cannot connect to a vnet, then I imagine it won't be able to connect to a private DNS zone, right?

We have enabled public network access on the flex consumption hosted http function. We don't have any issues accessing from a public network.

Answer 1

Hello @Sean Doherty,

Thanks for using Q and A forum.

The error you’re encountering, ClientConnectorDNSError: Cannot connect to host xxx.azurewebsites.net:443 ssl:default [Timeout while contacting DNS servers], typically indicates a DNS resolution issue. This can happen when your Azure Function on the consumption plan is trying to reach the HTTP endpoint hosted on a flex consumption plan that is connected to a VNet. Here are some steps you can take to troubleshoot and potentially resolve the issue:

Check VNet Configuration: Ensure that the VNet configuration allows outbound traffic from your Azure Function to the HTTP endpoint.
DNS Settings: Since you’re using the default Azure DNS, you might want to check if there are any custom DNS settings that could be affecting the resolution. If your HTTP function is deployed in a different region or has specific DNS requirements, consider configuring a private DNS zone.
Connection Pooling: Implement connection pooling and keep-alive settings in your Azure Function to reduce the frequency of DNS lookups and improve connection reuse.

By following these steps, you should be able to reduce the occurrence of DNS-related errors.

If the Answer is helpful, please click Accept Answer and Up-Vote 👍, so that this can be beneficial to other community members.

Sean Doherty 50 Reputation points

2025-12-31T01:26:29.0233333+00:00

Thanks for your suggestions, Sunoj. We have improved our connection pooling and that seems to be making a difference to the DNS failure rate.

Answer 2

Siddhesh Desai 7,400 Microsoft External Staff Moderator

Hi @Sean Doherty

Thank you for reaching out to Microsoft Q&A

Consumption plan Function cannot reach VNET, as a workaround you will have to try below options to resolve the DNS errors:

Use Azure Front Door or APIM in front of the Flex Function

Step 1: Add Private Endpoint to the Flex Function

Go to Flex Consumption Function App

Open Networking → Private endpoint connections

Click + Private endpoint

Select: Sub‑resource: sites

VNet: same VNet used for Flex integration

Subnet: dedicated, empty subnet

Approve the private endpoint connection

Step 2: Configure private DNS

Create Private DNS zone:

privatelink.azurewebsites.net

Link it to the Flex Function VNet

Confirm the Flex app resolves to a private IP inside the VNet

Step 3: Disable public access on the Flex Function

Flex Function → Networking

Set:

Public network access = Disabled

Step 4: Create Azure Front Door or APIM

Azure Front Door (Standard / Premium)

Create a Front Door profile

Add the Flex Function as an origin

Enable Private Link to origin

Approve the Private Link connection

Use the Front Door endpoint hostname

Step 5: Update the Consumption Function

Replace:

https://<flex-app>.azurewebsites.net

With:

https://<frontdoor-or-apim-endpoint>

Keep the Flex Function Public and Secure It

Step 1: Enable public access

Flex Function → Networking

Set: Public network access = Enabled

Step 2: Secure inbound access

Use one or more of:

Function keys

Azure AD authentication

IP access restrictions (where possible)

Managed Identity authentication

Step 3: Do not add a Private Endpoint

Adding a Private Endpoint while keeping a Consumption caller will cause DNS failures.

Move the Caller to a Plan That Supports VNet Integration

Step 1: Move Function to: Premium plan, or Flex Consumption plan

Step 2: Enable VNet integration on both Functions

Integrate both Function Apps with the same VNet

Use a dedicated subnet for each integration

Step 3: (Optional) Add Private Endpoints

Add Private Endpoint to the Flex Function

Ensure Private DNS zone privatelink.azurewebsites.net is linked

Both apps can now resolve the private endpoint

Sean Doherty 50 Reputation points

2025-12-31T01:24:59.6066667+00:00

At this point in time we are using "Keep the Flex Function Public and Secure It". The problem seems to be a high failure rate. Most of the time it works.
Siddhesh Desai 7,400 Reputation points Microsoft External Staff Moderator

2026-01-07T10:27:18.5133333+00:00

Hi @Sean Doherty

One more option is to convert the Caller function in Premium app or consumption app. Does the problem still occur when you keep both the function app as public?
Pravallika KV 16,945 Reputation points Microsoft External Staff Moderator

2026-01-09T06:43:01.5333333+00:00

Hi @Sean Doherty, following up to see if you had a chance to check the above response of Siddhesh and if it was helpful. Please let me know if you have any questions.
Sean Doherty 50 Reputation points

2026-01-11T22:53:23.8166667+00:00

Hi Pravallika KV and Siddesh. We have always been running http function as public with the problem still occurring. Pooling service connections has reduced the frequency of the problem. We may look at moving the caller function flex or praemium function apps and connecting via vnet, but not sure if that will benefit if we need to keep the http service function public.
Pravallika KV 16,945 Reputation points Microsoft External Staff Moderator

2026-01-22T08:57:08.5+00:00
Sean Doherty, you’re right that keeping the HTTP function public rules out Private Endpoint–only solutions.

However, moving the caller function to Flex Consumption or Premium and enabling VNet integration can still provide a benefit, even if the HTTP function remains public.

The key issue here isn't inbound connectivity to the HTTP function, but outbound DNS resolution from the caller. On the Consumption plan, outbound calls rely on shared Azure DNS infrastructure, which is known to occasionally produce transient DNS timeouts under load. Connection pooling reduces the frequency by limiting DNS lookups, but it doesn’t remove that dependency.

With Flex or Premium:

The caller’s outbound traffic (including DNS) goes through the VNet DNS path, which is generally more stable and predictable.

This improves reliability for calls to both public and private endpoints.

No Private Endpoint or public access change is required on the HTTP function.

So while keeping the HTTP function public is fine, moving the caller to Flex/Premium with VNet integration is still a valid mitigation for the DNS errors you’re seeing.
Pravallika KV 16,945 Reputation points Microsoft External Staff Moderator

2026-01-23T06:09:11.4733333+00:00

Hi @Sean Doherty, following up to see if you had a chance to check the above response of Siddhesh and if it was helpful. Please let me know if you have any questions.
Sean Doherty 50 Reputation points

2026-01-23T06:15:18.3866667+00:00

That is good to know that vnet will help. We will try this but might be a couple of weeks away. We are surviving with the current failure rate.

Share via

Azure http function Timeout while contacting DNS servers

2 answers

Your answer