Caching behaviour about passivedns HOT 3 CLOSED

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

from passivedns.

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.

from passivedns.

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

from passivedns.