So I tried to search the web for answers but didn't find any.
Is there any way to trace back which exe file or application caused the computer to make a specific DNS query?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this communitySo I tried to search the web for answers but didn't find any.
Is there any way to trace back which exe file or application caused the computer to make a specific DNS query?
Any application can easily submit any DNS resolution request. There are numerous libraries available and programmers can choose to perform the resolutions whichever way they want. For example, in Python it's one line of code (maybe two)
import dns.resolver
answers = dns.resolver.query('dnspython.org', 'MX')
To link an actual application to the UDP (assuming it is using the default UDP protocol) "session" it used to send the request, is a rather hard task. There are tools available for different Operating Systems (for example HomeProject or Microsoft Network Monitor) which can help to that direction.
Keep in mind, that the resolution process takes roughly a few milliseconds (DNS is competing among the fastest protocols). The process of resolving a domain name in order to get the IP address it resolves to, is being delegated from the stub resolver
(the "application" that needs the IP address for a corresponding domain name) to a Recursive DNS Server
(aka RDNS
). An example of such server is Google's Public DNS, at 8.8.8.8
and 8.8.4.4
. Your ISP will most likely provide the IP addresses of the RDNS
servers it operates to your home modem/router, which will send them to the devices connected to it (via DHCP
for example).
Among other things RDNS
servers will store a matching domain name to IP address pair in their internal cache
memory for a certain amount of time (TTL
, Time To Live). This means that if you perform a resolution request within that time frame, the RDNS
server will not go down the recursive resolution process, but will reply with the matching IP address it already has in memory. Therefore, the stub resolver
will get a response extremely fast. For example, this is the time it takes to perform a resolution:
The first time
;; Query time: 248 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
The second time
;; Query time: 40 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
What you are trying to do, is monitor which application opened a UDP socket on your system and listened to that socket for a response, for less than 3 seconds (the default timeout value for DNS). If you are not continuously monitoring both traffic and processes listening to specific ports, then as far as I know, there is no way to get the match. For future use, you will be able to match a process and a corresponding DNS resolution request, by looking at the ports used. For example, if application 1
opens port 7788
and you see a DNS request in the network traffic at the same time with source port
equal to 7788
(destination will most likely be 53
), then you have the application!