Azure Data Factory Copy activity failing due DNS resolution issue

Hi @Sahil Chaudhry

From the error you shared, the copy activity is failing because the runtime can’t resolve the storage account hostname:

The remote name could not be resolved: <storage account name>.dfs.core.windows.net

That’s a DNS resolution/network name resolution symptom (not necessarily an ADF connector/auth issue). Since this started “suddenly” a few days ago, the most common causes are changes in DNS settings, firewall/proxy/egress restrictions, managed network/private endpoint/DNS configuration, or integration runtime networking.

What to try (based on common ADF connectivity troubleshooting)

1) Verify which Integration Runtime is being used

In ADF, check the copy activity / linked services to confirm whether the job is running on:

• Self-hosted IR (SHIR) (hosted on your VM), or
• Azure IR with Managed VNet.

Then proceed using the matching troubleshooting path:

• For SHIR, you troubleshoot from the SHIR VM.
• For Managed VNet, you validate managed VNet/private link/DNS behavior.

2) Test “name resolution” from the same machine/runtime that executes the copy

If your VM is acting as the SHIR, run DNS tests on that VM (because it’s where the request originates):

• Use nslookup <storage-account-name>.dfs.core.windows.net
• If DNS resolution fails there, the storage endpoint can’t be reached by hostname—so the HTTP request fails with the error you’re seeing.

If you’re using Managed VNet/Private endpoints, make sure the private DNS zone / DNS resolution is correctly set up so that the hostname resolves to the expected private IP.

3) Ensure networking security components didn’t change

Even if the storage account is “disabled from all networks,” you can still see failures if something changed in one of these places:

• corporate firewall / router egress rules
• VPN/NSG rules
• proxy configuration on the IR VM (SHIR) or in the environment

ADF guidance here is to review firewalls/NSGs/VPN and confirm required ports/domains are allowed for the integration runtime and its connectivity path.

4) Check ADF IR connection troubleshooting + logs

To get the exact connectivity failure details:

• For SHIR, check Integration Runtime connector logs on the SHIR VM via Windows Event Viewer:
  • Event Viewer > Application and Services Logs > Integration Runtime and Connectors (and/or Integration Runtime logs depending on the guide)
• For Azure IR (Managed VNet), review ADF monitoring and confirm the managed networking/private link assumptions.

ADF also recommends testing the linked service connection using ADF → Author → Connections / Test connection (where applicable) and reviewing activity/connector logs.

5) If storage is private (private endpoint), validate DNS specifically

Your message says there is no network connectivity between source VM and storage (and storage is “disabled from all networks”). That strongly suggests you’re relying on some form of private access pattern—most often Private Endpoint + Private DNS.

If DNS stopped resolving days ago, that usually points to a private DNS zone association change, DNS server change, or private endpoint/DNS record change.

Why it “worked earlier” and now doesn’t

With DNS-based errors, the usual “no code change” causes are:

• DNS server update/change on the SHIR VM (or in the network path)
• Private DNS zone records/links changed (for storage private access)
• Firewall/egress rule or proxy setting changed, affecting DNS queries or outbound resolution
• Private endpoint or related network rules changed, causing the hostname not to resolve

Follow-up questions (so we can pinpoint the root cause quickly)

1. Which Integration Runtime is the copy activity using right now: Self-hosted IR (on the VM) or Azure IR (Managed VNet)?
2. Are you using Private Endpoint for the storage account (or any private access mechanism)? If yes, what DNS method are you using (private DNS zone, custom DNS server, etc.)?
3. On the SHIR VM, what is the result of nslookup <storage-account-name>.dfs.core.windows.net?
4. Did anything change in the last few days in DNS/proxy/firewall/NSG/VPN rules for the SHIR VM or the network path to Azure?
5. If you enable storage public access temporarily, does DNS still fail on the SHIR VM (or does it only fail at the HTTP call stage)?
6. Can you share the ADF Activity ID or the relevant integration runtime log excerpt from the time of failure (no sensitive data—just the error context)?

References (relevant docs from the provided materials)

• Resolve connector or connectivity issues when copying with Azure Data Factory: https://supportabilityhub.microsoft.com/solutions/apollosolutions/c345e3fb-4ac8-ef45-f217-37e7777487be/v2-connectivity-howto-apollo
• Troubleshoot issues reading or writing data using Copy activity (connectivity between IR and source/sink, firewall/IP allowlisting, SHIR connectivity + logs): https://supportabilityhub.microsoft.com/solutions/apollosolutions/539cd045-0e38-df43-c9be-d56775ed1ada/c8cf276e-e387-4c1b-b563-8439217e8771
• Troubleshoot Copy Activity Failures Between AWS S3 and Azure SQL Using Azure Data Factory (IR + managed VNet configuration): https://supportabilityhub.microsoft.com/solutions/apollosolutions/c345e3fb-4ac8-ef45-f217-37e7777487be/efdfecec-6379-465c-ba54-cd4d098ab6e83
• Troubleshoot Azure Data Factory and Azure Synapse pipelines (web/connection failure guidance; DNS troubleshooting note): https://learn.microsoft.com/azure/data-factory/data-factory-ux-troubleshoot-guide?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#connection-failed-error-in-azure-data-factory-studio
• Troubleshoot Azure Data Factory connectors / general copy activity errors: https://learn.microsoft.com/azure/data-factory/connector-troubleshoot-guide?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#general-copy-activity-errors

Hello Sahil !

Thank you for posting on MS Learn Q&A.

This error should be investigated from the Self-hosted IR VM. Since the message says remote name could not be resolved.the VM cannot resolve the ADLS Gen2 DFS endpoint.

Try to run nslookup <storage>.dfs.core.windows.net and Test-NetConnection <storage>.dfs.core.windows.net -Port 443 from the SHIR VM.

If the storage account has public access disabled, the VM needs a valid private network path to the storage account, normally through Private Endpoint plus Private DNS. For ADLS Gen2, configure both DFS and Blob private endpoints and link/configure the private DNS zones privatelink.dfs.core.windows.net and privatelink.blob.core.windows.net. Opening the storage account publicly will not fix this specific error if DNS resolution itself is failing.