=======
dns.log
=======

The Domain Name System (DNS) log, or :file:`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, :file:`dns.log` remains a powerful tool for security and network
administrators.

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

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

Inspecting the :file:`dns.log`
==============================

To inspect the :file:`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 :program:`jq` utility to review the contents.

.. code-block:: console

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

::

  {"ts":1774911641.78917,"uid":"CHhAvVGS1DHFjwGM9","id.orig_h":"172.17.0.2","id.orig_p":36844,"id.resp_h":"1.1.1.1","id.resp_p":53,"proto":"udp","trans_id":54060,"query":"zeek.org","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":2,"rejected":false,"opcode":0,"opcode_name":"query"}

  {"ts":1774911641.803041,"uid":"CHhAvVGS1DHFjwGM9","id.orig_h":"172.17.0.2","id.orig_p":36844,"id.resp_h":"1.1.1.1","id.resp_p":53,"proto":"udp","trans_id":20661,"rtt":0.03837108612060547,"query":"zeek.org","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":2,"answers":["192.0.78.150","192.0.78.212"],"TTLs":[60.0,60.0],"rejected":false,"opcode":0,"opcode_name":"query"}

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

.. code-block:: console

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

::

  {
    "ts": 1774911641.78917,
    "uid": "CHhAvVGS1DHFjwGM9",
    "id.orig_h": "172.17.0.2",
    "id.orig_p": 36844,
    "id.resp_h": "1.1.1.1",
    "id.resp_p": 53,
    "proto": "udp",
    "trans_id": 54060,
    "query": "zeek.org",
    "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": 2,
    "rejected": false,
    "opcode": 0,
    "opcode_name": "query"
  }
  {
    "ts": 1774911641.803041,
    "uid": "CHhAvVGS1DHFjwGM9",
    "id.orig_h": "172.17.0.2",
    "id.orig_p": 36844,
    "id.resp_h": "1.1.1.1",
    "id.resp_p": 53,
    "proto": "udp",
    "trans_id": 20661,
    "rtt": 0.03837108612060547,
    "query": "zeek.org",
    "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": 2,
    "answers": [
      "192.0.78.150",
      "192.0.78.212"
    ],
    "TTLs": [
      60.0,
      60.0
    ],
    "rejected": false,
    "opcode": 0,
    "opcode_name": "query"
  }

As emphasized in the :file:`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 :file:`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 :file:`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 :file:`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": 1774911641.803041,
    "uid": "CHhAvVGS1DHFjwGM9",
    "id.orig_h": "172.17.0.2",
    "id.orig_p": 36844,
    "id.resp_h": "1.1.1.1",
    "id.resp_p": 53,
    "proto": "udp",
    "trans_id": 20661,
    "rtt": 0.03837108612060547,
    "query": "zeek.org",
    "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": 2,
    "answers": [
      "192.0.78.150",
      "192.0.78.212"
    ],
    "TTLs": [
      60.0,
      60.0
    ],
    "rejected": false,
    "opcode": 0,
    "opcode_name": "query"
  }

According to this log entry, ``172.17.0.2`` asked ``1.1.1.1`` for the A
record of the host ``zeek.org``, and received the answer ``192.0.78.212`` and
``192.0.78.150``. There are more details in the log, but those are the key
elements an analyst should be able to extract.

Understanding the First :file:`dns.log` Entry
=============================================

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

::

  {
    "ts": 1774911641.78917,
    "uid": "CHhAvVGS1DHFjwGM9",
    "id.orig_h": "172.17.0.2",
    "id.orig_p": 36844,
    "id.resp_h": "1.1.1.1",
    "id.resp_p": 53,
    "proto": "udp",
    "trans_id": 54060,
    "query": "zeek.org",
    "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": 2,
    "rejected": false,
    "opcode": 0,
    "opcode_name": "query"
  }

According to this log entry, ``172.17.0.2`` asked ``1.1.1.1`` for the
AAAA record of the host ``zeek.org``, 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,
:doc:`/scripts/policy/protocols/dns/auth-addl.zeek`.

We can invoke the script using this syntax:

.. code-block:: console

  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 :file:`dns.log` entry:

.. code-block:: console

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

.. literal-emph::

  {"ts":1774911641.78917,"uid":"CHhAvVGS1DHFjwGM9","id.orig_h":"172.17.0.2","id.orig_p":36844,"id.resp_h":"1.1.1.1","id.resp_p":53,"proto":"udp","trans_id":54060,"query":"zeek.org","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":2,"rejected":false,"opcode":0,"opcode_name":"query","auth":["ns-1785.awsdns-31.co.uk"]}

The bolded ``auth`` item in the log entry shows that ``ns-1785.awsdns-31.co.uk`` is the
authoritative name server that is designated to answer questions about the AAAA
record for ``zeek.org``.

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 ``CHhAvVGS1DHFjwGM9``. This is
the same UID value that appeared in the :file:`conn.log` entry for a DNS
record. That means the DNS activity in the :file:`conn.log` and the DNS
activity in this :file:`dns.log` entry are the same.

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

.. code-block:: console

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

::

  {"ts":1774911641.78917,"uid":"CHhAvVGS1DHFjwGM9","id.orig_h":"172.17.0.2","id.orig_p":36844,"id.resp_h":"1.1.1.1","id.resp_p":53,"proto":"udp","trans_id":54060,"query":"zeek.org","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":2,"rejected":false,"opcode":0,"opcode_name":"query","auth":["ns-1785.awsdns-31.co.uk"]}
  {"ts":1774911641.803041,"uid":"CHhAvVGS1DHFjwGM9","id.orig_h":"172.17.0.2","id.orig_p":36844,"id.resp_h":"1.1.1.1","id.resp_p":53,"proto":"udp","trans_id":20661,"rtt":0.03837108612060547,"query":"zeek.org","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":2,"answers":["192.0.78.150","192.0.78.212"],"TTLs":[60.0,60.0],"rejected":false,"opcode":0,"opcode_name":"query"}

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

Remember that a single :file:`conn.log` entry summarized all of the DNS traffic
associate with the “connection” bearing UID ``CHhAvVGS1DHFjwGM9``. 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 :file:`conn.log` entry had the
timestamp ``1774911641.78917``, which is also the timestamp of the first
:file:`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 ``zeek.org``. The second
involved a query and response for IPv4-related information, i.e., an A record
for ``zeek.org``. It is interesting to note that the DNS resolver on the
``1.1.1.1`` system requested IPv6 information first, and then IPv4.

Conclusion
==========

Zeek’s :file:`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.
