Service Fabric VM using on-premises DNS servers not resolving

Question

I have a Service Fabric instance running in Azure with multiple VMs ( SFVM1 , SFVM2 , etc). Service Fabric is connected to a VNet which has a Virtual Network Gateway that connects to an on-premises network. There are also on-premises DNS servers (listed in the VNet) that handle translating names to on-premises servers.

As a proof of concept, I have a standalone Azure VM ( POCVM ) on the same VNet, and can successfully ping the "on-prem server in question" ( OnPremServer ) by name and it resolves its IP address and I get replies.

However, I'm finding that after Service Fabric is all done initializing, and I remote into SFVM1 , and I try to ping OnPremServer by name, the name does not resolve. The weird thing is I can ping OnPremServer 's IP address and get replies. To me, this seemed like DNS settings are out of whack on the vm, and after doing an ipconfig \\all I find that the custom DNS entries that are listed in the VNet aren't listed as DNS servers here.

From SFVM1 , I can also successfully ping the IP Address of the on-prem DNS servers. I've tried disabling/reenabling the Service Fabric DNS Service to no avail and haven't had much luck scouring the web for clues. Short of making a script that sets the DNS servers on VM startup described in this SO post , I don't know what else to do.

Shouldn't the Service Fabric VM's pick up the custom DNS entries from the VNet? If so, any idea what's wrong? If not, what is the correct way to do this?

Many thanks in advance!

Answer 1

After spinning my wheels on this more, I stumbled upon a solution. Apparently, changes made to the VNet DNS settings don't necessarily get propagated to Service Fabric VMs, even if they're restarted. After I accidentally completely bombed the network configuration of one of the Service Fabric VMs, I de-allocated and re-allocated the virtual machine scale set...and then the DNS settings were properly applied to the VMs like magic. Glad that predicament is over