dns.log does not correctly report multi-question query results
Let me prefix this by saying that it likely doesn't matter in practice. This is all @ekoyle 's fault :-), who wondered over here how Zeek logs DNS transactions in which a single query packet contains multiple questions. You can't actually create such things via dig (it ends up sending multiple queries), and the interwebs say that this generally isn't a thing.
However, DNS can express this and Zeek parses this stuff ... so here we are. I'm attaching a pcap with a scapy-generated single query packet that asks for 3 names (foo.com, bar.com, example.com), and a response that answers one of them (bar.com -> 1.2.3.4). As far as I can tell they're structurally sound, but DNS aficionados are very welcome to take a look. It looks okay to me in Wireshark and tcpdump reports it as follows:
$ tcpdump -nn -r dns-three-questions-one-answer.pcap
reading from file dns-three-questions-one-answer.pcap, link-type IPV4 (Raw IPv4), snapshot length 65535
13:46:37.631639 IP 192.168.1.10.12345 > 8.8.8.8.53: 43690+ [3q] A? foo.com. A? bar.com. A? example.com. (55)
13:46:37.636639 IP 8.8.8.8.53 > 192.168.1.10.12345: 43690 [3q],, 1/0/0 A 1.2.3.4 (78)You can probably tell from the clunky [3q],, that this isn't routine — you need to crank up verbosity for it to make more sense:
$ tcpdump -vv -nn -r dns-three-questions-one-answer.pcap
reading from file dns-three-questions-one-answer.pcap, link-type IPV4 (Raw IPv4), snapshot length 65535
13:46:37.631639 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 83)
192.168.1.10.12345 > 8.8.8.8.53: [udp sum ok] 43690+ [3q] A? foo.com. A? bar.com. A? example.com. (55)
13:46:37.636639 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 106)
8.8.8.8.53 > 192.168.1.10.12345: [udp sum ok] 43690 [3q] q: A? foo.com., q: A? bar.com., q: A? example.com. 1/0/0 bar.com. A 1.2.3.4 (78)Running this through Zeek yields this dns.log:
{
"ts": 1763761597.631639,
"uid": "CQjgpT1nBw7L5OQKgl",
"id.orig_h": "192.168.1.10",
"id.orig_p": 12345,
"id.resp_h": "8.8.8.8",
"id.resp_p": 53,
"proto": "udp",
"trans_id": 43690,
"rtt": 0.005000114440917969,
"query": "example.com",
"qclass": 1,
"qclass_name": "C_INTERNET",
"qtype": 1,
"qtype_name": "A",
"rcode": 0,
"rcode_name": "NOERROR",
"AA": false,
"TC": false,
"RD": true,
"RA": true,
"Z": 0,
"answers": [
"1.2.3.4"
],
"TTLs": [
3600.0
],
"rejected": false,
"opcode": 0,
"opcode_name": "query"
}This seems wrong since it suggests that example.com got resolved to 1.2.3.4, which isn't the case. The underlying events are right — three dns_request events, one for every name, one dns_A_reply that correctly shows the bar.com -> 1.2.3.4 resolution. So it's most likely just the logging logic that's off here.
Source: zeek/zeek