Http connection request failed - DNS Resolution error

Question

I have an Azure VNet established. When I try making API calls through a python script on Azure ML, I get a DNS name resolution error (I am trying to reach my internal company server). What are the steps I must take/check for?

Answer 1

Hello @Noopur Shah

Thank you for reaching out to Microsoft Q&A.

Based on your description, the Python script running on Azure Machine Learning is unable to resolve the hostname of your internal company server. This typically indicates a DNS configuration or network connectivity issue between the Azure ML compute environment and your corporate DNS infrastructure.

Below are the recommended checks and troubleshooting steps.

1. Verify connectivity between Azure and your internal network

Confirm how the internal server is connected to Azure. If the server resides on-premises or in another private network, ensure that connectivity exists through one of the following:

• Site-to-Site VPN
• ExpressRoute
• VNet peering (if hosted in another Azure VNet)

Without proper network connectivity, Azure ML compute instances will not be able to reach either the internal server or the DNS servers responsible for resolving its hostname.

2. Validate the DNS configuration of the Azure VNet

Check which DNS servers are configured on the VNet hosting the Azure ML compute.

Navigate to Azure Portal → Virtual Network → DNS Servers

• If your organization uses custom DNS servers (for example, Active Directory DNS servers hosted on-premises), verify that the VNet is configured to use them.
• If the VNet uses Azure-provided DNS (168.63.129.16), internal company hostnames generally cannot be resolved unless conditional forwarding has been configured.

3. Ensure the Azure ML compute can reach the DNS servers

If custom DNS servers are being used:

• Verify that the Azure ML subnet can communicate with those DNS servers.
• Confirm that NSGs, firewalls, and UDRs do not block DNS traffic.

DNS requires:

• UDP port 53
• TCP port 53

A common cause of this issue is that the compute instance cannot route traffic to the configured DNS servers.

4. Verify DNS forwarding behavior

If your DNS servers are hosted on-premises or in a hub VNet, ensure they are forwarding requests appropriately.

Microsoft recommends that custom DNS servers forward Azure-specific queries to the Azure recursive resolver:

168.63.129.16

Improper forwarding configurations can result in hostname resolution failures.

5. Test DNS resolution from the Azure ML compute instance

Connect to the Azure ML compute instance and run:

nslookup <internal-server-name>

or

dig <internal-server-name>

Verify:

• Whether the hostname resolves successfully.
• Which DNS server responds.
• Whether the returned IP address is expected.

You may also review:

cat /etc/resolv.conf

to confirm which nameservers are configured.

6. Verify VNet peering and routing

If your DNS servers are located in another VNet:

Ensure that:

• VNet peering status is Connected
• "Allow virtual network access" is enabled
• Appropriate gateway transit and forwarding settings are configured
• Routes permit traffic between the Azure ML subnet and the DNS servers

Missing or misconfigured peering is another common cause of DNS failures.

7. Review outbound access restrictions

If outbound traffic from Azure ML is restricted using NSGs, Azure Firewall, or FQDN allowlists:

• Confirm that DNS traffic is permitted.
• Verify that required outbound destinations are not blocked.

Restrictive outbound rules can prevent both DNS resolution and access to dependent services.

8. If Private Endpoints are involved, validate Private DNS integration

If your internal services or Azure ML workspace use Private Endpoints:

Verify that:

• The appropriate Private DNS Zones exist.
• Private DNS Zone Groups are associated with the Private Endpoint.
• The Private DNS Zones are linked to the VNet hosting the Azure ML compute.
• DNS resolution returns the expected private IP address.

If DNS Zone Groups are missing or incorrectly configured, recreate the Private Endpoint with Private DNS integration enabled.

9. Isolate whether this is purely a DNS issue

As a quick validation, try connecting directly using the server's IP address instead of its hostname.

• If the IP address works but the hostname fails, the issue is isolated to DNS resolution.
• If both fail, the issue is more likely related to network connectivity or firewall restrictions.

Please refer this

https://learn.microsoft.com/azure/machine-learning/how-to-secure-workspace-vnet (Configure network traffic / Secure Azure ML with VNet)

https://learn.microsoft.com/azure/machine-learning/how-to-troubleshoot-secure-connection-workspace?view=azureml-api-2&wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#dns-configuration (Troubleshoot private endpoint connection problems—DNS configuration + nslookup validation)

https://learn.microsoft.com/azure/virtual-network/virtual-network-manage-peering?tabs=peering-portal#create-a-virtual-network-peering (VNet peering creation/requirements referenced by the DNS failure doc)

I Hope this helps. Do let me know if you have any further queries.

---

If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

Thank you!

Answer 2

I think Azure ML uses the VNet’s DNS settings as they are and the internal hostname has to resolve from a VM in the same VNet for the ML call to work.

Answer 3

Use the following checks to troubleshoot DNS resolution for API calls from Azure Machine Learning in a virtual network, especially when reaching an internal company server.

1. Confirm which DNS solution the VNet uses

• In the Azure portal, open the VNet used by the Azure ML compute.
• Under Settings → DNS servers, check:
  • Default (Azure-provided) or 168.63.129.16 → using Azure DNS.
  • Any other IP → using a custom DNS server.

2. If using a custom DNS server a. Verify that the custom DNS can resolve the target FQDNs

• From a VM or compute resource in the same VNet/topology as the Azure ML compute, run:

    nslookup <internal-server-fqdn>
  

• The result must be the correct internal IP address of the company server.
• If nslookup fails or returns the wrong IP, fix the custom DNS configuration (zones, records, or forwarders) so it correctly resolves the internal server.

b. Ensure the ML compute is actually using the custom DNS

• On a Linux-based compute/VM in the VNet, check:

    cat /etc/resolv.conf
  

• On Windows, use:

    Get-DnsClientServerAddress -AddressFamily IPv4
  

• The DNS server IPs here must match the DNS servers configured on the VNet.

c. Validate DNS server reachability

• From a VM/compute in the VNet, test connectivity to the DNS server on port 53:

    nc -zv <dns-server-ip> 53
  

  or on Windows PowerShell:

    Test-NetConnection -ComputerName <dns-server-ip> -Port 53
  

• If this fails, fix NSG/firewall/routing so the compute can reach the DNS server.

3. If using Azure DNS with private endpoints If the internal company server is exposed via a private endpoint or private DNS zone:

a. Confirm the correct private DNS zone and records

• Ensure the FQDN of the internal service has an A/CNAME record in the appropriate Private DNS Zone.
• Confirm that the zone is linked to the VNet used by the Azure ML compute.

b. Validate name resolution from inside the VNet

• From a VM/compute in the same VNet/topology, run for each relevant FQDN:

    nslookup <fqdn>
  

• The IP returned must match the private IP shown on the private endpoint or internal service.
• If a public IP is returned, or you see “Non-existent domain” / “Server failed”, the DNS/private zone linkage or records are misconfigured and must be corrected.

4. For Azure ML workspaces with private endpoints and custom DNS If the Azure ML workspace itself is using a private endpoint and a custom DNS server, verify that the DNS path is correctly configured end-to-end:

1. Locate workspace FQDNs

• In the Azure portal (using the ?feature.privateendpointmanagedns=false URL for the region), open the Private Endpoint for the Azure ML workspace.
• On the Overview tab, note the workspace FQDNs (for example, <guid>.workspace.<region>.api.azureml.ms, notebook FQDNs, or managed endpoint FQDNs).

2. Test resolution from a compute resource in the VNet topology

• From a VM/compute in the same VNet or a peered VNet, run:

    nslookup <workspace-fqdn>
  

• Each FQDN must resolve to one of the private IPs on the workspace’s private endpoint.
• If not, typical causes include:
  • The compute is not using the intended DNS server.
  • The Private DNS Zones used by the private endpoint are not linked to the DNS server’s VNet.
  • Conditional forwarders from the DNS server to Azure DNS (168.63.129.16) are missing or misconfigured.
  • On-premises DNS forwarders to the in-VNet DNS server are misconfigured.

5. Browser / client-side DNS features (if calling via browser tools) If testing connectivity via a browser (for example, calling APIs from a notebook UI in a browser):

• Disable DNS over HTTPS (DoH) in the browser (Edge/Firefox) so that DNS queries use the network/VNet DNS instead of a public resolver, which would break private endpoint resolution.

6. General Azure DNS troubleshooting for custom domains If the internal server is represented by a custom DNS zone in Azure DNS:

• Verify that the DNS record (zone name, record name, type) is correctly configured in Azure DNS.
• Confirm that the record resolves correctly on the Azure DNS name servers.
• If using external tools, ensure they query the correct authoritative name servers for the zone.

In summary, for DNS name resolution errors from Azure ML in a VNet, systematically verify:

• Which DNS servers the VNet and compute use.
• That those DNS servers can resolve the internal server FQDNs to the correct private IPs.
• That the DNS servers are reachable over port 53.
• That any private endpoints and private DNS zones are correctly configured and linked.

---

References:

• Troubleshoot the VMExtensionError_K8SAPIServerDNSLookupFail error in Azure Kubernetes Service
• Troubleshoot private endpoint connection problems
• Troubleshoot Azure DNS
• Troubleshoot connection to a project with a private endpoint (classic)
• How to use your workspace with a custom DNS server