Windows DNS Server

DNS logging is an essential part of security monitoring. Windows DNS Server acts as the Global Catalog server for the forest and domain within Active Directory and is installed by default. Windows DNS Server can also be installed manually.

Windows DNS monitoring overview

NXLog offers four general event logging facilities for monitoring DNS events generated by Windows DNS Server and its clients. They are discussed in their corresponding sections, listed below.

The following table maps some of the key features and attributes unique to each NXLog logging facility available for Windows DNS monitoring.

Table 1. Windows DNS monitoring overview
DNS Logging or Tracing Type Provider or Channel Module(s) Feature(s) Requirements

Audit and Analytical
(Tracing)

Microsoft-Windows-DNSServer

im_etw

Preferred method.
Native DNS Server auditing.
Best choice for Analytical logs.

Server versions 2012 R2 and later

Debug
(Logging,
Details option disabled)

im_file
xm_msdns

Fast.
The only way to log DNS transaction information.

Windows Server versions 2008 R2, 2012 R2, and 2016

Debug
(Logging,
Details option enabled)

im_file
xm_multiline

Fast.
The only way to log DNS transaction information.

Active Directory auditing
(Logging)

Microsoft-Windows-Security-Auditing

im_msvistalog

Systems without native DNS auditing

Windows 8.1 or later

Native DNS auditing
(Logging)

Microsoft-Windows-DNSServer/Audit

im_msvistalog

Preferred method for collecting DNS audit logs

Windows Server 2016, or 2012 R2 with hotfix 2956577

Sysmon
(Logging or Tracing)

Microsoft-Windows-Sysmon/Operational
Sysmon Event ID 22

im_msvistalog

Only DNS client query logging, but it is the only way to obtain the name and path of the client application executing the query.

Windows 8.1 or later
Sysmon v10.0 or later

DNS Client
(Logging or Tracing)

Microsoft-Windows-DNS-Client/Operational

im_msvistalog

Another source of DNS client query logging.

Windows 8.1 or later

DNS logging via ETW Providers

Enhanced Windows DNS Event Log logging is available from ETW providers. There are two categories of events monitored:

  1. Windows DNS Server Audit Events are enabled by default. An audit event is logged whenever the DNS Server settings, zones, or resource records are changed. Such DNS events are of utmost importance for security audits. Each of the 53 types of audit events are identified by a unique EventID which is documented in the Audit events table of Microsoft’s documentation. The Type column in this table contains a short description of the event; however, it is not included in the actual logged event. For example, if a new zone is created, it will not be possible to search for an event containing Record create, instead only EventID: 515 is available for identifying this type of event.

  2. Windows DNS Server Analytical Events must be specifically enabled. They represent the bulk of DNS events—​primarily lookups and other queries—​and can be quite large in volume. The Analytic events table of Microsoft’s documentation lists each of the 23 types of events that are monitored. Just like with Audit Events, Windows logs the EventID, but not the more descriptive Type field. According to the Audit and analytic event logging section of Microsoft’s documentation, when processing 100,000 queries per second (QPS) on modern hardware the expected reduction in performance is around 5% if Analytical Event logging is enabled.

Event tracing offers significant advantages over DNS Debug Logging in terms of architecture, flexibility, configurability, and performance. ETW events can be read directly without requiring events to be first written to disk. However, ETW is not available on older Windows systems. To maintain its performance it is by design a "best effort" framework and consequently does not guarantee that all events will be captured.

For more information, see the Installing and enabling DNS diagnostic logging section on Microsoft Docs.

With Analytical Logging enabled, NXLog can use the im_etw module to collect DNS logs from the Microsoft-Windows-DNSServer ETW provider. This is the preferred method for collecting logs from Windows Server versions 2012 R2 and later.

On Windows Server 2012 R2, this feature is provided by hotfix 2956577.

Examples

Example 1. Using im_etw

The following configuration collects DNS logs via ETW from the Microsoft-Windows-DNSServer provider, using the im_etw module. The collected logs are converted to JSON and saved to a file.

nxlog.conf
<Input etw>
    Module      im_etw
    Provider    Microsoft-Windows-DNSServer
</Input>
In this example, an Audit event has been logged. EventID: 515 identifies this as a Record create for this zone.
{
  "SourceName": "Microsoft-Windows-DNSServer",
  "ProviderGuid": "{EB79061A-A566-4698-9119-3ED2807060E7}",
  "EventID": 515,
  "Version": 0,
  "ChannelID": 17,
  "OpcodeValue": 0,
  "TaskValue": 5,
  "Keywords": "4611686018428436480",
  "EventTime": "2020-03-10T09:42:39.788511-07:00",
  "ExecutionProcessID": 4752,
  "ExecutionThreadID": 1732,
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "Domain": "WIN-R4QHULN6KLH",
  "AccountName": "Administrator",
  "UserID": "S-1-5-21-915329490-2962477901-227355065-500",
  "AccountType": "User",
  "Flags": "EXTENDED_INFO|IS_64_BIT_HEADER|PROCESSOR_INDEX (577)",
  "Type": "1",
  "NAME": "www.example.com",
  "TTL": "3600",
  "BufferSize": "4",
  "RDATA": "0x0A00020F",
  "Zone": "example.com",
  "ZoneScope": "Default",
  "VirtualizationID": ".",
  "EventReceivedTime": "2020-03-10T09:42:40.801598-07:00",
  "SourceModuleName": "etw",
  "SourceModuleType": "im_etw"
}

File-based DNS debug logging

Windows DNS Debug Logging is the only means of monitoring DNS events on Windows Server versions prior to 2012 R2. However, DNS Servers capable of ETW might be configured for file-based logging in cases where all events must be captured without exception.

Enabling DNS debug logging

DNS logging can be enabled with debug logging mode. Queries are logged one per line.

To enable DNS Debug Logging, perform the following actions.

  1. Open the DNS Management console (dnsmgmt.msc).

  2. Right-click on the DNS Server and choose Properties from the context menu.

  3. Under the Debug Logging tab, enable Log packets for debugging.

    DNS Server Properties window
  4. Mark the check boxes corresponding to the data that should be logged.

    The Details option will produce multi-line logs. To parse this detailed format, refer to Parsing detailed DNS logs with regular expressions below.
  5. Set the File path and name to the desired log file location.

    The Windows DNS service may not recreate the debug log file after a rollover. If you encounter this issue, be sure to use the C: drive for the debug log path. See the post, The disappearing Windows DNS debug log, on the NXLog website.
Log sample (Standard debug mode)
4/21/2017 7:52:03 AM 06B0 PACKET  00000000028657F0 UDP Snd 10.2.0.1        6590 R Q [8081   DR  NOERROR] A      (7)example(3)com(0)

See the following sections for information about parsing the logs.

Parsing non-detailed logs with xm_msdns

The xm_msdns module, available in NXLog Enterprise Edition, can be used for parsing Windows DNS Server logs.

This module does not support parsing of logs from DNS Debug Logging generated with the Details option enabled.
This module has been tested on Windows Server versions 2008 R2, 2012 R2, and 2016.
Example 2. Using xm_msdns

This configuration uses the im_file and xm_msdns modules to read and parse the log file. Output is written to file in JSON format for this example.

nxlog.conf
<Extension dns_parser>
    Module      xm_msdns
    EventLine   TRUE
    PacketLine  TRUE
    NoteLine    TRUE
</Extension>

<Input in>
    Module      im_file
    File        'C:\Server\dns.log'
    InputType   dns_parser
</Input>
Event sample
{
  "EventTime": "2017-04-21 07:52:03",
  "ThreadId": "06B0",
  "Context": "PACKET",
  "InternalPacketIdentifier": "00000000028657F0",
  "Protocol": "UDP",
  "SendReceiveIndicator": "Snd",
  "RemoteIP": "10.2.0.1",
  "Xid": "6590",
  "QueryResponseIndicator": "Response",
  "Opcode": "Standard Query",
  "FlagsHex": "8081",
  "RecursionDesired": true,
  "RecursionAvailable": true,
  "ResponseCode": "NOERROR",
  "QuestionType": "A",
  "QuestionName": "example.com",
  "EventReceivedTime": "2017-04-21 7:52:03",
  "SourceModuleName": "in",
  "SourceModuleType": "im_file"
}

Parsing non-detailed logs with regular expressions

While the xm_msdns module is the preferred method for parsing DNS logs, and is about three times faster, regular expressions can also be used.

This example does not parse logs from DNS Debug logging generated with the Details option enabled.
This has been tested on Windows Server versions 2008 R2, 2012 R2, and 2016.
Example 3. Parsing DNS logs with regular expressions

This example parses the log files generated by DNS Debug Logging and then writes the output to file in JSON format.

nxlog.conf
define EVENT_REGEX /(?x)(?<Date>\d+(?:\/\d+){2})\s \
                    (?<Time>\d+(?:\:\d+){2}\s\w+)\s \
                    (?<ThreadId>\w+)\s+ \
                    (?<Context>\w+)\s+ \
                    (?<InternalPacketIdentifier>[[:xdigit:]]+)\s+ \
                    (?<Protocol>\w+)\s+ \
                    (?<SendReceiveIndicator>\w+)\s \
                    (?<RemoteIP>[[:xdigit:].:]+)\s+ \
                    (?<Xid>[[:xdigit:]]+)\s \
                    (?<QueryType>\s|R)\s \
                    (?<Opcode>[A-Z]|\?)\s \
                    (?<QFlags>\[(.*?)\])\s+ \
                    (?<QuestionType>\w)\s+ \
                    (?<QuestionName>.*)/
define EMPTY_EVENT_REGEX /(^$|^\s+$)/
define DOMAIN_REGEX /\(\d+\)([\w-]+)\(\d+\)([\w-]+)/
define SUBDOMAIN_REGEX /\(\d+\)([\w-]+)\(\d+\)([\w-]+)\(\d+\)(\w+)/
define NOT_STARTING_WITH_DATE_REGEX /^(?!\d+\/\d+\/\d+).+/
define QFLAGS_REGEX /(?x)(?<FlagsHex>\d+)\s+ \
                     (?<FlagsCharCodes>\s+|([A-Z]{2}|[A-Z]))\s+ \
                     (?<ResponseCode>\w+)/

<Extension _json>
    Module  xm_json
</Extension>

<Input in>
    Module  im_file
    File    'C:\Server\dns.log'
    <Exec>
        # Drop entries that have empty lines
        if $raw_event =~ %EMPTY_EVENT_REGEX% drop();
        # Drop entries not starting with date
        if $raw_event =~ %NOT_STARTING_WITH_DATE_REGEX% drop();
        # Split entries into fields & define regular entries
        if $raw_event =~ %EVENT_REGEX%
        {
            $Regular = TRUE;
            $EventTime  = parsedate($Date + " " + $Time);
            $Raw = $raw_event;
            delete($date);
            delete($time);
            if $FlagsCharCodes =~ /^\s+$/ delete($FlagsCharCodes );
            # Convert domains from (8)mydomain(1)com to mydomain.com
            if $QuestionName =~ %DOMAIN_REGEX% $QuestionName = $1 + "." + $2;
            # Convert domains from (8)sub(8)mydomain(1)com to sub.mydomain.com
            if $QuestionName =~ %SUBDOMAIN_REGEX%
                $QuestionName = $1 + "." + $2 + "." +$3;

            # Set query flags
            if $QFlags =~ %QFLAGS_REGEX% delete($QFlags);

            # Set the query type
            if $QueryType =~ %EMPTY_EVENT_REGEX% $QueryType = "query";
            else $QueryType = "response";
        }
        else
        {
            $Regular = FALSE;
            $Raw = $raw_event;
        }
    </Exec>
</Input>

<Output out>
    Module  om_file
    Exec    to_json();
    File    'C:\output-dns-traffic.json'
</Output>
Output sample
{
  "EventReceivedTime": "2017-04-21 07:52:16",
  "SourceModuleName": "in",
  "SourceModuleType": "im_file",
  "Context": "PACKET",
  "InternalPacketIdentifier": "00000000028657F0",
  "Opcode": "Q",
  "Protocol": "UDP",
  "QueryType": "response",
  "QuestionName": "notabilus.com",
  "QuestionType": "A",
  "RemoteIP": "10.2.0.1",
  "SendReceiveIndicator": "Snd",
  "ThreadId": "06B0",
  "Xid": "6590",
  "Regular": true,
  "EventTime": "2017-04-21 07:52:03",
  "Raw": "4/21/2017 7:52:03 AM 06B0 PACKET  00000000028657F0 UDP Snd 10.2.0.1        6590 R Q [8081   DR  NOERROR] A      (9)notabilus(3)com(0)",
  "FlagsCharCodes": "DR",
  "FlagsHex": "8081",
  "ResponseCode": "NOERROR"
}

Parsing detailed DNS logs with regular expressions

Detailed DNS logging uses a multi-line format that can be parsed with xm_multiline and regular expressions.

Example 4. Parsing multiple line detailed debug DNS logs

In this example, the xm_multiline module joins lines that belong to the same event, by using a regular expression to match the header line. Then a regular expression is used to parse the content into fields.

Input sample
6/1/2017 8:33:36 PM 09B8 PACKET  0000022041EED460 UDP Rcv 192.168.56.1    edaa   Q [2001   D   NOERROR] A      (6)google(3)com(0)
UDP question info at 0000022041EED460
  Socket = 680
  Remote addr 192.168.56.1, port 48210
  Time Query=6941, Queued=0, Expire=0
  Buf length = 0x0fa0 (4000)
  Msg length = 0x0027 (39)
  Message:
    XID       0xedaa
    Flags     0x0120
      QR        0 (QUESTION)
      OPCODE    0 (QUERY)
      AA        0
      TC        0
      RD        1
      RA        0
      Z         0
      CD        0
      AD        1
      RCODE     0 (NOERROR)
nxlog.conf
define EVENT_REGEX /(?x)(?<Date>\d+(?:\/\d+){2})\s \
                   (?<Time>\d+(?:\:\d+){2}\s\w+)\s \
                   (?<ThreadId>\w+)\s+ \
                   (?<Context>\w+)\s+ \
                   (?<InternalPacketIdentifier>[[:xdigit:]]+)\s+ \
                   (?<Protocol>\w+)\s+ \
                   (?<SendReceiveIndicator>\w+)\s \
                   (?<RemoteIP>[[:xdigit:].:]+)\s+ \
                   (?<Xid>[[:xdigit:]]+)\s \
                   (?<QueryType>\s|R)\s \
                   (?<Opcode>[A-Z]|\?)\s \
                   (?<QFlags>\[(.*?)\])\s+ \
                   (?<QuestionType>\w+)\s+ \
                   (?<QuestionName>.*)\s+  \
                   (?<LogInfo>.+)\s+.+=\s \
                   (?<Socket>\d+)\s+ Remote\s+ addr\s \
                   (?<RemoteAddr>.+),\sport\s \
                   (?<PortNum>\d+)\s+Time\sQuery= \
                   (?<TimeQuery>\d+),\sQueued= \
                   (?<Queued>\d+),\sExpire= \
                   (?<Expire>\d+)\s+.+\( \
                   (?<BufLen>\d+)\)\s+.+\( \
                   (?<MsgLen>\d+)\)\s+Message:\s+ \
                   (?<Message>(?s).*)/

define HEADER_REGEX /(?x)(?<Date>\d+(?:\/\d+){2})\s \
                    (?<Time>\d+(?:\:\d+){2}\s\w+)\s \
                    (?<ThreadId>\w+)\s+ \
                    (?<Context>\w+)\s+ \
                    (?<InternalPacketIdentifier>[[:xdigit:]]+)\s+ \
                    (?<Protocol>\w+)\s+ \
                    (?<SendReceiveIndicator>\w+)\s \
                    (?<RemoteIP>[[:xdigit:].:]+)\s+ \
                    (?<Xid>[[:xdigit:]]+)\s \
                    (?<QueryType>\s|R)\s \
                    (?<Opcode>[A-Z]|\?)\s \
                    (?<QFlags>\[(.*?)\])\s+ \
                    (?<QuestionType>\w+)\s+ \
                    (?<QuestionName>.*)/

<Extension multiline>
    Module      xm_multiline
    HeaderLine  %HEADER_REGEX%
</Extension>

<Input filein>
    Module      im_file
    File        'C:\Server\dns.log'
    InputType   multiline
    <Exec>
        if $raw_event =~ %EVENT_REGEX%
        {
            $EventTime  = parsedate($Date + " " + $Time);
            delete($Date);
            delete($Time);
        }
    </Exec>
</Input>
Output sample
{
  "EventReceivedTime": "2018-11-30T04:33:38.660127+01:00",
  "SourceModuleName": "filein",
  "SourceModuleType": "im_file",
  "BufLen": "512",
  "Context": "PACKET",
  "Expire": "0",
  "InternalPacketIdentifier": "000000D58F45A560",
  "LogInfo": "UDP response info at 000000D58F45A560",
  "Message": "XID       0x000d\r\n    Flags     0x8180\r\n      QR        1 (RESPONSE)\r\n      OPCODE    0 (QUERY)\r\n      AA        0\r\n      TC        0\r\n      RD        1\r\n      RA        1\r\n      Z         0\r\n      CD        0\r\n      AD        0\r\n      RCODE     0 (NOERROR)\r\n    QCOUNT    1\r\n    ACOUNT    1\r\n    NSCOUNT   0\r\n    ARCOUNT   0\r\n    QUESTION SECTION:\r\n    Offset = 0x000c, RR count = 0\r\n    Name      \"(6)google(3)com(0)\"\r\n      QTYPE   AAAA (28)\r\n      QCLASS  1\r\n    ANSWER SECTION:\r\n    Offset = 0x001c, RR count = 0\r\n    Name      \"[C00C](6)google(3)com(0)\"\r\n      TYPE   AAAA  (28)\r\n      CLASS  1\r\n      TTL    26\r\n      DLEN   16\r\n      DATA   2a00:1450:400d:805::200e\r\n    AUTHORITY SECTION:\r\n      empty\r\n    ADDITIONAL SECTION:\r\n      empty\r\n",
  "MsgLen": "56",
  "Opcode": "Q",
  "PortNum": "60010",
  "Protocol": "UDP",
  "QFlags": "[8081   DR  NOERROR]",
  "QueryType": "R",
  "QuestionName": "(6)google(3)com(0)",
  "QuestionType": "AAAA",
  "Queued": "0",
  "RemoteAddr": "::1",
  "RemoteIP": "::1",
  "SendReceiveIndicator": "Snd",
  "Socket": "512",
  "ThreadId": "044C",
  "TimeQuery": "12131",
  "Xid": "000d",
  "EventTime": "2018-11-30T04:32:43.000000+01:00"
}

Collecting DNS query logs via Sysmon

Another potential source of DNS event logs is Sysmon. It is a system service and device driver which monitors system activity and logs to the Windows Event Log (see Setting up Sysmon for further details).

The DNS event log collection supported by Sysmon is not comparable to other types of DNS monitoring like DNS Server Audit and Analytical logging or DNS Server Debug Logging. In fact, Sysmon DNS Query logging provides only DNS client query logging, but the information it provides compliments the information from DNS Server Analytical logs by adding the name and path of the application which is querying the DNS Server. It can monitor the DNS queries executed by practically any Windows client software that is network-enabled, for instance web browsers, FileZilla, WinSCP, ping, tracert, etc. It should be noted that direct DNS lookups using nslookup are not logged by Sysmon’s DNS Query logging.

Configure DNS query logging

Once Sysmon is installed on a system, it does not log DNS client queries by default. Configuring it to do so is relatively easy, however. Create or copy a Sysmon configuration file to the same directory where the Sysmon.exe was installed:

config-dnsquery.xml
<Sysmon schemaversion="4.22">
  <EventFiltering>
    <DnsQuery onmatch="exclude"/>
  </EventFiltering>
</Sysmon>

With the XML configuration file confg-dnsquery.xml located in the same directory as Sysmon.exe, running the following command will apply the new configuration:

Apply the XML configuration for Sysmon to log DNS queries
C:\Windows> Sysmon.exe -c config-dnsquery.xml

Once the configuration file has been applied, it can be confirmed by issuing the same command with the -c option, but without any file specified:

Confirming successful rule configuration of Sysmon for DNS query logging
C:\Windows> Sysmon.exe -c
A good resource for configuring Sysmon to perform DNS monitoring can be found in this document on GitHub: sysmonconfig-export.xml. Despite being in XML, the DNS section starting at line 835 is quite readable. Lines 871-1063 provide a complete RuleGroup example of how to filter 180 domains to reduce noise from ads and other common sources of DNS traffic that can generate a large number of events but are benign.

The last few lines of output returned from Sysmon should produce the following confirmation that DNS Query logging is active.

Successful rule configuration of Sysmon for DNS query logging
Rule configuration (version 4.22):
 - DnsQuery              onmatch: exclude   combine rules using 'And'

Once Sysmon is active and running as a service, it will be logging various events in addition to DNS queries. These events are visible in the Windows Event Viewer under Applications and Services Log > Microsoft > Windows > Sysmon > Operational. Each event has an EventID. Sysmon Event ID 22, DNSEvent (DNS query), is generated when a process executes a DNS query, whether the result is successful or fails, cached or not. The telemetry for this event was added for Windows 8.1 so it is not available on Windows 7 and earlier. See the Sysmon section for more information.

To collect DNS events, Sysmon creates an ETW trace session and writes the data into the Windows Event Log which can then be collected with the im_msvistalog module. To avoid this performance overhead, it is recommended to use the im_etw module to collect event data directly from the DNS ETW providers for greater efficiency.
Example 5. Collecting DnsQuery logs with Sysmon

Environments that already utilize Sysmon monitoring (v10.0 or later) only need to use the im_msvistalog module and add the relevant Sysmon filtering rules for DNS Query monitoring. In this example, the im_msvistalog module will collect DnsQuery logs.

nxlog.conf
<Input sysmon>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Microsoft-Windows-Sysmon/Operational">
                    *[System[(EventID='22')]]
                </Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>
Example of Sysmon logging a ping event in JSON
{
  "EventTime": "2019-10-29T15:47:43.685222+00:00",
  "Hostname": "HOST1",
  "Keywords": "9223372036854775808",
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 22,
  "SourceName": "Microsoft-Windows-Sysmon",
  "ProviderGuid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}",
  "Version": 5,
  "TaskValue": 22,
  "OpcodeValue": 0,
  "RecordNumber": 9152,
  "ExecutionProcessID": 3880,
  "ExecutionThreadID": 868,
  "Channel": "Microsoft-Windows-Sysmon/Operational",
  "Domain": "NT AUTHORITY",
  "AccountName": "SYSTEM",
  "UserID": "S-1-5-18",
  "AccountType": "User",
  "Message": "Dns query:\r\nRuleName: \r\nUtcTime: 2019-10-29 15:47:43.274\r\nProcessGuid: {b3c285a4-5f1e-5db8-0000-0010c24d1d00}\r\nProcessId: 5696\r\nQueryName: example.com\r\nQueryStatus: 0\r\nQueryResults: ::ffff:93.184.216.34;\r\nImage: C:\\Windows\\System32\\PING.EXE",
  "Category": "Dns query (rule: DnsQuery)",
  "Opcode": "Info",
  "UtcTime": "2019-10-29 15:47:43.274",
  "ProcessGuid": "{b3c285a4-5f1e-5db8-0000-0010c24d1d00}",
  "ProcessId": "5696",
  "QueryName": "example.com",
  "QueryStatus": "0",
  "QueryResults": "::ffff:93.184.216.34;",
  "Image": "C:\\Windows\\System32\\PING.EXE",
  "EventReceivedTime": "2019-10-29T15:47:44.949924+00:00",
  "SourceModuleName": "sysmon",
  "SourceModuleType": "im_msvistalog"
}

Summary of DNS query fields

The fields of particular interest are the QueryName and Image fields, which together provide a wealth of information about the network activity of the client machine. Each event discloses which site—​internal or external—​was queried and which Windows application was preparing to access that remote site.

The Message field usually contains a long string of information, most of which is parsed out into the following fields:

  • UtcTime (what EventTime is based on)

  • ProcessGuid

  • ProcessId

  • QueryName (the FQDN being looked up)

  • QueryStatus

  • QueryResults

  • Image (the full path and file name of the client application’s executable which performed the DNS query)

Monitoring DNS event sources using Windows Event Log

The im_msvistalog module is the most versatile input module for Windows since it can capture almost any type of event. It can be used to collect DNS Server Audit events, DNS client events from Sysmon, and native DNS Client events, all of which are accessible from Windows Event Log.

Monitoring native DNS client events

Another source of DNS client events available for monitoring can be found in the provider/channel Microsoft-Windows-DNS-Client/Operational.

Example 6. Configure DNS client logging

Using the im_msvistalog module for collecting DNS client events from this source is similar to the configuration for getting events from Sysmon. A QueryXML block is used to select the source, some fields are used to filter out unwanted events, while other fields are used to select only the events of interest. In this configuration example, only four Event IDs are of interest, queries for "wpad" are not needed, and any QueryType other than "1" will be dropped.

nxlog.conf
<Input DNS_Client>
  Module  im_msvistalog
  <QueryXML>
      <QueryList>
          <Query Id="0">
              <Select Path="Microsoft-Windows-DNS-Client/Operational">
                  *[System[(EventID=3006 or EventID=3008 or
                            EventID=3010 or EventID=3018)]]
              </Select>
          </Query>
      </QueryList>
  </QueryXML>
  Exec    if ($QueryName == 'wpad') OR \
             ($QueryType != '1') drop();
</Input>
Output sample
{
  "EventTime": "2020-03-12T14:40:08.809107-07:00",
  "Hostname": "WIN-R4QHULN6KLH",
  "Keywords": "9223372036854775808",
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 3006,
  "SourceName": "Microsoft-Windows-DNS-Client",
  "ProviderGuid": "{1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}",
  "Version": 0,
  "TaskValue": 0,
  "OpcodeValue": 0,
  "RecordNumber": 42095,
  "ExecutionProcessID": 2224,
  "ExecutionThreadID": 4672,
  "Channel": "Microsoft-Windows-DNS-Client/Operational",
  "Domain": "WIN-R4QHULN6KLH",
  "AccountName": "Administrator",
  "UserID": "S-1-5-21-915329490-2962477901-227355065-500",
  "AccountType": "User",
  "Message": "DNS query is called for the name ntp.msn.com, type 1, query options 140738562228224, Server List , isNetwork query 0, network index 0, interface index 0, is asynchronous query 0",
  "Opcode": "Info",
  "QueryName": "ntp.msn.com",
  "QueryType": "1",
  "QueryOptions": "140738562228224",
  "IsNetworkQuery": "0",
  "NetworkQueryIndex": "0",
  "InterfaceIndex": "0",
  "IsAsyncQuery": "0",
  "EventReceivedTime": "2020-03-12T14:40:10.674875-07:00",
  "SourceModuleName": "DNS_Client",
  "SourceModuleType": "im_msvistalog"
}

Monitoring DNS Server audit events

Although the im_msvistalog module can be used for capturing DNS Server Audit events, if performance is a concern, using im_etw is a better choice and remains the recommended method.

Example 7. Configure DNS Server audit logging

No filtering is used in this configuration since most audit events are important and audit logs tend to be much lower in volume than analytical or debug logs.

nxlog.conf
<Input DNS_Audit>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Microsoft-Windows-DNSServer/Audit">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>
Output sample
{
  "EventTime": "2020-03-12T14:56:07.622472-07:00",
  "Hostname": "WIN-R4QHULN6KLH",
  "Keywords": "4611686018428436480",
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 516,
  "SourceName": "Microsoft-Windows-DNSServer",
  "ProviderGuid": "{EB79061A-A566-4698-9119-3ED2807060E7}",
  "Version": 0,
  "TaskValue": 5,
  "OpcodeValue": 0,
  "RecordNumber": 98,
  "ExecutionProcessID": 2000,
  "ExecutionThreadID": 4652,
  "Channel": "Microsoft-Windows-DNSServer/Audit",
  "Domain": "WIN-R4QHULN6KLH",
  "AccountName": "Administrator",
  "UserID": "S-1-5-21-915329490-2962477901-227355065-500",
  "AccountType": "User",
  "Message": "A resource record of type 1, name ns2.example.com and RDATA 0x0A000210 was deleted from scope Default of zone example.com.",
  "Category": "ZONE_OP",
  "Opcode": "Info",
  "Type": "1",
  "NAME": "ns2.example.com",
  "TTL": "0",
  "BufferSize": "4",
  "RDATA": "0A000210",
  "Zone": "example.com",
  "ZoneScope": "Default",
  "VirtualizationID": ".",
  "EventReceivedTime": "2020-03-12T14:56:09.343045-07:00",
  "SourceModuleName": "DNS_Audit",
  "SourceModuleType": "im_msvistalog"
}

Processing DNS Server analytical events

One limitation of the im_msvistalog module is that it cannot read event traces of analytical sources. For this reason, the im_etw module remains the preferred choice for collecting events from the DNS Server Analytical log. It is possible though, to leverage the File directive in im_msvistalog to read DNS Server Analytical logs from .etl files. The active DNS Server Analytical log file is located here:

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-DNSServer%4Analytical.etl

A limitation of reading .etl files with im_msvistalog is that the module cannot seek in such files, resulting in the file being read from the beginning every time NXLog is started. For this reason, this method should only be used to process DNS Server Analytical logs in archived .etl files and not to monitor active .etl files.

Example 8. Configure DNS Server analytical logging

Analytical log sources, like debug log sources, tend to generate a high volume of events that are not always useful. In this configuration example, an analysis of the log file determined that frequent lookups on 10 specific hosts were responsible for a sizable portion of the log file. Since none of these hosts are of interest for security monitoring, they are being filtered out to reduce noise.

nxlog.conf
<Input DNS_Analytical>
  Module  im_msvistalog
  File    C:\temp\DNSServer%4Analytical-Archive.etl
  Exec if ($QNAME == 'americas1.notify.windows.com.akadns.net.') OR \
          ($QNAME == 'cy2.vortex.data.microsoft.com.akadns.net.') OR \
          ($QNAME == 'dm3p.wns.notify.windows.com.akadns.net.') OR \
          ($QNAME == 'geo.vortex.data.microsoft.com.akadns.net.') OR \
          ($QNAME == 'v10-win.vortex.data.microsoft.com.akadns.net.') OR \
          ($QNAME == 'v10-win.vortex.data.microsoft.com.akadns.NET.') OR \
          ($QNAME == 'v10.vortex-win.data.microsoft.com.') OR \
          ($QNAME == 'wns.notify.windows.com.akadns.net.') OR \
          ($QNAME == 'wns.notify.windows.com.akadns.NET.') OR \
          ($QNAME == 'client.wns.windows.com.') OR \
          ($QTYPE == '15') \
       drop();
</Input>
Output sample
{
  "EventTime": "2020-03-12T19:21:47.052133-07:00",
  "Hostname": "WIN-R4QHULN6KLH",
  "Keywords": "9223372071214514176",
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 279,
  "SourceName": "Microsoft-Windows-DNSServer",
  "ProviderGuid": "{EB79061A-A566-4698-9119-3ED2807060E7}",
  "Version": 0,
  "TaskValue": 1,
  "OpcodeValue": 0,
  "RecordNumber": 60,
  "ExecutionProcessID": 2000,
  "ExecutionThreadID": 4188,
  "Domain": "NT AUTHORITY",
  "AccountName": "SYSTEM",
  "UserID": "S-1-5-18",
  "AccountType": "User",
  "Message": "INTERNAL_LOOKUP_CNAME: TCP=0; InterfaceIP=10.0.2.15; Source=10.0.2.15; RD=1; QNAME=ns1.example.com.; QTYPE=1; Port=54171; Flags=34176; XID=2; PacketData=0x00028580000100010000000003777777076578616D706C6503636F6D0000010001",
  "Category": "LOOK_UP",
  "Opcode": "Info",
  "TCP": "0",
  "InterfaceIP": "10.0.2.15",
  "Source": "10.0.2.15",
  "RD": "1",
  "QNAME": "ns1.example.com.",
  "QTYPE": "1",
  "Port": "54171",
  "Flags": "34176",
  "XID": "2",
  "BufferSize": "33",
  "PacketData": "00028580000100010000000003777777076578616D706C6503636F6D0000010001",
  "EventReceivedTime": "2020-03-12T19:28:51.560303-07:00",
  "SourceModuleName": "DNS_Analytical",
  "SourceModuleType": "im_msvistalog"
}
Disclaimer

While we endeavor to keep the information in this topic up to date and correct, NXLog makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability, or availability of the content represented here.

Last revision: 01 February 2021