dns.log¶

The Domain Name System (DNS) log, or dns.log, is one of the most important data sources generated by Zeek. Although recent developments in domain name resolution have challenged traditional methods for collecting DNS data, dns.log remains a powerful tool for security and network administrators.

Those interested in getting details on every element of the dns.log should refer to DNS::Info.

Throughout the sections that follow, we will inspect Zeek logs in JSON format.

Inspecting the `dns.log`¶

To inspect the dns.log, we will use the same techniques we learned earlier in the manual. First, we have a JSON-formatted log file, either collected by Zeek watching a live interface, or by Zeek processing stored traffic. We use the jq utility to review the contents.

zeek@zeek:~/zeek-test/json$ jq . -c dns.log

{"ts":1591367999.306059,"uid":"CMdzit1AMNsmfAIiQc","id.orig_h":"192.168.4.76","id.orig_p":36844,"id.resp_h":"192.168.4.1","id.resp_p":53,"proto":"udp","trans_id":8555,"query":"testmyids.com","qclass":1,"qclass_name":"C_INTERNET","qtype":28,"qtype_name":"AAAA","rcode":0,"rcode_name":"NOERROR","AA":false,"TC":false,"RD":true,"RA":false,"Z":0,"rejected":false}

{"ts":1591367999.305988,"uid":"CMdzit1AMNsmfAIiQc","id.orig_h":"192.168.4.76","id.orig_p":36844,"id.resp_h":"192.168.4.1","id.resp_p":53,"proto":"udp","trans_id":19671,"rtt":0.06685185432434082,"query":"testmyids.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":["31.3.245.133"],"TTLs":[3600],"rejected":false}

As before, we could see each field printed on its own line:

zeek@zeek:~/zeek-test/json$ jq . dns.log

{
  "ts": 1591367999.306059,
  "uid": "CMdzit1AMNsmfAIiQc",
  "id.orig_h": "192.168.4.76",
  "id.orig_p": 36844,
  "id.resp_h": "192.168.4.1",
  "id.resp_p": 53,
  "proto": "udp",
  "trans_id": 8555,
  "query": "testmyids.com",
  "qclass": 1,
  "qclass_name": "C_INTERNET",
  "qtype": 28,
  "qtype_name": "AAAA",
  "rcode": 0,
  "rcode_name": "NOERROR",
  "AA": false,
  "TC": false,
  "RD": true,
  "RA": false,
  "Z": 0,
  "rejected": false
}
{
  "ts": 1591367999.305988,
  "uid": "CMdzit1AMNsmfAIiQc",
  "id.orig_h": "192.168.4.76",
  "id.orig_p": 36844,
  "id.resp_h": "192.168.4.1",
  "id.resp_p": 53,
  "proto": "udp",
  "trans_id": 19671,
  "rtt": 0.06685185432434082,
  "query": "testmyids.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": [
    "31.3.245.133"
  ],
  "TTLs": [
    3600
  ],
  "rejected": false
}

As emphasized in the conn.log material, what an analyst derives from any log is a function of the questions that he or she is trying to ask of it. The dns.log captures application-level name resolution activity, assuming that traffic is not encrypted, as is the case with DNS over HTTPS (DoH) or DNS over TLS (DoT). Applications mainly use DNS to resolve names to IP addresses, IP addresses to names, and certain other functions. Intruders use DNS for the same purposes, but may also subvert the protocol to carry command-and-control traffic, obfuscated or encrypted payload data, or other unwanted functions. DNS is a suitable protocol for these nefarious activities because administrators tend to allow it throughout their purview, as it is necessary for normal network operation.

In brief, when looking at the dns.log, analysts will primarily want to know who is asking a question, what is the nature of the question, who answered the question, and how was the question answered.

Understanding the Second `dns.log` Entry¶

Let’s use this framework to parse the two log entries. We will start with the second entry. For reference, that entry is the following:

{
  "ts": 1591367999.305988,
  "uid": "CMdzit1AMNsmfAIiQc",
  "id.orig_h": "192.168.4.76",
  "id.orig_p": 36844,
  "id.resp_h": "192.168.4.1",
  "id.resp_p": 53,
  "proto": "udp",
  "trans_id": 19671,
  "rtt": 0.06685185432434082,
  "query": "testmyids.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": [
    "31.3.245.133"
  ],
  "TTLs": [
    3600
  ],
  "rejected": false
}

According to this log entry, 192.168.4.76 asked 192.168.4.1 for the A record of the host testmyids.com, and received the answer 31.3.245.133. There are more details in the log, but those are the key elements an analyst should be able to extract.

Understanding the First `dns.log` Entry¶

Let’s take a look at the first dns.log entry. For reference, that entry is the following:

{
  "ts": 1591367999.306059,
  "uid": "CMdzit1AMNsmfAIiQc",
  "id.orig_h": "192.168.4.76",
  "id.orig_p": 36844,
  "id.resp_h": "192.168.4.1",
  "id.resp_p": 53,
  "proto": "udp",
  "trans_id": 8555,
  "query": "testmyids.com",
  "qclass": 1,
  "qclass_name": "C_INTERNET",
  "qtype": 28,
  "qtype_name": "AAAA",
  "rcode": 0,
  "rcode_name": "NOERROR",
  "AA": false,
  "TC": false,
  "RD": true,
  "RA": false,
  "Z": 0,
  "rejected": false
}

According to this log entry, 192.168.4.76 asked 192.168.4.1 for the AAAA record of the host testmyids.com, and did not receive an answer.

This is technically true, but it is not the whole story. If we augment stock Zeek with an additional script available from the project, we get a bit more information.

Specifically, we can enable a new script, policy/protocols/dns/auth-addl.zeek.

We can invoke the script using this syntax:

zeek@zeek:~/zeek-test/json2$ zeek -C LogAscii::use_json=T protocols/dns/auth-addl.zeek -r ../tm1t.pcap

The end result shows more information for the first dns.log entry:

zeek@zeek:~/zeek-test/json2$ cat dns.log | head -1

{"ts":1591367999.306059,"uid":"CQsafSKqmlOyqrgC6","id.orig_h":"192.168.4.76","id.orig_p":36844,"id.resp_h":"192.168.4.1","id.resp_p":53,"proto":"udp","trans_id":8555,"query":"testmyids.com","qclass":1,"qclass_name":"C_INTERNET","qtype":28,"qtype_name":"AAAA","rcode":0,"rcode_name":"NOERROR","AA":false,"TC":false,"RD":true,"RA":false,"Z":0,"rejected":false,"auth":["ns59.1and1.co.uk"]}

The bolded auth item in the log entry shows that ns59.1and1.co.uk is the authoritative name server that is designated to answer questions about the AAAA record for testmyids.com.

There are more details in the log, but those are the key elements an analyst should be able to extract.

The `uid` and Other Fields¶

Note the uid field in both log entries is CMdzit1AMNsmfAIiQc. This is the same UID value that appeared in the conn.log entry for a DNS record. That means the DNS activity in the conn.log and the DNS activity in this dns.log entry are the same.

You could have used the UID in the conn.log to search for the corresponding records in the dns.log using this UID. For example:

zeek@zeek:~/zeek-test/json$ grep CMdzit1AMNsmfAIiQc dns.log

{"ts":1591367999.306059,"uid":"CMdzit1AMNsmfAIiQc","id.orig_h":"192.168.4.76","id.orig_p":36844,"id.resp_h":"192.168.4.1","id.resp_p":53,"proto":"udp","trans_id":8555,"query":"testmyids.com","qclass":1,"qclass_name":"C_INTERNET","qtype":28,"qtype_name":"AAAA","rcode":0,"rcode_name":"NOERROR","AA":false,"TC":false,"RD":true,"RA":false,"Z":0,"rejected":false}

{"ts":1591367999.305988,"uid":"CMdzit1AMNsmfAIiQc","id.orig_h":"192.168.4.76","id.orig_p":36844,"id.resp_h":"192.168.4.1","id.resp_p":53,"proto":"udp","trans_id":19671,"rtt":0.06685185432434082,"query":"testmyids.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":["31.3.245.133"],"TTLs":[3600.0],"rejected":false}

Note the matching uid fields in the dns.log entries. In this simple example, these are the only two entries in the dns.log. Extrapolate this technique to logs with billions of records and you will appreciate the value!

Remember that a single conn.log entry summarized all of the DNS traffic associate with the “connection” bearing UID CMdzit1AMNsmfAIiQc. Zeek treated the 4 packets associated with this conversation as a connection because they shared the same source and destination IP addresses and ports, and occurred over the UDP protocol. The single conn.log entry had the timestamp 1591367999.305988, which is also the timestamp of the first dns.log entry.

Zeek’s DNS protocol analyzer created two log entries because it recognized two different DNS exchanges. The first involved a query and response for IPv6-related information, i.e., a AAAA record for testmyids.com. The second involved a query and response for IPv4-related information, i.e., an A record for testmyids.com. It is interesting to note that the DNS resolver on the 192.168.4.76 system requested IPv6 information first, and then IPv4.

Conclusion¶

Zeek’s dns.log is a critical log that offers a great deal of information on how systems are interacting with the Internet and each other. In the next section we will look at other core Internet protocols.

dns.log¶

Inspecting the dns.log¶

Understanding the Second dns.log Entry¶

Understanding the First dns.log Entry¶

The uid and Other Fields¶

Conclusion¶

Inspecting the `dns.log`¶

Understanding the Second `dns.log` Entry¶

Understanding the First `dns.log` Entry¶

The `uid` and Other Fields¶