Unable to resolve global.rdc.infrastructure.microsoft.com from Azure VM (NXDOMAIN from 8.8.8.8 and 1.1.1.1)

Question

• I'm deploying AVD in Azure. DNS resolution to global.rdc.infrastructure.microsoft.com fails even when using the Azure-provided DNS (168.63.129.16) inside my VNet. Public resolvers like 8.8.8.8 and 1.1.1.1 also return NXDOMAIN — as expected. But this domain should resolve internally for AVD to provision. Is DNS resolution to control plane endpoints blocked in certain new Azure subscriptions or regions?

Answer 1

Hi Michael Fowler,

In your new subscription, the Microsoft.DesktopVirtualization provider must be registered. Even if it shows as registered, sometimes unregistering and re-registering triggers the DNS control plane endpoint propagation.

Check and (Re)Register the Required Azure Resource Provider

Check registration:

az provider show --namespace Microsoft.DesktopVirtualization --query "registrationState"

 If it’s Registered, unregister it:

az provider unregister --namespace Microsoft.DesktopVirtualization

Then re-register:

az provider register --namespace Microsoft.DesktopVirtualization

Wait about 2-5 minutes for registration and propagation.

and then restart the Azure VM

Once the provider is registered again:

az vm restart --resource-group <YourResourceGroup> --name <YourVMName>

This ensures the VM picks up the latest internal DNS control plane zones.

Test DNS Resolution Again

From inside your VM:

nslookup global.rdc.infrastructure.microsoft.com 168.63.129.16

https://learn.microsoft.com/en-us/azure/virtual-desktop/private-link-setup?tabs=azure%2Cportal%2Cportal-2#initial-feed-discovery

As the information was helpful, please click "Upvote" and "Accept Answer" on the post to let us know.

Accepted answer will help other community members navigate to the appropriate solutions.

Thank you.

Answer 2

Dear Mr. Fowler,

Thank you for your follow-up question regarding DNS resolution for Azure Virtual Desktop (AVD) control plane endpoints. To address your concern directly: No, DNS resolution to AVD control plane endpoints (such as global.rdc.infrastructure.microsoft.com) is not intentionally blocked in any Azure subscriptions or regions. This domain should resolve internally when using Azure’s default DNS (168.63.129.16) within your VNet.

Confirm VNet DNS Settings:

Ensure your VNet or VM NIC is explicitly set to use Azure’s DNS (168.63.129.16) and not a custom resolver.

nslookup global.rdc.infrastructure.microsoft.com 168.63.129.16

Review Service Dependencies and verify that the WindowsVirtualDesktop service tag is allowed in your NSGs/ firewall rules.

Check for AVD-specific network requirements.

Subscription/Region-Specific Checks:

If this is a new subscription, ensure there are no Azure Policy restrictions on DNS or network egress.

Temporary workaround: Test in another region to isolate the issue.

Escalate to Microsoft Support:

If the domain still fails to resolve, this may indicate a platform-level issue.

Best regards,

Alex

P.S. If my answer help to you, please Accept my answer

Answer 3

@Michael Fowler welcome to the Microsoft Q&A community.

It seems like you're encountering a DNS resolution issue specific to the Azure Virtual Desktop (AVD) control plane endpoint. Here are some potential reasons and steps to troubleshoot:

1. Azure DNS Configuration: Ensure that your virtual network is correctly configured to use Azure-provided DNS (168.63.129.16). This is essential for resolving internal Azure endpoints like global.rdc.infrastructure.microsoft.com.
2. Subscription or Region-Specific Restrictions: While there are no known restrictions for DNS resolution to control plane endpoints in new Azure subscriptions or regions, it's worth verifying with Azure support if there are any specific limitations or configurations affecting your subscription.
3. Firewall or Network Security Group (NSG) Rules: Check if there are any outbound rules in your NSG or firewall that might be blocking DNS traffic or access to the control plane endpoint.
4. Private DNS Zones: If you're using Azure Private DNS zones, ensure that the necessary records for global.rdc.infrastructure.microsoft.com are correctly configured and linked to your virtual network.
5. Azure Service Health: Verify the Azure Service Health dashboard to check for any ongoing issues or outages affecting AVD or DNS resolution in your region. If these steps don't resolve the issue, reaching out to Azure support might be the best course of action to get detailed insights into your specific setup. Let me know if you'd like help with any of these steps!

I hope these helps. Let me know if you have any further questions or need additional assistance.

Also if these answers your query, do click the "Upvote" and click "Accept the answer" of which might be beneficial to other community members reading this thread.