Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Post History
You certainly can use Wireshark to look for DNS traffic. First off, because of caching, I strongly recommend that you reboot the computer, and as quickly as possible start Wireshark, start monitor...
Answer
#2: Post edited
by
Canina
·
2021-10-08T07:29:09Z (about 3 years ago)
- You certainly can use Wireshark to look for DNS traffic.
- First off, because of caching, I strongly recommend that you reboot the computer, and as quickly as possible start Wireshark, start monitoring network traffic, set up a Wireguard filter, and then start the application in question, while doing as little else as possible. Also keep in mind that Wireshark will be looking at *all* network traffic, including loopback traffic, so you will likely get quite a lot of data quite quickly. (Hence my suggestion to do as little as possible other than the one task you want to monitor the network traffic for.)
You should be able to use Wireshark's [filter toolbar](https://www.wireshark.org/docs/wsug_html_chunked/ChUseFilterToolbarSection.html) to set up a filter. [Filter rules](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) support typical boolean operators combined with network-centric expressions, and DNS uses either TCP or UDP (you may find places that claim that DNS is UDP, but while DNS *typically* uses UDP, it *can* use TCP, and does so for large queries) but always port 53 on the server side. The general syntax for filtering on a protocol and port combination is `[tcp|udp] [src|dst] port <port>`, so simply specifying `port 53` as the filter should get you all DNS traffic (queries and responses).- Although I don't immediately see this mentioned in the Wireshark manual, apparently it also natively supports a [`dns` filter](https://resources.infosecinstitute.com/topic/infosec-skills-network-traffic-analysis-for-ir-dns-protocol-with-wireshark/) that does pretty much that. In that case, simply specifying `dns` as the filter should be sufficient.
- Be sure to click the apply 🠲 button to actually apply the filter.
- Either way, it looks like Wireshark has built-in support for decoding DNS queries and responses and displaying those in a somewhat user-friendly fashion, including showing the queried-for host name in the "Info" column. You will want to look for `A` (IPv4 address), `AAAA` (IPv6 address) or `ANY` (less likely, but possible) queries.
- You can also set up a filter like `(tcp port 80) or (tcp port 443)` to look for HTTP and HTTPS traffic on the respective standard ports, and look at the hostnames or at least IP addresses referenced there. ([QUIC](https://en.wikipedia.org/wiki/QUIC) uses UDP, but I wouldn't expect a years-old application to use that for its update checking mechanism.)
- You certainly can use Wireshark to look for DNS traffic.
- First off, because of caching, I strongly recommend that you reboot the computer, and as quickly as possible start Wireshark, start monitoring network traffic, set up a Wireguard filter, and then start the application in question, while doing as little else as possible. Also keep in mind that Wireshark will be looking at *all* network traffic, including loopback traffic, so you will likely get quite a lot of data quite quickly. (Hence my suggestion to do as little as possible other than the one task you want to monitor the network traffic for.)
- You should be able to use Wireshark's [filter toolbar](https://www.wireshark.org/docs/wsug_html_chunked/ChUseFilterToolbarSection.html) to set up a filter. [Filter rules](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) support typical boolean operators combined with network-centric expressions, and DNS uses either TCP or UDP (you may find places that claim that DNS is UDP, but while DNS *typically* uses UDP, it *can* use TCP, and does so for large queries) but always port 53 on the server side. (DNS over TLS/DTLS normally uses port 853, and DNS over HTTPS normally uses port 443, but for a first approximation it's probably safe to assume old-style, plaintext DNS.) The general syntax for filtering on a protocol and port combination is `[tcp|udp] [src|dst] port <port>`, so simply specifying `port 53` as the filter should get you all DNS traffic (queries and responses).
- Although I don't immediately see this mentioned in the Wireshark manual, apparently it also natively supports a [`dns` filter](https://resources.infosecinstitute.com/topic/infosec-skills-network-traffic-analysis-for-ir-dns-protocol-with-wireshark/) that does pretty much that. In that case, simply specifying `dns` as the filter should be sufficient.
- Be sure to click the apply 🠲 button to actually apply the filter.
- Either way, it looks like Wireshark has built-in support for decoding DNS queries and responses and displaying those in a somewhat user-friendly fashion, including showing the queried-for host name in the "Info" column. You will want to look for `A` (IPv4 address), `AAAA` (IPv6 address) or `ANY` (less likely, but possible) queries.
- You can also set up a filter like `(tcp port 80) or (tcp port 443)` to look for HTTP and HTTPS traffic on the respective standard ports, and look at the hostnames or at least IP addresses referenced there. ([QUIC](https://en.wikipedia.org/wiki/QUIC) uses UDP, but I wouldn't expect a years-old application to use that for its update checking mechanism.)
#1: Initial revision
by
Canina
·
2021-08-23T08:23:51Z (over 3 years ago)
You certainly can use Wireshark to look for DNS traffic. First off, because of caching, I strongly recommend that you reboot the computer, and as quickly as possible start Wireshark, start monitoring network traffic, set up a Wireguard filter, and then start the application in question, while doing as little else as possible. Also keep in mind that Wireshark will be looking at *all* network traffic, including loopback traffic, so you will likely get quite a lot of data quite quickly. (Hence my suggestion to do as little as possible other than the one task you want to monitor the network traffic for.) You should be able to use Wireshark's [filter toolbar](https://www.wireshark.org/docs/wsug_html_chunked/ChUseFilterToolbarSection.html) to set up a filter. [Filter rules](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) support typical boolean operators combined with network-centric expressions, and DNS uses either TCP or UDP (you may find places that claim that DNS is UDP, but while DNS *typically* uses UDP, it *can* use TCP, and does so for large queries) but always port 53 on the server side. The general syntax for filtering on a protocol and port combination is `[tcp|udp] [src|dst] port <port>`, so simply specifying `port 53` as the filter should get you all DNS traffic (queries and responses). Although I don't immediately see this mentioned in the Wireshark manual, apparently it also natively supports a [`dns` filter](https://resources.infosecinstitute.com/topic/infosec-skills-network-traffic-analysis-for-ir-dns-protocol-with-wireshark/) that does pretty much that. In that case, simply specifying `dns` as the filter should be sufficient. Be sure to click the apply 🠲 button to actually apply the filter. Either way, it looks like Wireshark has built-in support for decoding DNS queries and responses and displaying those in a somewhat user-friendly fashion, including showing the queried-for host name in the "Info" column. You will want to look for `A` (IPv4 address), `AAAA` (IPv6 address) or `ANY` (less likely, but possible) queries. You can also set up a filter like `(tcp port 80) or (tcp port 443)` to look for HTTP and HTTPS traffic on the respective standard ports, and look at the hostnames or at least IP addresses referenced there. ([QUIC](https://en.wikipedia.org/wiki/QUIC) uses UDP, but I wouldn't expect a years-old application to use that for its update checking mechanism.)