Azure Blob storage: Cannot connect to host name.blob.core.windows.net:443 ssl:default [Temporary failure in name resolution]

Question

Azure Blob storage: Cannot connect to host ********.blob.core.windows.net:443 ssl:default [Temporary failure in name resolution]
This issue occurs occasionally while uploading .parquet files on Data lake.

Location : East US
Primary/Secondary Location

Primary: East US, Secondary: West US

Performance : Standard
Replication : Geo-redundant storage (GRS)
Account kind : StorageV2 (general purpose v2)
Disk state : Primary: Available, Secondary: Available

Answer 1

Hi @govind,

The error message "Temporary failure in name resolution" typically indicates a DNS resolution issue, which means that your system is unable to resolve the hostname to an IP address.

Troubleshooting steps:

1. Check Network Connectivity: Ensure that your network connection is stable and that you can access other internet resources.
2. DNS Configuration: Verify that your DNS settings are correctly configured on the machine uploading the .parquet files to Data Lake. Try using a public DNS server like Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1) temporarily to see if it resolves the issue.
3. Firewall and Security Groups: Check if there are any firewall rules or security group settings that might be blocking access to the Azure Blob Storage endpoint.
4. Retry the Operation: Since the issue occurs occasionally, it might be a temporary network glitch. Retry the upload after a short time.

Please let us know if you have any further queries. I’m happy to assist you further.

Please consider to “up-vote” and "Accept the answer" wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Hello govind,

Thanks for reaching out over Q&A forum.

Based on the above exception, it points that the connection to storage wasn't successful due to name resolution failing and not necessarily an issue on the storage account side.

In order to isolate this, you can do quick test such as telnet, nslookup etc from the same machine. As you mentioned it is occasionally, it is quite possible that this is momentarily and the above might also resolve successfully when you will try them out. In that case, if it is transient you can retry the operation and also explore connectivity over Private endpoint, in case not already.

Hope this helps! Please let us know if you have any further quires, we will be glad to assist you.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.