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

Question

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

Michael Fowler 20

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?

Alex Burlachenko 4,225 Reputation points

2025-04-23T08:01:38.01+00:00
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
Chiugo Okpala 1,120 Reputation points MVP

2025-04-23T09:28:44.1733333+00:00
@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:

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.

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.

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.

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.

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.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-23T09:57:56.06+00:00

Hi Michael Fowler,
Just checking in to see if you had a chance to review the answer on your question addressed by "Alex Burlachenko ". Feel free to reach out if you have any further queries.

If you found the information helpful, please click "Upvote" and "Accept Answer" on the post to let us know.

Thank You.
Michael Fowler 20 Reputation points

2025-04-24T00:24:04.27+00:00
I'd like to thank everyone for their responses. I'm in a new subscription, there are no policies that are causing issues or any other types of restrictions. There are no firewalls or NSGs, these are the results of my testing. I can't resolve global.rdc.infrastructure.microsoft.com 168.63.129.16

Server: UnKnown

Address: 168.63.129.16

*** UnKnown can't find global.rdc.infrastructure.microsoft.com: Non-existent domain

Everything else I can.

PS C:\Users\mAdmin> Get-DnsClientServerAddress

InterfaceAlias Interface Address ServerAddresses

Index Family

Ethernet 6 IPv4 {168.63.129.16}

Ethernet 6 IPv6 {}

Loopback Pseudo-Interface 1 1 IPv4 {}

Loopback Pseudo-Interface 1 1 IPv6 {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}

PS C:\Users\mAdmin> nslookup login.microsoftonline.com

Server: UnKnown

Address: 168.63.129.16

Non-authoritative answer:

Name: www.tm.a.prd.aadg.akadns.net

Addresses: 2603:1016:1400:70::2

2603:1017:0:78:: 2603:1016:1400:68::4 2603:1016:1400:70::4 2603:1016:1400:68::3 2603:1016:1400:68::2 2603:1017:0:78::2 2603:1016:1400:68::5 20.190.167.66 20.190.167.64 20.190.167.19 20.190.167.21 20.190.167.18 20.190.167.20 20.190.167.149 20.190.167.148

Aliases: login.microsoftonline.com

login.mso.msidentity.com ak.privatelink.msidentity.com

PS C:\Users\mAdmin> nslookup global.rdc.infrastructure.microsoft.com

Server: UnKnown

Address: 168.63.129.16

*** UnKnown can't find global.rdc.infrastructure.microsoft.com: Non-existent domain

PS C:\Users\mAdmin> nslookup rdweb.wvd.microsoft.com

Server: UnKnown

Address: 168.63.129.16

Non-authoritative answer:

Name: waws-prod-sy3-a338ee95.sip.p.azurewebsites.windows.net

Address: 40.64.146.17

Aliases: rdweb.wvd.microsoft.com

rdweb.privatelink-global.wvd.microsoft.com rdweb-prod-geo.trafficmanager.net mrs-auer1c220-rdweb-prod.wvd-ase-auer1c220-prod.p.azurewebsites.net

PS C:\Users\mAdmin> nslookup www.bing.com

Server: UnKnown

Address: 168.63.129.16

Non-authoritative answer:

Name: e86303.dscx.akamaiedge.net

Addresses: 2600:1415:9c00:12::172e:ae3

2600:1415:9c00:12::172e:af3 23.32.5.33 23.32.5.41 23.32.5.31 23.32.5.38 23.32.5.30 23.32.5.40 23.32.5.39 23.32.5.46 23.32.5.25

Aliases: www.bing.com

www-www.bing.com.trafficmanager.net www.bing.com.edgekey.net

PS C:\Users\mAdmin> nslookup global.rdc.infrastructure.microsoft.com 168.63.129.16

Server: UnKnown

Address: 168.63.129.16

*** UnKnown can't find global.rdc.infrastructure.microsoft.com: Non-existent domain

PS C:\Users\mAdmin>
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-24T00:54:19.35+00:00

Hi Michael Fowler,

Thanks for getting back to us allow me some time we are looking into the issue will get back to on this as soon as possible

Thank You.
Michael Fowler 20 Reputation points

2025-04-24T03:30:24.7466667+00:00

An update. I've created a completely new environment. My VM using Azure NAT Gateway can reach all public Microsoft endpoints (login.microsoftonline.com, rdweb.wvd.microsoft.com), but cannot connect to global.rdc.infrastructure.microsoft.com:443. NAT is working, DNS is resolved (tried hosts file), but TCP connection is refused or dropped. I'm looking to find out if there might be a restriction somewhere else. In addition this is a brand new subscription.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-24T04:39:14.5266667+00:00
Hi Michael Fowler,

Even if NAT is working, inbound and outbound NSG rules can still block specific outbound traffic. Check NSG rules associated with the VM’s NIC, the subnet the VM is in.

Specifically, ensure you have an allow rule for outbound TCP traffic on port 443 to global.rdc.infrastructure.microsoft.com.

Check NSG rules associated with that VM NIC and the Subnet that VM relies.

Steps to add NSG rule:

use nslookup to get ip address

nslookup global.rdc.infrastructure.microsoft.com

If there are no existing outbound NSG rules allowing access to global.rdc.infrastructure.microsoft.com, you can create a new outbound rule in the NSG associated with the VM’s subnet.

Use the above ip to create NSG outbound rule pointing that to destination-address-prefixes below:

az network nsg rule create \ --resource-group <your-resource-group> \ --nsg-name <your-nsg-name> \ --name AllowOutboundRDC \ --priority 200 \ --direction Outbound \ --access Allow \ --protocol Tcp \ --source-address-prefixes '*' \ --destination-address-prefixes <ip-1> <ip-2> \ --destination-port-ranges 443 \ --description "Allow outbound HTTPS to global.rdc.infrastructure.microsoft.com"

I hope this is helpful, Let me know if you have any further queries!

Thank you.
Michael Fowler 20 Reputation points

2025-04-24T04:43:27.4533333+00:00

I have removed the NSGs to support my troubleshooting, so there is nothing that should be preventing that connection. Also nslookup does not resolve the IP address for global.rdc.infrastructure.microsoft.com .

I'm kind of stuck at this point but appreciate those that are looking out.
Michael Fowler 20 Reputation points

2025-04-24T07:27:53.69+00:00

It appears that global.rdc.infrastructure.microsoft.com has been deprecated. I couldn't find it here https://learn.microsoft.com/en-us/azure/virtual-desktop/required-fqdn-endpoint?tabs=azure. What i did do was to re-register the resource providers for AVD and then deploy a quick start and it has worked. This seems to make sense.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-24T07:50:58.83+00:00

Hi Michael Fowler,

As you mentioned in your comment, could you please confirm if you referred to the information I shared in previous private message, or if you found it on your side? That would be great to know.

Also, can you please confirm whether the issue has been resolved or if it still persists? Let me know

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

Accepted answer

0 additional answers

Your answer

Alex Burlachenko 4,225 Reputation points

2025-04-23T08:01:38.01+00:00

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
Chiugo Okpala 1,120 Reputation points MVP

2025-04-23T09:28:44.1733333+00:00

@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:

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.

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.

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.

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.

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.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-23T09:57:56.06+00:00

Hi Michael Fowler,
Just checking in to see if you had a chance to review the answer on your question addressed by "Alex Burlachenko ". Feel free to reach out if you have any further queries.

If you found the information helpful, please click "Upvote" and "Accept Answer" on the post to let us know.

Thank You.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-24T00:54:19.35+00:00

Hi Michael Fowler,

Thanks for getting back to us allow me some time we are looking into the issue will get back to on this as soon as possible

Thank You.
Michael Fowler 20 Reputation points

2025-04-24T03:30:24.7466667+00:00

An update. I've created a completely new environment. My VM using Azure NAT Gateway can reach all public Microsoft endpoints (login.microsoftonline.com, rdweb.wvd.microsoft.com), but cannot connect to global.rdc.infrastructure.microsoft.com:443. NAT is working, DNS is resolved (tried hosts file), but TCP connection is refused or dropped. I'm looking to find out if there might be a restriction somewhere else. In addition this is a brand new subscription.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-24T04:39:14.5266667+00:00

Hi Michael Fowler,

Even if NAT is working, inbound and outbound NSG rules can still block specific outbound traffic. Check NSG rules associated with the VM’s NIC, the subnet the VM is in.

Specifically, ensure you have an allow rule for outbound TCP traffic on port 443 to global.rdc.infrastructure.microsoft.com.

Check NSG rules associated with that VM NIC and the Subnet that VM relies.

Steps to add NSG rule:

use nslookup to get ip address

nslookup global.rdc.infrastructure.microsoft.com

If there are no existing outbound NSG rules allowing access to global.rdc.infrastructure.microsoft.com, you can create a new outbound rule in the NSG associated with the VM’s subnet.

Use the above ip to create NSG outbound rule pointing that to destination-address-prefixes below:

az network nsg rule create \ --resource-group <your-resource-group> \ --nsg-name <your-nsg-name> \ --name AllowOutboundRDC \ --priority 200 \ --direction Outbound \ --access Allow \ --protocol Tcp \ --source-address-prefixes '*' \ --destination-address-prefixes <ip-1> <ip-2> \ --destination-port-ranges 443 \ --description "Allow outbound HTTPS to global.rdc.infrastructure.microsoft.com"

I hope this is helpful, Let me know if you have any further queries!

Thank you.
Michael Fowler 20 Reputation points

2025-04-24T04:43:27.4533333+00:00

I have removed the NSGs to support my troubleshooting, so there is nothing that should be preventing that connection. Also nslookup does not resolve the IP address for global.rdc.infrastructure.microsoft.com .

I'm kind of stuck at this point but appreciate those that are looking out.
Michael Fowler 20 Reputation points

2025-04-24T07:27:53.69+00:00

It appears that global.rdc.infrastructure.microsoft.com has been deprecated. I couldn't find it here https://learn.microsoft.com/en-us/azure/virtual-desktop/required-fqdn-endpoint?tabs=azure. What i did do was to re-register the resource providers for AVD and then deploy a quick start and it has worked. This seems to make sense.
Pramidha Yathipathi 325 Reputation points Microsoft External Staff

2025-04-24T07:50:58.83+00:00

Hi Michael Fowler,

As you mentioned in your comment, could you please confirm if you referred to the information I shared in previous private message, or if you found it on your side? That would be great to know.

Also, can you please confirm whether the issue has been resolved or if it still persists? Let me know

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

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.

User's image

Thank you.

Share via

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

0 additional answers

Your answer