7.7. 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 resolve from Wireshark specific configuration
files. For details about the configuration files Wireshark uses for name
resolution and alike, see Appendix B, Files and Folders.

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

7.7.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 will 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.

The resolved names are not stored in the capture file or somewhere else. So
the resolved names might not be available if you open the capture file later
or on a different machine. Each time you open a capture file it may look
“slightly different” simply because you can’t connect to the name server
(which you could connect to before).

DNS may add additional packets to your capture file. You may see packets
to/from your machine in your capture file, which are caused by name resolution
network services of the machine Wireshark captures from.

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 → Reload to rebuild the packet list with the correctly resolved names.
However, this isn’t possible while a capture is in progress.

7.7.2. Ethernet name resolution (MAC layer)

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.7.3. IP name resolution (network layer)

Try to resolve an IP address (e.g. 216.239.37.99) to something more “human
readable”.

DNS/concurrent DNS name resolution (system/library service): Wireshark will
ask the operating system (or the concurrent DNS library), to convert an IP
address to the hostname associated with it (e.g. 216.239.37.99 →
www.1.google.com). The DNS service is using synchronous calls to the DNS server.
So Wireshark will stop responding until a response to a DNS request is returned.
If possible, you might consider using the concurrent DNS library (which won’t
wait for a name server response).

Warning

Enabling network name resolution when your name server is unavailable may
significantly slow down Wireshark while it waits for all of the name server
requests to time out. Always use concurrent DNS resolution.

DNS vs. concurrent DNS: here’s a short comparison: Both mechanisms are used
to convert an IP address to some human readable (domain) name. The usual DNS
call gethostname() will try to convert the address to a name. To do this, it
will first ask the systems hosts file (e.g. /etc/hosts) if it finds a
matching entry. If that fails, it will ask the configured DNS server(s) about
the name.

So the real difference between DNS and concurrent DNS comes when the system has
to wait for the DNS server about a name resolution. The system call
gethostname() will wait until a name is resolved or an error occurs. If the DNS
server is unavailable, this might take quite a while (several seconds).

The concurrent DNS service works a bit differently. It will also ask the DNS
server, but it won’t wait for the answer. It will just return to Wireshark in a
very short amount of time. The actual (and the following) address fields won’t
show the resolved name until the DNS server returns an answer. As mentioned
above, the values get cached, so you can use View → Reload to “update” these
fields to show the resolved values.

hosts name resolution (hosts file): If DNS name resolution failed, Wireshark
will try to convert an IP address to the hostname associated with it, using a
hosts file provided by the user (e.g. 216.239.37.99 → www.google.com).

7.7.4. TCP/UDP port name resolution (transport layer)

Try to resolve a TCP/UDP port (e.g. 80) to something more “human readable”.

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).