Pretty sure you must’ve noticed it
Most of us must’ve faced this problem, especially in our home networks. You must’ve noticed that when you’re trying reach one machine from another using it’s IP address, it works perfectly. However when you try to reach it using its hostname/DNS name like
wiseindy-pc, it is extremely unreliable and rarely works.
And if you’ve got the opportunity to work with corporate networks, you’ll notice that this is not the case there. Communicating with machines via hostnames is as reliable as communicating via their individual IP addresses in a corporate environment.
Is it because companies have “bigger” and “better” hardware? And your home router sucks? Well, not really.
The problem is pretty straightforward actually. The devices on your network don’t really know whom they should ask to resolve the hostname.
To translate a hostname to an IP address, the machine will need to know the “Fully Qualified Domain Name” or “FQDN” in short.
FQDN for a particular machine looks something like this:
hostname.domain.whatever. A home environment (in almost all cases) is not a domain environment, i.e., the computers are not connected to a central domain unlike most companies. This
domain.com part in the FQDN called the “DNS Zone”.
Let us assume that machine we are trying to connect is called
wiseindy-pc and its IP address is
So on your home network, you have the
hostname part, e.g.
wiseindy-pc. But the machine has no idea about the
domain.com part (since there IS no domain). Hence it has no way to convert
Ok, so that explains why it doesn’t work. But, in some rare cases (probably when the planets align) it actually does work, even on a network without a DNS zone. How is that possible?
Well, as it turns out, if a DNS zone is not defined for the network, your device tries ANOTHER way to figure out the IP address before abandoning the resolving process altogether. It tries to find out the hostname -> IP address mapping on its own using a technique called “DNS broadcast”. The problem with this is that not all machines/devices are configured to answer to this DNS broadcasr, or are actually configured to deliberately not answer such a request.
To fix this you need to configure a “DNS Suffix” for your network.
If you open up command prompt and type
ipconfig, you’ll notice that the Connection-specific DNS Suffix is blank.
It’s extremely simple to do this on a router which has the DD-WRT firmware installed. In case you don’t have a router with DD-WRT, here’s my guide to install DD-WRT on one.
Open up a browser and navigate to your router homepage. After logging in, click on the Services tab.
.local, while your windows machines will probably do just fine, your Linux machines will adhere to the mDNS (Multicast DNS) standard and will again ignore the DNS server.
Scroll down, click Save. Then hit Apply.
To get the new settings on your PC, you’ll need to refresh the IP configuration. Open up a Command Prompt window and type the following commands one after the other:
ipconfig. You should see that a DNS suffix is now defined.
Now, since you have a DNS suffix, the resulting FQDN for this machine will be
wiseindy-pc.wise.lan. The hostname can now be resolved to its IP address easily.
ipconfig /release and
ipconfig /renew on at least one more machine and try pinging
wiseindy-pc using only the hostname. You should see that the client has automatically understood that the full name of the device you’re pinging is
hostname.dns.zone), and was able to translate (resolve) the FQDN to an IP.
(header image source: goodfon.su)