A Windows Server 2012R2 Essentials machine was returning strange results when I did a DNS query from PowerShell. I traced it back to modifications that 3CX version 14 had made to the Windows hosts file.
Background
One standard setup for Essentials is to have a “remote.mydomain.com” address registered with a public DNS server. That address is used for remote access to the Essentials machine and as an RDP gateway.
The Issue
In a PowerShell script, I needed to to check the current public IP of the Essentials server. Normally this line returns the first public IP address:
[System.Net.Dns]::GetHostAddresses(“remote.mydomain.com”)[0].IPAddressToString
But this kept returning the localhost address 127.0.0.1.
nslookup remote.mydomain.com worked fine, so DNS was not the problem. So why is the .Net DNS class returning 127.0.0.1?
Investigation
I discovered a new cmdlet in PowerShell v4 (Server 2012) called Resolve-DnsName.
Resolve-DnsName –name remote.mydomain.com
also returned 127.0.0.1. Even when I explicitly specified Google’s DNS server:
Resolve-DnsName –name remote.mydomain.com –server 8.8.8.8
I kept getting 127.0.0.1. How is that possible? Google’s DNS can’t be returning 127.0.0.1. Wait, here’s an interesting parameter: “-DnsOnly resolves a name using only DNS. LLMNR and NetBIOS queries are not issued.”
Resolve-DnsName –name remote.mydomain.com –DnsOnly
Success! This returns the public IP address. But I still don’t know where the 127.0.0.1 is coming form. Okay, here’s another parameter: “-NoHostsFile skips the hosts file when resolving this query.”
Resolve-DnsName –name remote.mydomain.com –NoHostsFile
Sure enough, this also returns the public IP. So 127.0.0.1 must be coming from the hosts file.
Cause
When I opened C:\Windows\System32\drivers\etc\hosts, I found two entries apparently put there by the 3CX installer:
127.0.0.1 remote.mydomain.com
127.0.0.1 3cx.mydomain.local
Interestingly, I had already uninstalled 3CX, but that did not remove these entries.
Solution
I backed up the hosts file and replaced it with one that did not have the extra pointers to 127.0.0.1 The .Net DNS command was once again able to retrieve the public IP of the server.
I assume that 3CX puts these entries in the hosts file so that you can access its web interface with the public FQDN even when logged on to the machine where 3CX is installed. Fair enough. I would prefer to set that in DNS rather than in the hard-to-find hosts file, as 3CX documents here, but that is more complex because it would require manual intervention. Nonetheless, the user should be notified of the change to the hosts file, since it can unexpectedly impact other activities on the same machine, and the entries should be removed when 3CX is uninstalled.