Name resolution relates to two important identities: hostnames and IP addresses. People are usually more comfortable with hostnames that are easier to remember. However, TCP/IP requires source and destination IP addresses for communication. Name resolution works between these two identities.
Name resolution via DNS is one of the most critical services in the network. Without them, network printers, servers, websites, and other important services could become inaccessible. This article shows several methods and commands for troubleshooting name resolution from the client’s perspective.
Ping the target
Administrators can use several methods to determine if the system they are troubleshooting has a name resolution issue. Suppose a user receives an error message stating that a specific file server cannot be found. An administrator could begin to troubleshoot the issue by following the steps below for a Ring Command:
- Open a terminal on the operating system.
- Use the Ring Command to determine if name resolution is failing or if there is some other connection problem. Ping the resource by hostname first, then by IP address.
If the ping by name succeeds, the local system has a network path to the remote system and the problem is probably not name resolution.
If ping by name fails, try ping by IP address. If this fails, there is no network connection between the local and remote systems. The problem can be a cable, switch, router, or firewall issue.
If ping by IP address succeeds but ping by name fails, there is likely a problem with name resolution. However, the ping does not work if the target is identified by name.
Assuming these tests alert administrators to a name resolution issue, the next step is to verify connectivity to the DNS server.
Check DNS settings
To verify connectivity to the DNS servers, start with the standard IP configuration commands for each operating system.
For Linux, use the resolve status Command to display the configured name resolution servers.
Enter for macOS scutil –dns to view the configured name resolution servers.
Enter for Windows ipconfig /all to view the configured name resolution servers.
Another alternative for Windows is the Get-DnsClientServerAddress PowerShell cmdlet.
Regardless of what commands administrators use to view DNS configuration, the goal is to ensure they are free of typographical errors. The clients must be able to find and connect to the DNS servers. It’s a good idea to list at least two name resolution servers that the client can query.
Note that the client will likely get these settings from Dynamic Host Configuration Protocol (DHCP). Confirm that the DHCP server settings for name resolution are correct.
Test the connection to DNS
Once administrators have identified which DNS servers the client is using, they can test connectivity to the Ring Command. Perform this test using the DNS server’s IP address, as this is what the client computer will use.
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:
- the DNS server is active and the service is running;
- Firewall settings on the DNS server allow incoming requests on port 53/udp;
- all routers between the client and the DNS server are working; and
- Any packet filtering on routers between the client and the DNS server allows traffic over port 53/udp.
Query DNS manually
The system’s name resolution client automatically queries DNS without user intervention for tools such as web browsers, ping, and scripts. However, manually initiating name resolution queries can be helpful for troubleshooting. For example, administrators might try to test connectivity to a specific DNS server, verify that a specific server is returning an expected result, or discover domain or other information about the DNS service. There are several tools to query DNS manually.
Nslookup is a powerful name resolution utility. It’s available for Windows, Linux, and macOS, which is useful for admins working on all three platforms, as it’s convenient to learn just one tool when multiple operating systems are supported.
Admins can type nslookup-workstation1 to resolve the IP address for Workstation1. The system’s configured DNS server returns the results. Administrators can send a reverse lookup query using the IP address instead of the hostname, like so: nslookup 192.0.2.2.
Nslookup also has a powerful interactive mode that allows administrators to initiate zone transfers and view different types of resource records. Although this mode has too many features to cover in this article, it is worthwhile for administrators to familiarize themselves with the details of nslookup.
Another option is the dig utility. It displays essentially the same information as nslookup, but in a more organized format. Dig may not be installed on an operating system, but administrators can add it. Dig offers both forward and backward searches and can display specific resource records from the zone. The syntax is like nslookup Excavation Workplace1.
That host Command displays a simple result. This simplicity is useful for scripts that extract and then use information host command gathered. As with dig and nslookup, administrators can enter the command and the hostname or IP address they want to resolve, e.g Host Workstation1.
Use PowerShell cmdlets
Windows PowerShell is based on the Resolve DnsName Cmdlet to initiate manual name resolution queries. Its flexibility allows administrators to view exactly the information they need. The cmdlet’s syntax is similar to the other commands, but not entirely the same: Resolve-DnsName – Workstation1 name.
Enter the following to use a specific DNS server (at 192.0.2.24) as the target for providing resolution Resolve-DnsName -Name Workstation1 -Server 192.0.2.24.
As with dig and host, administrators 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 if 192.0.2.24 is a DNS server Test DNS server IP address 192.0.2.24.
These utilities are useful for troubleshooting and scripting. If administrators regularly work on at least two of the big three operating systems, it pays to discover and use a universal command.
This article focuses on testing from the customer’s perspective and provides the following general troubleshooting steps:
- Ping the target by name and then by IP address to determine if the problem is name resolution or basic connectivity.
- View and confirm the client’s DNS configuration, whether statically or dynamically set.
- Test the connection to the DNS server, paying close attention to firewalls and routers along the network path.
- Query the DNS server manually using tools like dig, hostnslookup and Resolve DnsName.
Name resolution is an essential network service, so it’s beneficial for administrators to be safe and fast when troubleshooting. Mastering these techniques and commands will help administrators with future name resolution challenges.