Couple of weeks ago I had an issue where I changed DNS addresses in large network of around 300 nodes. After that, some of the nodes still continued to ask old DNS servers, although resolv.conf was ok, and host/nslookup were querying new DNS servers.
Looking at tcpdump and trying to record requests with iptables logging, I confirmed that indeed some of the hosts were still sending queries to old nameservers.
I took one of the hosts out of production and started shutting down services / stracing processes in an attempt to find out the culprit.
At the end – it was lldpd daemon, which obviously cached nameservers at startup and didn't even notice changes in resolv.conf.
So, my question is – is there a more intelligent way to find out which PId is generating specific kind of traffic? I tried with auditctl but without much success. CentOS 6 is in question but if there is solution for any Linux distro, I would appreciate it.
Best Answer
What's wrong with the auditctl?
You would do it like this
1) Define your audit rule to audit sendmsg and sendto system calls. These system calls are used during name resolution.
2) Now search for your audit records. You can grep based on the remote DNS IP here
In the below example you can see that application which was responsible for the systemcall is called dig
And the way to differentiate to which remote DNS request is send is here. So you would just have to grep for a particular DNS host.
Or even better - see what DNS hosts are used (I have only one in this example)
And then narrow down which apps are using those particular hosts.
Edit 1: Actually I just did strace of a simple ping to a host. Seems like sendmsg is not always used. Here is what I see
My previous example was based on dig app, which takes slightly different route in terms of system calls.
So it looks like in majority of cases it would be this rule
Followed by ausearch