Suricata

Note that normal suricata eve-log input is encapsulated in data key in my example out.

And version info:
2.1dev (rev e250040)

Also happens with 60a4965

Confirmed in both live and pcap mode. Packet captures were taken from the same physical interface but not at the same time.

From the same pcap, here's two example sessions (one with vlan tags, one without):

{"timestamp":"2015-05-21T11:30:00.962978+0100","flow_id":22189344,"pcap_cnt":6031,"event_type":"dns","src_ip":"10.X.X.X","src_port":65077,"dest_ip":"10.Y.Y.Y","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":7442,"rcode":"NXDOMAIN","rrname":"u.03.s.sophosxl.net","rrtype":"SOA","ttl":9}}
{"timestamp":"2015-05-21T11:30:01.467133+0100","flow_id":22312464,"pcap_cnt":6078,"event_type":"dns","vlan":1,"src_ip":"10.X.X.X","src_port":50545,"dest_ip":"10.Y.Y.Y","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":53770,"rcode":"NOERROR","rrname":"iplayerhelp.external.bbc.co.uk","rrtype":"CNAME","ttl":1797,"rdata":"bbciplayer.metafaq.com"}}

From live capture:

{"timestamp":"2015-05-21T10:17:27.866919","flow_id":140034661246416,"in_iface":"eth2","event_type":"dns","vlan":1,"src_ip":"10.X.X.X","src_port":41341,"dest_ip":"10.Y.Y.Y","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":20985}}
{"timestamp":"2015-05-21T10:17:27.867699","flow_id":140034661247088,"in_iface":"eth2","event_type":"dns","src_ip":"10.X.X.X","src_port":39122,"dest_ip":"10.Z.Z.Z","dest_port":53,"proto":"UDP","dns":{"type":"answer","id":20985}}

Note that there are also correct log entries, for example:

{"timestamp":"2015-05-21T10:15:18.195891","flow_id":140034664754368,"in_iface":"eth2","event_type":"dns","vlan":1,"src_ip":"10.X.X.X","src_port":53,"dest_ip":"10.Y.Y.Y","dest_port":50494,"proto":"UDP","dns":{"type":"answer","id":61479,"rrname":"internalnameredacted.local","rrtype":"A","ttl":0,"rdata":"10.Z.Z.Z"}}

The incorrect log entries greatly outnumber the correct ones in pcap mode. My sample is small and not statistically significant. The below is from a 1.2MB pcap:

-> % jq -c 'select(.dns.type=="answer") | select(.src_port==53)' eve.json | wc -l
3 # correct

-> % jq -c 'select(.dns.type=="answer") | select(.dest_port==53)' eve.json | wc -l
9897 # incorrect

And from the live capture:

-> % jq -c 'select(.dns.type=="answer") | select(.src_port==53)' dns.log | wc -l
4149 # correct

-> % jq -c 'select(.dns.type=="answer") | select(.dest_port==53)' dns.log | wc -l
1164 # incorrect

Live capture used 2.1beta2, pcap used 2.1dev (rev 0e2a4c0).

I propose we close this. I confirmed that I could replicate it with rev 0e2a4c0, but I am not able to replicate with 3.2RC1.

Appears it was fixed by this commit 133485937952d8ed106eae840f517edf53024e19 (though I'm not sure why...)

That commit shouldn't affect it, how did you determine that?

You're right. I limited my back testing to commits on the dns files, it could have been in another commit leading up to that one. I'll re-check.

Maybe a git bisect could be useful. It can be automated if you have a test case that returns good/bad.

This is the commit: https://redmine.openinfosecfoundation.org/projects/suricata/repository?utf8=%E2%9C%93&branch=master&tag=&rev=2f0e0f17dbb4f289f045ab38cf13dc2ef209a148