Name resolution relates two important identities: hostnames and IP addresses. Humans are typically more comfortable with hostnames, which are easier to remember. However, TCP/IP requires source and destination IP addresses to communicate. Name resolution works between these two identities.
Name resolution via DNS is one of the most critical services on the network. Without it, network printers, servers, websites and other essential services could become inaccessible. This article shows several methods and commands for troubleshooting name resolution from the client's perspective.
Ping the destination
Admins can use several methods to determine whether the system they're troubleshooting has a name resolution problem. Suppose a user receives an error message stating a specific file server can't be found. An administrator could start to troubleshoot the problem using the following steps for a ping command:
- Open a terminal on the OS.
- Use the ping command to identify whether name resolution is failing or if some other connectivity problem exists. First, ping the resource by hostname, and then ping it by IP address.
If the ping by name succeeds, the local system has a network path to the remote system, and the problem probably isn't name resolution.
Read the first article in the series that defines name resolution components and processes. The following article covers name resolution troubleshooting at the DNS server.
If the ping by name fails, try a ping by IP address. If this fails, the local and remote systems don't have network connectivity between them. The issue could be a cable, switch, router or firewall problem.
If the ping by IP address succeeds but the ping by name fails, it's probably a name resolution problem. The ping works but not when the destination is identified by name.
Assuming these tests point admins toward a name resolution problem, the next step is to check connectivity to the DNS server.
Check DNS settings
To check connectivity to the DNS servers, begin with the standard IP configuration commands for each OS.
For Linux, use the resolvectl status command to display the configured name resolution servers.
For macOS, type scutil --dns to display the configured name resolution servers.
For Windows, type ipconfig /all to display the configured name resolution servers.
Another alternative for Windows is the Get-DnsClientServerAddress PowerShell cmdlet.
Whichever commands admins use to display the DNS configuration, the goal is to ensure they don't have any typographical errors. The clients must be able to find and connect to the DNS servers. It is a best practice to list at least two name resolution servers for the client to query.
Note that the client probably receives these settings from Dynamic Host Configuration Protocol (DHCP). Confirm the DHCP server's settings for name resolution are accurate.
Test the connection to DNS
Once admins identify which DNS servers the client uses, they can test connectivity using the ping command. Do this test with the DNS server's IP address as that is what the client computer uses.
For example, if the DNS server is found at 192.0.2.127, enter ping 192.0.2.127.
If this ping fails, confirm the following items:
- the DNS server is up, and the service is running;
- firewall settings on the DNS server permit inbound queries on port 53/udp;
- any routers between the client and DNS server are functional; and
- any packet filtering on routers between the client and DNS server permits traffic over port 53/udp.
Manually query DNS
The system's name resolution client automatically queries DNS without user intervention for tools such as web browsers, ping and scripts. However, it can be useful for troubleshooting to initiate name resolution queries manually. For example, admins might try to test connectivity to a particular DNS server, check that a specific server returns an expected result, or identify domain or other information about the DNS service. Multiple tools exist to query DNS manually.
Use nslookup
Nslookup is a powerful name resolution utility. It's available for Windows, Linux and macOS, which is helpful for admins who work on all three platforms, as it's convenient to learn only one tool when supporting multiple OSes.
Admins can type nslookup workstation1 to resolve the IP address for workstation1. The system's configured DNS server returns the results. Admins can send a reverse lookup query using the IP address instead of the hostname, like this: nslookup 192.0.2.2.
Nslookup also has a powerful interactive mode that enables admins to initiate zone transfers and display various resource record types. While this mode offers too many features to cover in this article, it's worthwhile for admins to learn the details of nslookup.
Use dig
Another option is the dig utility. It displays much the same information as nslookup but in a more organized format. Dig may not be installed on an OS, but admins can add it. Dig provides both forward and reverse lookups and can display specific resource records from the zone. Like nslookup, the syntax is dig workstation1.
Use host
The host command displays a simple result. This simplicity is useful for scripts that extract and then use information the host command gathers. As with dig and nslookup, admins can type the command and the hostname or IP address they wish to resolve, such as host workstation1.
Use PowerShell cmdlets
Windows PowerShell relies on the Resolve-DnsName cmdlet to initiate manual name resolution queries. Its flexibility enables admins to display exactly the information required. The cmdlet's syntax is similar to that of the other commands but not quite the same: Resolve-DnsName -Name workstation1.
To target a specific DNS server (at 192.0.2.24) to provide resolution, type Resolve-DnsName -Name workstation1 -Server 192.0.2.24.
As with dig and host, admins can add Resolve-DnsName to PowerShell scripts to manipulate information as needed.
Another useful cmdlet for confirming DNS functionality is Test-DnsServer. The output shows whether the destination is a DNS server. The syntax to check whether 192.0.2.24 is a DNS server is Test-DnsServer -IPAddress 192.0.2.24.
These utilities are helpful for troubleshooting and scripting. If admins work on at least two of the three major OSes regularly, it's worth their time to discover and use a universal command.
Wrap-up
This article focuses on testing from the client's perspective, and it includes the following common troubleshooting steps:
- Ping the destination by name and then by IP address to identify whether the problem is name resolution or basic connectivity.
- Display and confirm the client's DNS configuration, whether it's set statically or dynamically.
- Test connectivity to the DNS server, paying close attention to firewalls and routers along the network path.
- Manually query the DNS server with tools such as dig, host, nslookup and Resolve-DnsName.
Name resolution is an essential network service, so it's beneficial for admins to be confident and quick when troubleshooting. Mastering these techniques and commands will help admins with any future name resolution challenges.
