Open gavinspearhead opened 8 years ago
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 https://github.com/gamelinux/passivedns/issues/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)?
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)