gamelinux / passivedns

A network sniffer that logs all DNS server replies for use in a passive DNS setup

Home Page:http://gamelinux.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fragmented IP

gavinspearhead opened this issue · comments

Does passivedns support fragmented IP packets? Or what else fishy is going on here?

It seems they don't get handled too wel, eg
dig -t tlsa _443._tcp.www.dougbarton.us +dnssec @8.26.56.26
doesn't get parsed properly. Wireshark says more fragments flag is set.

However this does get parsed properly (note: same query different DNS server, different answer)
dig -t tlsa _443._tcp.www.dougbarton.us +dnssec @8.8.8.8
the size of the packet is much smaller due to the omission of the additional section.
(436 instead of 1476 bytes)

There is no IP defrag nor any TCP stream reassembling :( :( :(. There might
be some IP-defrag code in a branch, but I could get ldns to parse the
reassembled packet and get anything useful out :/

On Wed, Sep 9, 2015, 00:39 Gavin Spearhead notifications@github.com wrote:

Does passivedns support fragmented IP packets? Or what else fishy is going
on here?

It seems they don't get handled too wel, eg
dig -t tlsa _443._tcp.www.dougbarton.us +dnssec @8.26.56.26
doesn't get parsed properly. Wireshark says more fragments flag is set.

However this does get parsed properly (note: same query different DNS
server, different answer)
dig -t tlsa _443._tcp.www.dougbarton.us +dnssec @8.8.8.8
the size of the packet is much smaller due to the omission of the
additional section.
(436 instead of 1476 bytes)


Reply to this email directly or view it on GitHub
#60.

I found a couple of bugs in the defrag code (a pointer calculations with the wrong type, and you need to cut off the UDP header). Here's the diff: https://gist.github.com/gavinspearhead/eafd74dc85098a970772
It seems ldns is not complaining any more now!
But then I get stuck with this:
[dns.c:130(dns_parser)] [D] DNS Query TID did not match Answer TID: 0 != 42674 - Skipping!

Any thoughts on why the cxt->plid doesn't seem to be set correctly? It does and set the plid in the query. And it does find it in the answer. Seems to be an issue with the connection tracking. Could it be overwritten when it finds the second fragment (which does not have the UDP header and all that)?