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.
DNS Logging or Tracing Type | Provider or Channel | Module(s) | Feature(s) | Requirements |
---|---|---|---|---|
Audit and Analytical |
Microsoft-Windows-DNSServer |
Preferred method. |
Server versions 2012 R2 and later |
|
Debug |
Fast. |
Windows Server versions 2008 R2, 2012 R2, and 2016 |
||
Debug |
im_file |
Fast. |
||
Active Directory auditing |
Microsoft-Windows-Security-Auditing |
Systems without native DNS auditing |
Windows 8.1 or later |
|
Native DNS auditing |
Microsoft-Windows-DNSServer/Audit |
im_msvistalog |
Preferred method for collecting DNS audit logs |
Windows Server 2016, or 2012 R2 with hotfix 2956577 |
Sysmon |
Microsoft-Windows-Sysmon/Operational |
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 |
DNS Client |
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:
-
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. TheType
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 onlyEventID: 515
is available for identifying this type of event. -
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 descriptiveType
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
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.
<Input etw>
Module im_etw
Provider Microsoft-Windows-DNSServer
</Input>
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.
-
Open the DNS Management console (
dnsmgmt.msc
). -
Right-click on the DNS Server and choose Properties from the context menu.
-
Under the Debug Logging tab, enable Log packets for debugging.
-
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. -
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.
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. |
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.
<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>
{
"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. |
This example parses the log files generated by DNS Debug Logging and then writes the output to file in JSON format.
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>
{
"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.
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.
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)
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>
{
"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:
<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:
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:
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.
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. |
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.
<Input sysmon>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID='22')]]
</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
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
(whatEventTime
is based on) -
ProcessGuid
-
ProcessId
-
QueryName
(theFQDN
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.
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.
<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>
{
"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.
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.
<Input DNS_Audit>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Microsoft-Windows-DNSServer/Audit">*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
{
"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.
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.
<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>
{
"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"
}