Bug #6281
closeddns: structure of query differs between "alert" and "dns" event types
Description
In DNS query records, the dns object is a flat object representing the request. Even though a DNS request could contain multiple queries this is not seen in practice, which is probably the reason for the easier-to-use flat object.
Note: DNS responses do place all the responses in an answers array as multiple answers to a single query are normal.
In alerts for DNS, the query is (more correctly) placed in a query array.
For example, a DNS event request:
"dns": {
"type": "query",
"id": 55380,
"rrname": "google.de",
"rrtype": "AAAA",
"tx_id": 0,
"opcode": 0
}
The DNS metadata in an alert:
"dns": {
"query": [
{
"type": "query",
"id": 55380,
"rrname": "google.de",
"rrtype": "AAAA",
"tx_id": 0,
"opcode": 0
}
]
},
And a DNS record for an answer:
dns: {
answers: [
{
rdata: "35.212.0.44",
rrname: "suricata.io",
rrtype: "A",
ttl: 600
}
],
The question is how to resolve this going further. The DNS record type for requests looks clearly wrong, but I think there was some conscious decision to do that for the sake SIEMs, and changing that would probably break reports and other post-processing of the data.
Updated by Sascha Steinbiss 11 months ago
FWIW, in the case for the answers in the alerts the format appears to be identical to the "detailed" one in the DNS metadata events. So it really appears to be just a question of the queries.
Updated by Jason Ish 9 months ago
- Status changed from New to In Progress
- Assignee changed from OISF Dev to Jason Ish
- Target version changed from TBD to 8.0.0-beta1
Here's an alert on a DNS response. It is not in an array. If I had to guess, there was just a mix up during implementation and queries were put in an array when it was meant to put responses in the array:
{
"timestamp": "2023-10-24T22:14:56.664417+0000",
"flow_id": 100796292290581,
"pcap_cnt": 2,
"event_type": "alert",
"src_ip": "8.8.8.8",
"src_port": 53,
"dest_ip": "10.16.1.11",
"dest_port": 34435,
"proto": "UDP",
"pkt_src": "wire/pcap",
"tx_id": 1,
"alert": {
"action": "allowed",
"gid": 1,
"signature_id": 1,
"rev": 1,
"signature": "DNS TEST response answer name",
"category": "",
"severity": 3
},
"dns": {
"answer": {
"version": 2,
"type": "answer",
"id": 49971,
"flags": "8180",
"qr": true,
"rd": true,
"ra": true,
"opcode": 0,
"rrname": "suricata.io",
"rrtype": "A",
"rcode": "NOERROR"
}
},
"app_proto": "dns",
"direction": "to_client"
}
Given this is a bug that can result in loss of fidelity I'd like to consider it backport worthy, at least to 7.0.
Updated by Philippe Antoine 8 months ago
- Blocks Feature #5773: Support DNS over HTTPS (DoH) added
Updated by Jason Ish 8 months ago
- Blocked by Feature #6496: dns: new detection buffer: dns.answer.name added
- Blocked by Feature #6497: dns: new detection buffer: dns.query.name added
Updated by Jason Ish 7 months ago
- Blocked by deleted (Feature #6497: dns: new detection buffer: dns.query.name)
Updated by Jason Ish 7 months ago
- Blocked by deleted (Feature #6496: dns: new detection buffer: dns.answer.name)
Updated by Philippe Antoine 7 months ago
- Related to Bug #6458: eve/http: discrepancy in http events and http objects logged in alerts added
Updated by Philippe Antoine 7 months ago
- Blocks Feature #6621: dns: add keyword for dns rcode: dns.rcode added
Updated by Jason Ish about 2 months ago ยท Edited
For DNS requests we'll see the following breaking change:
Before
{
"timestamp": "2024-06-04T10:55:27.082147-0600",
"flow_id": 2041670771398517,
"pcap_cnt": 1,
"event_type": "dns",
"src_ip": "10.16.1.11",
"src_port": 42106,
"dest_ip": "1.1.1.1",
"dest_port": 53,
"proto": "UDP",
"pkt_src": "wire/pcap",
"dns": {
"type": "query",
"id": 0,
"rrname": "forum.suricata.io",
"rrtype": "A",
"tx_id": 0,
"opcode": 0
}
}
After
{
"timestamp": "2024-06-04T10:55:27.082147-0600",
"flow_id": 2041670948131806,
"pcap_cnt": 1,
"event_type": "dns",
"src_ip": "10.16.1.11",
"src_port": 42106,
"dest_ip": "1.1.1.1",
"dest_port": 53,
"proto": "UDP",
"pkt_src": "wire/pcap",
"dns": {
"type": "request",
"id": 0,
"flags": "100",
"rd": true,
"opcode": 0,
"rcode": "NOERROR",
"queries": [
{
"rrname": "forum.suricata.io",
"rrtype": "A"
}
]
}
}
Changes:
- The DNS request is now an object inside the dns.queries array instead of just fields inside the dns object.
- This is how DNS queries are logged in an alert record.
- I did change the name from query as used in the alert record to queries to better reflect what is logged here since we're already making a breaking change.
- As we're breaking things, may as well change type to request and response to better match the specification and other tools like Wireshark.
Notes:
- This could present challenges for those building reports on DNS fields, or correlating DNS queries with other records.
Updated by Victor Julien about 2 months ago
Does this mean we're doing a version:3 record type?
Updated by Jason Ish about 2 months ago
Victor Julien wrote in #note-12:
Does this mean we're doing a
version:3record type?
I suppose we should. We're breaking DNS requests when logged as part of a DNS event. We're also breaking DNS responses when part of an alert. Since we're breaking both its probably a good time for any additional cleanups as well.
Updated by Jason Ish about 2 months ago
Theres also #6400 which is another reason for a version bump as well.
Updated by Jason Ish about 2 months ago
Draft PR addressing requests: https://github.com/OISF/suricata/pull/11238
Updated by Jason Ish about 2 months ago
- Related to Feature #3952: mDNS protocol implementation added
Updated by Jason Ish about 2 months ago
- Status changed from In Progress to In Review
PR for review: https://github.com/OISF/suricata/pull/11283
Updated by Jason Ish about 2 months ago
Ping @Eric Leblond, as we started to talking about this over #6400 I think.
Updated by Jason Ish about 1 month ago
- Related to Feature #7011: DNS additional section parsing and logging added
Updated by Jason Ish 16 days ago
- Status changed from In Review to Closed
Merged, PR: https://github.com/OISF/suricata/pull/11439