In my early days of being IT, I used to connect to everything via IP address. This was fine in a small network. But it gets harder when you have to look after a large amount of servers. It hard remembering all those IP address. We can use host names which would be resolved by DNS to solve this problem.
Using DNS also helps with server migrations, because if the clients are using DNS resolution of host names to connect to a service like a SMTP or a webserver, then you only need to update the DNS name in one place and once the TTL (Time To Live – the cache expiry time for that DNS record) is reached, the client will request the IP address for that DNS name again. If you had hardcoded the IP address on the client, you would have to manually update the settings on each device when the service is migrated.
A hostname can be a short name, such as server-a or the server could use a FQDN (Fully Qualified Domain Name) like server-a.example.net. The name resolution process that resolves the IP address is different for Windows and Linux, and can also be different if you are trying to access a SMB/CIFS service share as opposed to a URL.
If you are using an internal DNS server, for example, in a Windows Active Directory environment, choose wisely what domain name you want to pick as this could trip you up in the future, especially if you are planning to use a Linux desktop OS or trying to get a TLS (SSL) Certificate from a Trusted TLS provider.
When Windows 2000 Server introduced Active Directory, using DNS you had to choose a root DNS namespace. Microsoft recommended using .local. i.e.: company.local. This is now considered to be a bad idea because in 2003, The IETF (Internet Engineering Task Force) standards created RFC 6762 which reserves the use of the domain name label .local as a pseudo-top-level domain for hostnames in local area networks that can be resolved via the mDNS (Multicast Domain Name Service) name resolution protocol. I’ll cover this more when we discuss Linux name resolution on an Ubuntu desktop OS. Also, since 1st November 2015, publicly trusted CA (TLS Certificate Authorities) are not allowed to produce certificates using the .local TLD (Top Level Domain).
Windows DNS Resolution
Windows has two routes to follow for Name Resolution – FQDN and short name resolution. With short name resolution, since Microsoft Windows 2000, if a computer is looking to talk to server-a, and it has a DNS Server configured in the network card configuration settings, it will try to resolve the name to an IP address following this method:
- Checks the local host file in
C:\Windows\System32\Drivers\etc\hoststo see if there is an entry existing for this hostname. - Query the DNS server. If you have DNS suffixes configured in the network card configuration, it will try and resolve them in order, for example, if you have
company1.example.net,company2.example.netconfigured in the DNS suffixes. It will ask for the IP address forserver-a.company1.example.netand if this is not found it will ask forserver-a.company2.example.netand so on. - Check the local NetBIOS name cache to see if it has been resolved before.
- If a WINS (Windows Internet Naming Service) server is configured in the network settings, it will ask that service to resolve the IP address.
- If a WINS server is not configured on the network for NetBIOS name resolution, NetBIOS names are resolved into IP addresses through a
NAME QUERY REQUESTbroadcast. The computer that has the NetBIOS name included in theNAME QUERY REQUESTmessage has to reply to the sender and return its IP address. - The last thing to be checked is the
LMHOSTSfile: LMHOSTS files is a text file, similar to theHOSTSfile used for name resolution for TCP/IP based networks. ThisLMHOSTSfiles contain host name to IP address mapping and is located inC:\Windows\System32\Drivers\etc\lmhosts.sam.
With a FQDN, if you are trying to resolve server-a.example.net, then the OS will only try the first 2 steps.
Linux DNS Resolution
In Linux, the default order on an Ubuntu 18.04 OS Desktop is:
1. Files
2. mdns4_minimal
3. dns
The order can be changed by editing the /etc/nsswitch.conf file.
Here the order in more details
Files
The file /etc/hosts is checked to see if there is an entry in the host file.
mdns4_minimal
If an mDNS or Multicast DNS service is provided Avahi/Bonjour daemon, that lets small network computers resolve names even when no central DNS is present. It uses, by default, the .local domain for resolving hosts on that network. mDNS does not cross subnet boundaries, and performs a local broadcast (e.g. 192.0.2.255 when your network is 192.0.2.0/24) to resolve the DNS name.
DNS
DNS servers, defined in /etc/resolv.conf are used for DNS Lookups.
Even with a fresh install of Ubuntu 18.04, even if you define DNS servers in the network manager, 127.0.0.53 is configured in the /etc/resolv.conf. This is because 18.04 uses systemd-resolved as a local DNS resolver. This service provides network name resolution to local applications, and implements a caching and validating DNS/DNSSEC stub resolver (basically, it can perform DNS lookups for your applications), as well as providing an LLMNR (Link-Local Multicast Name Resolution) and mDNS resolver and responder. It listens on a local IP (127.0.0.53) on UDP port 53. If the DNS request can’t be answered from its own cache or via mDNS, it will forward the DNS query to the server specified in network manager, and then cache the response for later.
.local and Ubuntu
I have always used .local just out of habit and have an Active Directory Domain Controller at home providing DNS and DHCP, in my case home.local. This was all OK until I started using a Linux desktop OS at home. Accessing SMB/CIFS/Samba shares this seemed to work fine because it uses a NetBIOS broadcast to find it.
The problem I was having was if I used a hostname or FQDN to access a webserver via a browser the system would not resolve the IP address. The DNS server setting were provided by DHCP and pointed to my local DNS server. If I used nslookup it was using 127.0.0.1 as is the DNS server to query, so it was using itself to resolve the IP address, but nslookup was not resolving the address via the DNS server defined in the network manager because, as I was using a .local TLD it was being treated as mDNS and not passing it to my normal DNS server.
So I somehow I needed to get the OS to talk directly to my local DNS and not systemd-resolve. If you look at /etc/resolv.conf it is a symbolic link to /run/systemd/resolve/stub-resolv.conf. This has the DNS server defined as 127.0.0.53 as the DNS server.
To get this to work for me I removed the symbolic link for /etc/resolv.conf and create a new symbolic link to /run/systemd/resolve/resolv.conf. This file contains the correct IP address of the DNS servers provide by the DHCP.
Here’s how I did it:
# Delete the existing symbolic link to /etc/resolv.conf file
sudo rm -f /etc/resolv.conf
# Create a new symbolic link
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
# Verify that the command has worked and the symbolic link is created
ls -l /etc/resolv.conf
If I now use nslookup, it reports that it’s using my local DNS server and returns the correct IP address for my .local addresses, however, if I try to ping from the command line it still does not resolve hosts with the .local domain suffix. This is because the order in which DNS is searched in /etc/nsswitch.conf is still set to file,mdns4_minimal,dns. We already know that there is no entry in /etc/hosts so next it tries to use mdns4_minimal, but because I am using a .local domain name the mdns4_minimal tries to discover the hostname with mDNS, and a failure here stops the lookup. Instead, though, I can edit /etc/nsswitch.conf and remove mdns4_minimal (so now it says file,dns). I can now ping the address from the command line because the order is now the local host file and then DNS. This does, however, mean that I can’t use mDNS anymore.
Conclusion
When rebuild my home network, I want to choose a new domain name. Some people are suggesting that I should use something like home.lan, but doing further research I would probably use a domain name that I own and then add a subdomain for my internal network, something like ad.mydomain.example.net.
Some reading on choosing a good active directory name: