Unlike TCP connections which maintain state, UDP's connectionless nature makes tracking the originating process particularly challenging. When investigating mysterious DNS requests on my Fedora 12 system (kernel 2.6.32.16), I discovered traditional tools like netstat and lsof only show active sockets during the exact moment of packet transmission.


For contemporary Linux systems (kernel 4.3+), ss combined with grep provides better visibility:
ss -aup | grep -E 'State|53'

However, for older kernels or persistent monitoring, we need more sophisticated approaches:
The most effective solution combines network monitoring with process inspection:
# Install required tools on Debian-based systems:
sudo apt-get install sysdig

# Capture UDP traffic with process info
sudo sysdig -s 2000 -A -c spy_ip udp.port == 53

For modern kernels, eBPF provides powerful tracing capabilities:
# Trace DNS requests with process info
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_sendto {
    if (args->uservaddr == 53) {
        printf("%s[%d] sent UDP to port 53\n", comm, pid);
    }
}'

For continuous monitoring of DNS requests, consider this bash script:
#!/bin/bash
while true; do
    date
    sudo strace -p $(pgrep -f "domain-to-resolve") -e trace=network -f 2>&1 | \
        grep "sendto" | grep -oP 'AF_INET, "\K[^"]+'
    sleep 1
done

When all else fails, kernel probes can reveal the culprit:
sudo perf probe --add 'udp_sendmsg sk->sk_protocol'
sudo perf stat -e 'probe:udp_sendmsg' -a sleep 30

For containerized environments, inspect network namespaces:
lsns -t net
nsenter -t $(pidof suspicious-process) -n netstat -aup

After identifying potential candidates, verify with:
sudo grep -l "domain.com" /proc/[0-9]*/fd/*



Unlike TCP connections which maintain state, UDP's stateless nature makes process identification particularly challenging. When investigating continuous DNS traffic on my Fedora 12 system (kernel 2.6.32), traditional tools like netstat and lsof proved inadequate because they only show active sockets at the exact moment of execution.
For persistent UDP traffic monitoring, we need tools that can capture traffic and correlate it with process information:
# Method 1: Using ss (socket statistics)
sudo ss -aup | grep -E 'State|:53'

# Method 2: Advanced process monitoring with strace
sudo strace -f -e trace=network -p $(pgrep -f "process_pattern") 2>&1 | grep sendto

For deeper inspection, BPF (Berkeley Packet Filter) tools provide the most reliable solution:
# Install BPF tools (on modern systems)
sudo apt install bpfcc-tools

# Trace UDP packets and show associated PIDs
sudo /usr/sbin/tcpdump -i any -nn -p udp port 53 | awk '{print $3}' | xargs -I {} sudo lsof -i udp | grep {}

For continuous monitoring of DNS requests, SystemTap offers powerful capabilities:
# SystemTap script to monitor UDP/DNS traffic
probe kernel.trace("udp_sendmsg") {
    printf("%s[%d] sent UDP to %s:%d\n", execname(), pid(), 
           ip_ntop(&__ip_sk_daddr(skb)->sin_addr.s_addr), 
           ntohs(__ip_sk_daddr(skb)->sin_port))
}

When dealing with containerized environments, we need additional steps:
# Find the network namespace of a process
ls -l /proc/$(pidof suspicious_process)/ns/net

# Enter the namespace and run inspection tools
nsenter -t $(pidof suspicious_process) -n netstat -aup

Here's a complete workflow to identify unwanted DNS traffic:
# Step 1: Capture DNS traffic
sudo tcpdump -i any -nn -p udp port 53 -w dns_traffic.pcap &

# Step 2: Monitor processes making DNS requests
sudo auditctl -a exit,always -F arch=b64 -S socket -F a0=2 -k udp_tracing

# Step 3: Correlate data
ausearch -k udp_tracing | grep "pid=" | awk '{print $2}' | cut -d= -f2 | sort -u

Remember that on older kernels (like 2.6.32), some modern tools may require backported versions or alternative approaches.