7.9. Name Resolution
Prev | Chapter 7. Advanced Topics | Next

## 7.9. Name Resolution

Name resolution tries to convert some of the numerical address values into a human readable format. There are two possible ways to do these conversions, depending on the resolution to be done: calling system/network services (like the gethostname() function) and/or resolving from Wireshark specific configuration files. For details about the configuration files Wireshark uses for name resolution and alike, see Section A.2.4, “[Stream setup by PROTOCOL (frame 123)]”.

The name resolution feature can be enabled individually for the protocol layers listed in the following sections.

### 7.9.1. Name Resolution Drawbacks

Name resolution can be invaluable while working with Wireshark and may even save you hours of work. Unfortunately, it also has its drawbacks.

- Name resolution can often fail. The name to be resolved might simply be unknown by the name servers asked, or the servers are just not available and the name is also not found in Wireshark’s configuration files.
- Resolved names might not be available. Wireshark obtains name resolution information from a variety of sources, including DNS servers, the capture file itself (e.g., for a pcapng file), and the hosts files on your system and in your profile directory. The resolved names might not be available if you open the capture file later or on a different machine. As a result, each time you or someone else opens a particular capture file it may look slightly different due to changing environments.

- DNS may add additional packets to your capture file. You might run into the observer effect if the extra traffic from Wireshark’s DNS queries and responses affects the problem you’re trying to troubleshoot or any subsequent analysis.

  The same sort of thing can happen when capturing over a remote connection, e.g., SSH or RDP.

- Resolved DNS names are cached by Wireshark. This is required for acceptable performance. However, if the name resolution information should change while Wireshark is running, Wireshark won’t notice a change in the name resolution information once it gets cached. If this information changes while Wireshark is running, e.g., a new DHCP lease takes effect, Wireshark won’t notice it.

Name resolution in the packet list is done while the list is filled. If a name can be resolved after a packet is added to the list, its former entry won’t be changed. As the name resolution results are cached, you can use View → Redissect Packets to rebuild the packet list with the correctly resolved names.

### 7.9.2. Ethernet Name Resolution (MAC Layer)

Try to resolve an Ethernet MAC address (e.g., 00:09:5b:01:02:03) to a human readable name.

ARP name resolution (system service): Wireshark will ask the operating system to convert an Ethernet address to the corresponding IP address (e.g. 00:09:5b:01:02:03 → 192.168.0.1).

Ethernet codes (ethers file): If the ARP name resolution failed, Wireshark tries to convert the Ethernet address to a known device name, which has been assigned by the user using an ethers file (e.g., 00:09:5b:01:02:03 → homerouter).

Ethernet manufacturer codes (manuf file): If neither ARP or ethers returns a result, Wireshark tries to convert the first 3 bytes of an ethernet address to an abbreviated manufacturer name, which has been assigned by the IEEE (e.g. 00:09:5b:01:02:03 → Netgear_01:02:03).

### 7.9.3. IP Name Resolution (Network Layer)

Try to resolve an IP address (e.g., 216.239.37.99) to a human readable name.

DNS name resolution (system/library service): Wireshark will use a name resolver to convert an IP address to the hostname associated with it (e.g., 216.239.37.99 → www.1.google.com).

Most applications use synchronously DNS name resolution. For example, your web browser must resolve the host name portion of a URL before it can connect to the server. Capture file analysis is different. A given file might have hundreds, thousands, or millions of IP addresses so for usability and performance reasons Wireshark uses asynchronous resolution. Both mechanisms convert IP addresses to human readable (domain) names and typically use different sources such as the system hosts file (/etc/hosts) and any configured DNS servers.

Since Wireshark doesn’t wait for DNS responses, the host name for a given address might be missing from a given packet when you view it the first time but be present when you view it subsequent times.

You can adjust name resolution behavior in the Name Resolution section in the Preferences Dialog. You can control resolution itself by adding a hosts file to your personal configuration directory. You can also edit your system hosts file, but that isn’t generally recommended.

Another option is to group addresses by their subnet. For instance a common private network is 192.168.0.0/16. Adding this to the subnets file allows Wireshark to show an unknown host in this address range to be part of this network, e.g. "private:18.145". A similar file exists for IPv6 subnets. See Section B.3, “Configuration Files” for more details.

### 7.9.4. TCP/UDP Port Name Resolution (Transport Layer)

Try to resolve a TCP/UDP port (e.g., 80) to a human readable name.

TCP/UDP port conversion (system service): Wireshark will ask the operating system to convert a TCP or UDP port to its well-known name (e.g., 80 → http).

### 7.9.5. VLAN ID Resolution

To get a descriptive name for a VLAN tag ID a vlans file can be used.

### 7.9.6. SS7 Point Code Resolution

To get a node name for a SS7 point code a ss7pcs file can be used.

Prev | Up | Next
7.8. Packet Reassembly | Home | 7.10. Checksums