Hi all, I am doing some PoC around Azure private DNS zones and it's auto-registration features. I created two vnets a central private DNS zone and linked both of the Vnets to the Zone with auto-registration enabled (in both of the vnet links). However, I noticed that hosts deployed in Vnet1 can resolve hosts which are deployed in the Vnet1, but cannot for those which are created in Vnet2. It seems very weird to me because both of the Vnets are linked to the same DNS Zone and a resolution should be given. Any help on understanding this better would be greatly appreciated. PFB some snips for reference. Note: Both Vnet are peered to each other. PS : I tried disabling auto-registration on one of the links and tried creating manual records but no luck. DNS Zone Private Link: Intra Vnet resolution: Inter Vnet resolution however, ping to IP of the host works:

Hi Apurva, You need to use the FQDN instead (so it knows suffix to use), similar to below: ping azulvnet002.yourdomain.com If you want you could add your domain name to the search directive in the VM's /etc/resolv.conf file. For example, something similar to below: search vt20vdk0ae4udlttckjrbsgtjb.zx.internal.cloudapp.net yourdomain.com With the name added on to the end of the search directive you could then enter ping azulvnet02 if you wanted and it would work since it would know to try to resolve using azulvnet02.yourdomain.com. Please click Accept Answer and upvote if the above was helpful. Thanks. -TP

Azure Private DNS Zone unable to resolve hostname created in a different Vnet

Accepted answer

TP 95,556 Reputation points

2024-09-22T16:15:11.6166667+00:00
Hi Apurva,

You need to use the FQDN instead (so it knows suffix to use), similar to below:

ping azulvnet002.yourdomain.com

If you want you could add your domain name to the search directive in the VM's /etc/resolv.conf file. For example, something similar to below:

search vt20vdk0ae4udlttckjrbsgtjb.zx.internal.cloudapp.net yourdomain.com

With the name added on to the end of the search directive you could then enter ping azulvnet02 if you wanted and it would work since it would know to try to resolve using azulvnet02.yourdomain.com.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP
Please sign in to rate this answer.

1 person found this answer helpful.
Apurva Pathak 570 Reputation points

2024-09-23T07:04:27.2933333+00:00

Hi @TP,

Thanks for your comment, but it works without FQDN for AZUL002 (VM which is deployed in the same Vnet).

Thanks

TP 95,556 Reputation points

2024-09-23T08:00:06.8133333+00:00

Thanks for your comment, but it works without FQDN for AZUL002 (VM which is deployed in the same Vnet).

Correct, that is expected because that VM has same search directive in its resolv.conf. Please take look at resolv.conf file on each VM to see what I mean. You can do this by entering below command on each:

cat /etc/resolv.conf

Apurva Pathak 570 Reputation points

2024-09-23T09:07:10.4566667+00:00

Hi @TP,

Thanks for your comments, that seems to be working now. However, I am now curious to know that if both are linked to same Zone, why is it VMs in Vnet1 are unable to resolve hosts deployed in Vnet2 (without their FQDN)?

Thanks again!

TP 95,556 Reputation points

2024-09-23T09:34:30.01+00:00

Thanks for your comments, that seems to be working now. However, I am now curious to know that if both are linked to same Zone, why is it VMs in Vnet1 are unable to resolve hosts deployed in Vnet2 (without their FQDN)?

By default, an operating system (in this case Linux) doesn't know what domain suffix to use when you use a short name. This is why you need to configure it in the resolv.conf file.When the request is sent to the DNS server to resolve the hostname to the IP address, the DNS server doesn't know anything about "azulvnet02", however, it does know (or can ask another DNS server) "azulvnet02.yourdomain.com". In other words, just giving the short name isn't enough information.

You may be wondering why it worked for the VMs in same VNet? The reason is, Azure automatically added line to resolv.conf with a default internal domain.

TP 95,556 Reputation points

2024-09-23T10:21:59.58+00:00

@Apurva Pathak Please click Accept Answer and upvote to close up this thread.

Thank you.

Apurva Pathak 570 Reputation points

2024-09-23T13:36:34.1433333+00:00

Hi @TP,

Thanks, but why Azure couldn't add the resolution information to the other VM, both were linked and registered to the same DNS Zone?

KapilAnanth-MSFT 45,451 Reputation points Microsoft Employee

2024-09-23T13:45:21.5633333+00:00

@Apurva Pathak ,

Both the VNETs are linked to a Private DNS Zone of name <.yourdomain.com>

Not, <.internal.cloudapp.net>

When you do a query for just "vm2"

The actual resolution takes place for vm2.abc.xyz.internal.cloudapp.net and not vm2.yourdomain.com

Since there is no Private DNS Zone for <.internal.cloudapp.net>, this fails and there is no response.

This is called "Azure-provided name resolution" and this is different from you manually creating a Private DNS Zone and enabling auto-registration.

See : Azure-provided name resolution's Considerations

Hope this clarifies.

Thanks,

Kapil

Please Accept an answer if correct.

Original posters help the community find answers faster by identifying the correct answer.

TP 95,556 Reputation points

2024-09-23T13:45:28.14+00:00

Thanks, but why Azure couldn't add the resolution information to the other VM, both were linked and registered to the same DNS Zone?

That's not something that Azure does currently. It certainly would be possible for them to add this as a feature, but there are different issues to work through.

If you want you could submit it as an idea for them to consider:

https://feedback.azure.com/d365community/forum/8ae9bf04-8326-ec11-b6e6-000d3a4f0789

Apurva Pathak 570 Reputation points

2024-09-24T07:52:34.0133333+00:00

Hi @KapilAnanth-MSFT ,

Thanks a ton!

As usually you're my Saviour for most of the Azure Networking related queries :)!

However, I still have below:

How to overcome this limitation?

"This is called "Azure-provided name resolution" and this is different from you manually creating a Private DNS Zone and enabling auto-registration."-- I didn't get this clearly. How Azure-provided name resolution take place for VMs unless I created a DNS zone and enable auto-registration?

If Azure-provided name resolution cannot resolve the names created in different Vnets, how does it work with FQDN? Is it because it

KapilAnanth-MSFT 45,451 Reputation points Microsoft Employee

2024-09-24T09:12:47.5833333+00:00

@Apurva Pathak ,

Glad we could be of service.

Wrt your queries,

1.How to overcome this limitation?

You are expected to query the resources with their FQDN. i.e., for VM2, it should be vm2.yourdomain.com

Note that this is by design and Azure VNET's "Azure-provided name resolution" was always intended to be used within the Virtual Network.

For larger networks and your own custom domain, such as <.yourdomain.com>, you must use the full name of for the DNS Query to succeed.

2.How Azure-provided name resolution take place for VMs unless I created a DNS zone and enable auto-registration?

This is managed at platform level, by default

Every VM you create gets an internal DNS Name with some random DNS Suffix.

For e.g., when you create a VM named VM1, an internal DNS name for the VM is created like : vm1.abc.xyz.internal.cloudapp.net

This is random and the ".abc.xyz" suffix is not fixed across Virtual Networks

This is why, you are not able to resolve VMs in peered Virtual Networks.

I.E., For VM2 (in a different VNET), it will be vm2.**def.ijk.**internal.cloudapp.net

3.If Azure-provided name resolution cannot resolve the names created in different Vnets, how does it work with FQDN?

I believe you meant to say "Private DNS Zones"

With Private DNS Zone, the suffix is constant.

i.e., <yourdomain.com> will be same for VM1 and VM2

See FAQs :

Will DNS resolution by using the default FQDN (internal.cloudapp.net) still work even when a private zone (for example, private.contoso.com) is linked to a virtual network? Answer here

Will the DNS suffix on virtual machines within a linked virtual network be changed to that of the private zone? Answer here

Thanks for your continued contribution on Q&A and appreciate much for taking the time to share your feedback.

Cheers,

Kapil

Apurva Pathak 570 Reputation points

2024-09-25T08:36:53.2333333+00:00

Thanks @KapilAnanth-MSFT ,

As per point 2: Does it mean that if I create two VMs in Azure in same Vnet, would they be able to resolve their hostnames to their IPs, even if I don't create a custom Private DNS Zone linked to the Vnet (and if I set Azure DNS in the Vnet level DNS config)?

If yes, then I might not need to create any private DNS Zone for intra-vnet DNS resolution for VMs, is my understanding correct?

And Azure Private DNS Zones, supports name resolution only with 'FQDN' and not hostnames?

Thankful for all your help on this till now!

KapilAnanth-MSFT 45,451 Reputation points Microsoft Employee

2024-09-25T08:46:21.5+00:00

@Apurva Pathak ,

1 . As per point 2: Does it mean that if I create two VMs in Azure in same Vnet, would they be able to resolve their hostnames to their IPs, even if I don't create a custom Private DNS Zone linked to the Vnet (and if I set Azure DNS in the Vnet level DNS config)?

Correct

2 . If yes, then I might not need to create any private DNS Zone for intra-vnet DNS resolution for VMs, is my understanding correct?

Correct

3 . And Azure Private DNS Zones, supports name resolution only with 'FQDN' and not hostnames?

Correct

If you have a record as "vm", and zone has "yourdomain.com" , you should query as whole - vm.yourdomain.com

Happy to assist :)

Cheers,

Kapil

Apurva Pathak 570 Reputation points

2024-09-25T11:13:25.66+00:00

Cheers KapilAnanth-MSFT!
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure Private DNS Zone unable to resolve hostname created in a different Vnet

0 additional answers

Your answer