Network connection issue with private in machine learning workstation: customer DNS and Azure DNS

rain purple 300 Reputation points
2026-07-16T23:56:32.82+00:00

Hello, support team:

There's a feedback with machine learning workstation with network issue, but don't know/understand what happened?

sometimes I can use it, sometimes I can't loading, the networking settings is the same with both situation.

but the feedback is different, now it becomes with DNS issue, so how to check the DNS from customer and Azure, also how to set it?

User's image

Thanks, have a good working week and relaxing weekend.

user from Azure portal

Azure Machine Learning
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jose Benjamin Solis Nolasco 9,806 Reputation points Volunteer Moderator
    2026-07-17T02:45:55.0766667+00:00

    Welcome to Microsoft Q&A

    Hello @rain purple , I hope you are doing well.

    Since Workspace Diagnostics reports no issues but you're intermittently receiving:

    "You are attempting to access a restricted resource from an unauthorized network location."

    the issue is most likely related to network connectivity or DNS resolution rather than the Azure Machine Learning workspace itself.

    Based on your latest findings, I recommend checking the following:

    • Verify that the client and the Machine Learning compute resource consistently resolve the workspace private endpoint FQDNs to their private IP addresses using nslookup.
    • If you're using custom DNS, ensure that:
      • Conditional forwarders are correctly configured.
        • The Private DNS Zones are properly linked to the virtual network.
          • The DNS server can resolve Azure Private Link records correctly.
          • If you're using Azure-provided DNS, verify that the Private Endpoint has an associated DNS Zone Group and that the required Private DNS Zones are linked to the virtual network.
          • Review any Network Security Groups (NSGs), User Defined Routes (UDRs), or Azure Firewall rules to ensure they are not intermittently blocking DNS (TCP/UDP 53) or connectivity to the private endpoint.
          • If the issue only occurs from certain networks or client machines, compare the DNS resolution and routing results between a working and a failing client to identify configuration differences.

    The fact that the problem is intermittent usually indicates inconsistent DNS resolution or differences in the network path, rather than a problem with the Azure Machine Learning workspace itself.

    References

    If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.This helps others in the community find similar solutions.

    Was this answer helpful?

  2. rain purple 300 Reputation points
    2026-07-17T00:48:48.6933333+00:00

    hello, dear AI assistant, follow your guideline, above is okay for Azure DNS, but the issue is continued.

    the current situation is:

    Error loading workspace :You are attempting to access a restricted resource from an unauthorized network location. Please contact your administrator or follow the troubleshooting instructions here.Back to all workspaces

    Workspace Diagnostics : no errors found

    Need a further checking with this resource, but the sending ticket path is unknown .

    Thanks

    user from Azure portal with developer support plan

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-07-16T23:56:54.4566667+00:00

    The error indicates the workspace is using a custom DNS path, but the workspace FQDNs are not resolving to the private endpoint private IPs consistently. That matches an intermittent access pattern: sometimes resolution works, sometimes it does not.

    Use this check sequence.

    1. Determine whether the virtual network is using Azure DNS or custom DNS
      1. In the Azure portal, open the private endpoint for the Azure Machine Learning workspace.
      2. On Overview, select the Network Interface link.
      3. Under Settings > IP Configurations, select the Virtual network link.
      4. In that virtual network, open DNS servers.
      5. Interpret the result:
        • Default (Azure-provided) or 168.63.129.16 = Azure DNS
        • Any other IP address = custom DNS
    2. If the network uses custom DNS, verify name resolution
      1. In the portal, open the workspace private endpoint and note the workspace FQDNs shown on the private endpoint.
      2. From a VM or compute resource that connects through the same virtual network topology, run: 
              nslookup <workspace FQDN>
      3. Run it for each workspace FQDN.
      4. Expected result: each lookup returns one of the private IP addresses assigned to the workspace private endpoint.
      5. If nslookup returns an error, a public IP, or an IP different from the portal, the custom DNS configuration is incorrect.
    3. Common custom DNS causes to check
      • The compute resource is not actually using the intended DNS server for name resolution.
      • The Private DNS zones selected when the private endpoint was created are not linked to the DNS server virtual network.
      • Conditional forwarders from the DNS server to the Azure DNS virtual server IP are configured incorrectly.
      • If on-premises DNS is involved, conditional forwarders from the on-premises DNS server to the DNS server are configured incorrectly.
    4. If the network uses Azure DNS, verify private DNS integration
      1. On the private endpoint, open DNS configuration.
      2. For each Private DNS zone entry, there should also be a DNS zone group entry.
      3. If there is a Private DNS zone entry but no DNS zone group, delete and recreate the private endpoint, and enable Private DNS zone integration when recreating it.
        • Warning: recreating a private endpoint changes connectivity configuration and should be planned carefully.
      4. If a DNS zone group exists, open the Private DNS zone.
      5. In the zone, open Virtual network links.
      6. Confirm the virtual network is linked. If it is not, delete and recreate the private endpoint using a Private DNS zone linked to that virtual network, or create a new linked zone.
    5. Check browser DNS behavior Browser DNS over HTTPS can bypass network DNS and break private endpoint resolution.
      • In Microsoft Edge: Settings > search for DNS > disable Use secure DNS to specify how to look up the network address for websites.
    6. If DNS still fails intermittently A network control may be blocking DNS traffic. One documented cause is an NSG, Azure Firewall rule, or user-defined route blocking UDP or TCP port 53 between the client and its configured DNS target.

    The key validation is simple: from the affected network, nslookup for every workspace FQDN must return the private endpoint private IP shown in the portal. If it does not, fix DNS before investigating the workspace itself.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.