DNS is one of the first things I check when troubleshooting a network problem. A user may report that a website is slow, an application cannot connect, or a server appears to be offline, but the underlying problem can sometimes be a DNS query that is taking too long or failing altogether. Wireshark makes it possible to see exactly what is happening between the DNS client and server, and display filters can quickly turn a large packet capture into something much easier to analyze. Instead of scrolling through thousands of packets, these five Wireshark DNS filters can help isolate the transactions that are most likely to explain a problem.
DNS is the protocol that converts the easy-to-remember words we want to use, into the numbers that routers and hosts need. It's the connection between the names and the actual addresses where the services reside.
1. Find slow DNS responses: dns.flags.rcode == 0 && dns.time > 0.1 is a useful starting point when investigating DNS performance. It displays successful DNS responses that took more than 100 milliseconds to complete. The 100 ms value isn't a universal definition of a slow DNS server, but it is a practical threshold for troubleshooting because DNS is normally expected to respond very quickly when information is available from cache. Wireshark exposes both the DNS response code and response timing as filterable fields, making it easy to identify unusually slow transactions. If you capture close to the DNS server, you can also reduce the amount of network round-trip latency included in your measurement.
2. Follow a DNS transaction ID: dns.id == <transaction ID> is extremely useful when a DNS exchange becomes complicated. DNS uses a transaction ID to associate a query with its response, so filtering on that value lets you concentrate on one transaction instead of an entire capture. This can be particularly helpful when troubleshooting retries, multiple DNS servers, or intermittent failures. If a client doesn't receive a response, you may see the same transaction being attempted again or sent toward another resolver. Looking at the packets associated with the transaction can reveal whether the problem is the client, the network path, or the DNS server. Wireshark identifies the DNS transaction ID as the dns.id field.
3. Follow the DNS conversation: Once you find an interesting packet, following its transport conversation can provide additional context. For UDP traffic, udp.stream == <stream number> isolates the UDP conversation, while TCP-based DNS traffic can be examined with tcp.stream == <stream number>. This is especially useful when a packet capture contains DNS traffic from many clients and servers. Rather than filtering only on port 53, the stream filter lets you focus on the particular conversation associated with the problem. It is also a good reminder that DNS isn't limited to one transport mechanism; troubleshooting should consider both UDP and TCP traffic when the capture indicates that TCP is being used.
4. Investigate DNS zone transfers: DNS administrators can also use Wireshark to investigate zone-transfer activity. The filter dns.qry.type == 251 || dns.qry.type == 252 || dns.flags.opcode == 4 looks for incremental zone transfers, full zone-transfer requests, and DNS NOTIFY messages. These transactions are normally associated with communication between authoritative DNS servers rather than ordinary client lookups. If a secondary DNS server isn't receiving updated records, examining these packets can help determine whether the notification, transfer request, or subsequent response is failing. Wireshark exposes the DNS query type and opcode as dedicated filter fields, making this type of analysis much easier.
5. Find DNS errors and failed lookups: Finally, dns.flags.rcode != 0 is a simple way to locate DNS responses containing a non-zero response code. These can include conditions such as name errors or server failures and are often worth investigating when users report intermittent connectivity problems. You can make the filter more targeted by looking at the response code and query type together. For example, an IPv6-related investigation can use dns.qry.type == 28 to identify AAAA queries. Wireshark currently exposes fields such as dns.flags.rcode, dns.flags.response, dns.qry.name, dns.qry.type, and dns.aaaa, giving network engineers plenty of options for building more specific DNS troubleshooting filters.
These five filters aren't meant to replace a complete DNS troubleshooting methodology, but they provide a practical starting point when working with a packet capture. I normally begin by determining whether the DNS response is slow, then follow an individual transaction and examine the client/server conversation. From there, DNS response codes and query types can help identify whether the issue is related to resolution, server availability, configuration, or the network path. The big advantage of using Wireshark is that you aren't guessing what DNS is doing—you can see the actual queries and responses in the packet capture and build your troubleshooting process around evidence.
Do you have a Packet mystery that you'd like Betty to solve? How about a team who needs training on how to catch the culprit themselves? Contact her at bettydubois.com information. Your mystery will be solved in no time.
