gamelinux / passivedns

A network sniffer that logs all DNS server replies for use in a passive DNS setup
http://gamelinux.org/
1.67k stars 372 forks source link

Caching behaviour #78

Closed bjornfro closed 7 years ago

bjornfro commented 8 years ago

Not sure this is an issue or working as designed.

However, it seems that we miss many of the client IP queries/logs because we enabled cache. To reduce bandwidth used for logs we very much want to keep cache enabled though.

We see our DNS resolver's query for "bad domain" to the Internet but we don't see the IP generating it. In many cases at least. When disabling cache it shows up.

Is that working as designed, regarding cache?

Running with below: /usr/sbin/passivedns -i eth0 -X 46CDNPRSxs -P 3600 -y -Y -D -p /var/run/passivedns.pid

/usr/sbin/passivedns -V

[] PassiveDNS 1.1.3 [] By Edward Bjarte Fjellskål edward.fjellskaal@gmail.com [] Using libpcap version 1.4.0 [] Using ldns version 1.6.17

zachsis commented 8 years ago

I am also seeing the same thing I believe. When running passivedns on a BIND DNS Caching server, I see the client IP in the logs for each DNS request sourcing from the dnscaching server itself.

i.e. tcpdump example of a workstation querying for amazon.com:

key:

10.x.x.x = client 10.10.x.x = dns caching server 10.20.x.x = internal dns resolver

11:02:35.443228 IP 10.x.x.x.59293 > 10.10.x.x.53: 57578+ A? amazon.com. (28)
11:02:35.443924 IP 10.10.x.x.47491 > 10.20.x.x.53: 47417+% [1au] A? amazon.com. (39)
11:02:35.444100 IP 10.10.x.x.33665 > 10.20.x.x.53: 25504+ [1au] NS? . (28)
11:02:35.444645 IP 10.20.x.x.53 > 10.10.x.x.33665: 25504 13/0/14 NS m.root-servers.net., NS a.root-servers.net., NS d.root-servers.net., NS j.root-servers.net., NS k.root-servers.net., NS f.root-servers.net., NS b.root-servers.net., NS i.root-servers.net., NS g.root-servers.net., NS l.root-servers.net., NS e.root-servers.net., NS c.root-servers.net., NS h.root-servers.net. (460)
11:02:35.482586 IP 10.20.x.x.53 > 10.10.x.x.47491: 47417 6/0/1 A 54.239.25.200, A 54.239.17.6, A 54.239.26.128, A 54.239.17.7, A 54.239.25.192, A 54.239.25.208 (135)
11:02:35.483647 IP 10.10.x.x.53 > 10.x.x.x.59293: 57578 6/13/11 A 54.239.26.128, A 54.239.25.208, A 54.239.25.200, A 54.239.25.192, A 54.239.17.7, A 54.239.17.6 (511)

output from /var/log/passivedns.log:

please note that 10.10.x.x again is the caching server, not the client who made the request.

1466787755.482586||10.10.x.x||10.20.x.x||IN||amazon.com.||A||54.239.25.200||40||1
1466787755.482586||10.10.x.x||10.20.x.x||IN||amazon.com.||A||54.239.17.6||40||1
1466787755.482586||10.10.x.x||10.20.x.x||IN||amazon.com.||A||54.239.26.128||40||1
1466787755.482586||10.10.x.x||10.20.x.x||IN||amazon.com.||A||54.239.17.7||40||1
1466787755.482586||10.10.x.x||10.20.x.x||IN||amazon.com.||A||54.239.25.192||40||1
1466787755.482586||10.10.x.x||10.20.x.x||IN||amazon.com.||A||54.239.25.208||40||1

Running passivedns with the following flags:

[root@myserv src]# passivedns -i eth1 -l /var/log/passivedns.log -u myuser -D -p /var/run/passivedns/passivedns.pid

It appears passivedns must be snagging the first response from the dns resolver to the dns caching server and not parsing the second response from the caching server to the client.

gamelinux commented 8 years ago

Yeah, so this is by design :)

So, from the above, this is probably what happens (or should happen):

client -> cache -> resolver

then

client <- cache <- resolver

Passivedns sees the queries: client <> cache and cache <> resolver

The resolver answers the cache, and at that time, passivedns writes out the logline (query + answer was seen) from that session. When the cache answers the client, it just updates the cached in memory table, like the client IP, timestamp, count. So it will not print the client IP in the logs.

You could start two instances of passivedns, and use bpf filters to just look at client <> cache, and cache <> resolver etc.

Hope this helps.

Edward

zachsis commented 8 years ago

I was able to BPF filter out all of my resolvers and only collect the client <> caching servers. Thanks!