Feature #2086
closedDNS answer for a NS containing multiple name servers should only be one line
Description
Below is a sample of pcap showing 192.168.170.8 requesting the name server for isc.org. The server responds with 4 name servers.
$ tcpdump -vv -r ~/dns.cap | grep isc ... 192.168.170.8.32797 > 192.168.170.20.domain: [udp sum ok] 8330+ NS? isc.org. (25) 192.168.170.20.domain > 192.168.170.8.32797: [udp sum ok] 8330 q: NS? isc.org. 4/0/0 isc.org. NS ns-ext.nrt1.isc.org., isc.org. NS ns-ext.sth1.isc.org., isc.org. NS ns-ext.isc.org., isc.org. NS ns-ext.lga1.isc.org. (124) ...
For the same packets, Suricata 3.2.1 shows the query as one line and then each of the name servers provided is each a separate log line. See below... Why is the answer just not one log line?
03/30/2005-00:52:17.740166 [**] Query TX 208a [**] isc.org [**] NS [**] 192.168.170.8:32797 -> 192.168.170.20:53 03/30/2005-00:52:17.758453 [**] Response TX 208a [**] Recursion Desired [**] 192.168.170.20:53 -> 192.168.170.8:32797 03/30/2005-00:52:17.758453 [**] Response TX 208a [**] isc.org [**] NS [**] TTL 3600 [**] ns-ext.nrt1.isc.org [**] 192.168.170.20:53 -> 192.168.170.8:32797 03/30/2005-00:52:17.758453 [**] Response TX 208a [**] isc.org [**] NS [**] TTL 3600 [**] ns-ext.sth1.isc.org [**] 192.168.170.20:53 -> 192.168.170.8:32797 03/30/2005-00:52:17.758453 [**] Response TX 208a [**] isc.org [**] NS [**] TTL 3600 [**] ns-ext.isc.org [**] 192.168.170.20:53 -> 192.168.170.8:32797 03/30/2005-00:52:17.758453 [**] Response TX 208a [**] isc.org [**] NS [**] TTL 3600 [**] ns-ext.lga1.isc.org [**] 192.168.170.20:53 -> 192.168.170.8:32797
In comparison, I looked at Bro to see how it handles this. The NS answers are located within one log line.
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p proto trans_id rtt query qclass qclass_name qtype qtype_name rcode rcode_name AA TC RD RA Z answers TTLs rejected #types time string addr port addr port enum count interval string count string count string count string bool bool bool bool count vector[string] vector[interval] bool 1112172737.740166 C2qvyN39DpMjGWUx62 192.168.170.8 32797 192.168.170.20 53 udp 8330 0.018287 isc.org 1 C_INTERNET 2 NS 0 NOERROR F F T T 0 ns-ext.nrt1.isc.org,ns-ext.sth1.isc.org,ns-ext.isc.org,ns-ext.lga1.isc.org 3600.000000,3600.000000,3600.000000,3600.000000 F
End Goal
My end goal is to use the Suricata DNS logs in JSON format. Below are the same lines represented by Suricata as JSON.
{"timestamp":"2005-03-30T00:52:17.740166-0800","flow_id":907251321752390,"pcap_cnt":27,"event_type":"dns","src_ip":"192.168.170.8","src_port":32797,"dest_ip":"192.168.170.20","dest_port":53,"proto":"UDP","dns":{"type":"query","id":8330,"rrname":"isc.org","rrtype":"NS","tx_id":0}} {"timestamp":"2005-03-30T00:52:17.758453-0800","flow_id":907251321752390,"pcap_cnt":29,"event_type":"dns","src_ip":"192.168.170.20","src_port":53,"dest_ip":"192.168.170.8","dest_port":32797,"proto":"UDP","dns":{"type":"answer","id":8330,"rcode":"NOERROR","rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.nrt1.isc.org"}} {"timestamp":"2005-03-30T00:52:17.758453-0800","flow_id":907251321752390,"pcap_cnt":29,"event_type":"dns","src_ip":"192.168.170.20","src_port":53,"dest_ip":"192.168.170.8","dest_port":32797,"proto":"UDP","dns":{"type":"answer","id":8330,"rcode":"NOERROR","rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.sth1.isc.org"}} {"timestamp":"2005-03-30T00:52:17.758453-0800","flow_id":907251321752390,"pcap_cnt":29,"event_type":"dns","src_ip":"192.168.170.20","src_port":53,"dest_ip":"192.168.170.8","dest_port":32797,"proto":"UDP","dns":{"type":"answer","id":8330,"rcode":"NOERROR","rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.isc.org"}} {"timestamp":"2005-03-30T00:52:17.758453-0800","flow_id":907251321752390,"pcap_cnt":29,"event_type":"dns","src_ip":"192.168.170.20","src_port":53,"dest_ip":"192.168.170.8","dest_port":32797,"proto":"UDP","dns":{"type":"answer","id":8330,"rcode":"NOERROR","rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.lga1.isc.org"}}
As JSON, I would expect a single log line to contain all the answers like the below:
{ "timestamp": "2005-03-30T00:52:17.758453-0800", "flow_id": 907251321752390, "pcap_cnt": 29, "event_type": "dns", "src_ip": "192.168.170.20", "src_port": 53, "dest_ip": "192.168.170.8", "dest_port": 32797, "proto": "UDP", "dns": { "type": "answer", "id": 8330, "rcode": "NOERROR", "rrname": "isc.org", "rrtype": "NS", "ttl": 3600, "rdata": [ "ns-ext.nrt1.isc.org", "ns-ext.sth1.isc.org", "ns-ext.isc.org", "ns-ext.lga1.isc.org" ] } }
My Setup
My DNS sample set is "_dns.cap (libpcap) Various DNS lookups_." from https://wiki.wireshark.org/SampleCaptures
My setup is an out of the box config from source (suricata-3.2.1) and I ensured DNS logging is enabled (see below).
- dns: # control logging of queries and answers # default yes, no to disable query: yes # enable logging of DNS queries answer: yes # enable logging of DNS answers # control which RR types are logged # all enabled if custom not specified #custom: [a, aaaa, cname, mx, ns, ptr, txt]
Updated by Ask Kemp over 7 years ago
p.s. This applies to more than just NS. The below is for MX.
tcpdump
192.168.170.8.32795 > 192.168.170.20.domain: [udp sum ok] 63343+ MX? google.com. (28) 192.168.170.20.domain > 192.168.170.8.32795: [udp sum ok] 63343 q: MX? google.com. 6/0/6 google.com. [9m12s] MX smtp4.google.com. 40, google.com. [9m12s] MX smtp5.google.com. 10, google.com. [9m12s] MX smtp6.google.com. 10, google.com. [9m12s] MX smtp1.google.com. 10, google.com. [9m12s] MX smtp2.google.com. 10, google.com. [9m12s] MX smtp3.google.com. 40 ar: smtp4.google.com. [10m] A 216.239.37.26, smtp5.google.com. [10m] A 64.233.167.25, smtp6.google.com. [10m] A 66.102.9.25, smtp1.google.com. [10m] A 216.239.57.25, smtp2.google.com. [10m] A 216.239.37.25, smtp3.google.com. [10m] A 216.239.57.26 (256)
Currently with Suricata 3.2.1
03/30/2005-00:47:50.501268 [**] Query TX f76f [**] google.com [**] MX [**] 192.168.170.8:32795 -> 192.168.170.20:53 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] Recursion Desired [**] 192.168.170.20:53 -> 192.168.170.8:32795 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] google.com [**] MX [**] TTL 552 [**] smtp4.google.com [**] 192.168.170.20:53 -> 192.168.170.8:32795 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] google.com [**] MX [**] TTL 552 [**] smtp5.google.com [**] 192.168.170.20:53 -> 192.168.170.8:32795 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] google.com [**] MX [**] TTL 552 [**] smtp6.google.com [**] 192.168.170.20:53 -> 192.168.170.8:32795 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] google.com [**] MX [**] TTL 552 [**] smtp1.google.com [**] 192.168.170.20:53 -> 192.168.170.8:32795 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] google.com [**] MX [**] TTL 552 [**] smtp2.google.com [**] 192.168.170.20:53 -> 192.168.170.8:32795 03/30/2005-00:47:51.333401 [**] Response TX f76f [**] google.com [**] MX [**] TTL 552 [**] smtp3.google.com [**] 192.168.170.20:53 -> 192.168.170.8:32795
Desire (as JSON):
{ "timestamp": "2005-03-30T00:47:51.333401-0800", "flow_id": 1448296924221870, "pcap_cnt": 4, "event_type": "dns", "src_ip": "192.168.170.20", "src_port": 53, "dest_ip": "192.168.170.8", "dest_port": 32795, "proto": "UDP", "dns": { "type": "answer", "id": 63343, "rcode": "NOERROR", "rrname": "google.com", "rrtype": "MX", "ttl": 552, "rdata": [ "smtp4.google.com", "smtp5.google.com", "smtp6.google.com", "smtp1.google.com", "smtp2.google.com", "smtp3.google.com" ] } }
note: Note that the "ttl" key for this MX example and the NS example may need to be moved as the value for each answer could be different.
Updated by Andreas Herz over 7 years ago
- Assignee set to Anonymous
- Target version set to TBD
Updated by Victor Julien about 7 years ago
- Status changed from New to Assigned
- Assignee changed from Anonymous to Giuseppe Longo
- Target version changed from TBD to 70
Will be addressed in the new EVE record type.
Updated by Jason Ish over 6 years ago
Closing. This has been addressed with the v2 of the EVE/DNS logger. Examples:
{"timestamp":"2005-03-30T02:52:17.758453-0600","flow_id":861475560311622,"pcap_cnt":29,"event_type":"dns","src_ip":"192.168.170.20","src_port":53,"dest_ip":"192.168.170.8","dest_port":32797,"proto":"UDP","dns":{"version":2,"type":"answer","id":8330,"flags":"8180","qr":true,"rd":true,"ra":true,"rcode":"NOERROR","rrname":"isc.org","answers":[{"rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.nrt1.isc.org"},{"rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.sth1.isc.org"},{"rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.isc.org"},{"rrname":"isc.org","rrtype":"NS","ttl":3600,"rdata":"ns-ext.lga1.isc.org"}],"grouped":{"NS":["ns-ext.nrt1.isc.org","ns-ext.sth1.isc.org","ns-ext.isc.org","ns-ext.lga1.isc.org"]}}}
{"timestamp":"2005-03-30T02:47:51.333401-0600","flow_id":519690635088302,"pcap_cnt":4,"event_type":"dns","src_ip":"192.168.170.20","src_port":53,"dest_ip":"192.168.170.8","dest_port":32795,"proto":"UDP","dns":{"version":2,"type":"answer","id":63343,"flags":"8180","qr":true,"rd":true,"ra":true,"rcode":"NOERROR","rrname":"google.com","answers":[{"rrname":"google.com","rrtype":"MX","ttl":552,"rdata":"smtp4.google.com"},{"rrname":"google.com","rrtype":"MX","ttl":552,"rdata":"smtp5.google.com"},{"rrname":"google.com","rrtype":"MX","ttl":552,"rdata":"smtp6.google.com"},{"rrname":"google.com","rrtype":"MX","ttl":552,"rdata":"smtp1.google.com"},{"rrname":"google.com","rrtype":"MX","ttl":552,"rdata":"smtp2.google.com"},{"rrname":"google.com","rrtype":"MX","ttl":552,"rdata":"smtp3.google.com"}],"grouped":{"MX":["smtp4.google.com","smtp5.google.com","smtp6.google.com","smtp1.google.com","smtp2.google.com","smtp3.google.com"]}}}
Pull request: https://github.com/OISF/suricata/pull/3287
Updated by Jason Ish over 6 years ago
- Related to Feature #2199: DNS answer events compacted added
Updated by Jason Ish over 6 years ago
- Related to Feature #1198: more compact dns logging added
Updated by Jason Ish over 6 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 4.1beta1