Name resolution is the process of associating names and IP addresses, and it’s one of the most essential services on a network.
People understand descriptive names, but network communications require difficult-to-remember addresses. While it’s simple enough for network administrators to connect to webserver3, a computer needs the destination server’s IP address to establish communications.
This article explains network host identities and the DNS name resolution process. The next two articles in this series cover troubleshooting from the perspective of both clients and DNS servers.
Hosts on a TCP/IP network have multiple identities. Network devices use these identities to deliver data to the correct hosts.
The three identities are the following:
- Media access control (MAC) address. The network interface card (NIC) has a MAC address encoded on its firmware.
- IP address. The NIC also has a logical IP address assigned to it.
- Hostname. The system has a human-friendly hostname set during the OS installation.
These identities provide a means of finding a given node on a network or network segment.
Because the identities differ, a means must exist to relate them to each other. For example, Address Resolution Protocol relates unknown MAC addresses to known IP addresses. However, the name resolution process that relates hostnames and IP addresses is significantly more complex.
Name resolution enables a host to be recognized by either its hostname or IP address. Typically, people are most comfortable working with easily understood and descriptive names, such as webserver3. However, TCP/IP data packets require source and destination address fields — values that are necessary for routers to direct network traffic correctly. These addresses, such as an IPv4 address of 192.0.2.127, are much harder for people to work with. Imagine if web browser bookmarks displayed only IP addresses instead of descriptive names.
Most of the time, the name resolution process consists of relating an unknown IP address with a known hostname, such as when an administrator types ping webserver3. The ping must be sent to an IP address, but the administrator more easily remembers the descriptive webserver3 name.
The name resolution process
When all is working correctly, a system resolves the hostname behind the scenes. It checks two resources to discover the necessary IP address: a local file and a DNS database server.
The first method relies on a text file named hosts that resides on the local machine’s storage disk. The hosts file is OK for an occasional entry, but it is difficult to keep current as network devices come and go on the network and receive new IP address configurations from the Dynamic Host Configuration Protocol servers. Any host the system needs to connect to must be stored in the file along with its IP address.
Modern networks may have hundreds or even thousands of nodes, making the file difficult to maintain. Any time a node’s hostname or IP address changes, the file must be updated on every host in the network. This method is too cumbersome for a modern network.
The second, more dynamic method is to store all names and IP addresses on one or more network servers and configure the hosts to query the server to retrieve the information needed. The modern implementation of this is DNS.
DNS servers maintain a database of names and IP addresses. Client systems, such as Windows, Linux and macOS, dynamically update the DNS server’s database any time their hostname or IP address changes. This ensures the database is current. Hostname and IP address relationships are stored in entries called resource records.
Many types of resource records exist, but this article covers address (A) and DNS pointer (PTR) records:
- A records. A records provide hostname-to-IP address resolution. This type of query is known as a forward lookup.
- PTR records. PTR records provide IP address-to-hostname resolution. This type of query is known as a reverse lookup.
When a user enters a hostname as part of a command, such as ping webserver3, the system queries the DNS server, asking for the IP address of webserver3. The address is stored in an A record, enabling the DNS server to reply with webserver3’s IP address.
Local DNS query
Modern OSes include a DNS client that checks the hosts file and queries the DNS database. DNS communicates on the network using port 53. Some DNS transmissions are TCP-based, and others rely on User Datagram Protocol (UDP). UDP transmissions are used for client queries, and TCP is for zone transfers between DNS servers. Zone transfers are how DNS servers update each other.
Note that host and network firewalls must enable communication on port 53/udp for name resolution queries to succeed.
Internal clients querying for internal resources use internal DNS servers. Suppose an end-user workstation needs to be configured to connect to a network print device named salesprinter3. The technician configuring the workstation easily identifies salesprinter3 by name and uses the Windows Map Network Printer feature to establish the connection. The client computer automatically queries DNS, asking for the IP address associated with the name salesprinter3. The DNS server checks its resource records and responds with the address. The client system can now properly address TCP/IP packets to the network print device. In this example, all name resolution happens using internal resources.
The process is the same for any TCP/IP client, including Windows, Linux and macOS systems.
Internet DNS query
The theory is the same for internet-based resources, but the process is more complex. Internet names are organized hierarchically into domains, beginning with the root — depicted by a single dot — followed by the top-level domains, such as com, edu, org, etc. Name resolution queries pass from one layer to the next until the name is resolved or determined to be unresolvable.
Internet names are actually paths from one domain to the next. For example, the name webserver3.example.com is read backward as “go to com, find example and then find webserver3.” This naming convention is known as a fully qualified domain name.
Name resolution is a critical network service. System and network administrators must be able to configure and troubleshoot name resolution. Begin by understanding the purpose of name resolution and the difference between resolving from the hosts file and DNS.
They must also understand DNS queries. The next article in this series covers methods of troubleshooting name resolution. It includes Windows, Linux and macOS commands for testing and solving name resolution issues. The third article explains how to check the DNS server service to ensure it is enabled, is functioning and doesn’t include typographical errors.