Be sure to read Part 1 and Part 3 of our DNS Log Collection series, in case you missed them.

DNS Log Collection on Windows

If you need to reduce the cost of DNS security and increase efficiency through centralizing DNS log collection, where would you start? Answering this question requires knowledge and awareness of the challenges and opportunities available on the Windows platform.

While Windows DNS server is a common technology serving many types of organizations, from local domains to large multi-site enterprises, the possibilities are not necessarily that well-known within the context of comprehensive, site-wide log collection. This article distills the main concepts essential to planning and deploying such an implementation into this article, which serves as the second part of the DNS log collection series.

To start, this article will touch on log sources that are generated by Windows DNS servers as well as the DNS requests of the clients they serve.

Windows DNS Log Sources

You may know that there are several ways of collecting DNS logs within the Windows environment:

The deployment and resources to be used for DNS log collection will also depend on whether the logs will be collected from the DNS server (a critical asset) or from DNS clients. Each of these will be covered in further detail in this blog post.

Collecting DNS Query Logs from Sysmon

Sysmon includes a DNS Query logging feature to collect DNS query logs from clients. These events are generated when a process executes a DNS query, whether the result is successful or fails, cached or not.

Depending on how Sysmon is configured, you can also set additional rules in the configuration file for Sysmon in relation to Event ID 22: DNSEvent (DNS query). This is advisable due to the noisy nature of this type of event.

These types of additional rules can be:

  • Exclusion rules to avoid logging reverse DNS lookups

  • Exclusion rules about which domains to exclude. When excluding certain top level domains (to reduce the amount of logs collected), be as specific as possible with domains

  • Rules to exclude IPv6 lookups

  • Rules to omit domains typically used in sandboxes like localhost

  • Rules to omit queries involving popular third-party applications like Google, Mozilla, as well as CDNs

  • Rules to omit sites that involve social media widgets like Disqus

  • Rules to exclude ad serving sites and other ad-related services

These are only suggestions for rules and are by all means non-exhaustive. There are Sysmon configuration samples available online for use and adaptation.

Since DNS queries generate a large amount of logs, you may opt to forward Sysmon DNS events in their own output stream to a central log server instead of merging them with other DNS client event sources.

Sysmon DNS Query Event Sample in JSON Format
{
"EventTime":"2020-02-04T14:59:39.343541+00:00",
"Hostname":"EC2AMAZ-EPO7HKA",
"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":9532,
"ExecutionProcessID":1996,
"ExecutionThreadID":2616,
"Channel":"Microsoft-Windows-Sysmon/Operational",
"Domain":"NT AUTHORITY",
"AccountName":"SYSTEM",
"UserID":"S-1-5-18",
"AccountType":"User",
"Message":"Dns query:\r\nRuleName: \r\nUtcTime: 2020-02-04 14:59:38.349\r\nProcessGuid: {b3c285a4-3cda-5dc0-0000-001077270b00}\r\nProcessId: 1904\r\nQueryName: EC2AMAZ-EPO7HKA\r\nQueryStatus: 0\r\nQueryResults: 172.31.46.38;\r\nImage: C:\\Program Files\\nxlog\\nxlog.exe",
"Category":"Dns query (rule: DnsQuery)",
"Opcode":"Info",
"UtcTime":"2020-02-04 14:59:38.349",
"ProcessGuid":"{b3c285a4-3cda-5dc0-0000-001077270b00}",
"ProcessId":"1904","QueryName":"EC2AMAZ-EPO7HKA","QueryStatus":"0",
"QueryResults":"172.31.46.38;",
"Image":"C:\\Program Files\\nxlog\\nxlog.exe",
"EventReceivedTime":"2020-02-04T14:59:40.780905+00:00",
"SourceModuleName":"in",
"SourceModuleType":"im_msvistalog"
}

Collecting from DNS ETW Providers

The DNS ETW providers with their corresponding GUIDs are displayed in the following table.

Table 1. List of ETW Providers
ETW Provider Name GUID

DNS Server Trace Provider

57840C25-FA99-4F0D-928D-D81D1851E3DD

Microsoft-Windows-DNS-Client

1C95126E-7EEA-49A9-A3FE-A378B03DDB4D

Microsoft-Windows-DNS-Server-Service

71A551F5-C893-4849-886B-B5EC8502641E

Microsoft-Windows-DNSServer

EB79061A-A566-4698-9119-3ED2807060E7

Most of the time, ETW is not considered as a log source, either because it is not widely known or because special tools are needed to keep track of log traces (see Solving Windows Log Collection Challenges with Event Tracing). In addition, these tools can negatively affect DNS server performance, especially if they are set to continuously collect and write event traces to disk or convert to a format like JSON before being forwarded to a remote host.

Enhanced Windows DNS Event Log Logging

Enhanced DNS Server audit events are available via both the Windows Event Log channels, such as the Microsoft-Windows-DNSServer/Audit channel, as well as directly from the Windows Event Tracing (ETW) provider. These enable change tracking on Windows DNS Server, provided audit events are set to be logged in the Group Policy Editor. If enabled, an audit event is logged for each instance when changes are made to the DNS server such as:

Windows DNS Audit Events

  • Zone operations – zone deletions, updates, zone record creation and deletion, zone scope creation and deletion, online signing (zone signing/unsigning/resigning), pausing/reloading/resuming zones

  • DNSSEC operations – key rollover events, export/importing of DNSSEC metadata, addition of trust point

  • Cache operations – (cache purge events)

  • Policy operation events – creation/deletion/updating of records such as client subnet records, server level policies or zone level policies

  • Other server operations – restarting the server, clearing of debug logs, clearing of statistics, scavenging operations

These audit events represent important operations for any DNS server. They can provide very useful information for security and compliance reasons, as well as for incident response.

Ensure that auditing is enabled on Windows DNS Server via the Group Policy Management Editor. You can also configure auditing on the target object via the ADSIEDIT.MSC console by making the necessary changes for the auditing properties of that object.

Example console screen for changing the auditing settings on Group Policy

The following is an event sample from Microsoft Windows DNS Server for the audit event 513 (Type: Zone delete, Category: Zone operations) generated by the Microsoft-Windows-DNSServer channel.

Zone Deletion Event Sample in JSON Format
{
  "EventTime":"2020-02-17T13:41:17.260147+00:00",
  "Hostname":"Workstation A",
  "Keywords":"4611686018427912192",
  "EventType":"INFO",
  "SeverityValue":2,
  "Severity":"INFO",
  "EventID":513,
  "SourceName":"Microsoft-Windows-DNSServer",
  "ProviderGuid":"{EB79061A-A566-4698-9119-3ED2807060E7}",
  "Version":0,
  "TaskValue":5,
  "OpcodeValue":0,
  "RecordNumber":10,
  "ExecutionProcessID":1936,
  "ExecutionThreadID":2820,
  "Channel":"Microsoft-Windows-DNSServer/Audit",
  "Domain":"Example.corp.com",
  "AccountName":"Administrator",
  "UserID":"S-1-5-21-211798184-3831789826-2356777772-500",
  "AccountType":"User",
  "Message":"The zone example.com was deleted. [virtualization instance: .].",
  "Category":"ZONE_OP",
  "Opcode":"Info",
  "Zone":"test.corp.com",
  "VirtualizationID":".",
  "EventReceivedTime":"2020-02-17T13:41:23.978572+00:00",
  "SourceModuleName":"in",
  "SourceModuleType":"im_msvistalog"
}

Windows DNS Analytical Events

DNS analytical events differ from DNS auditing in that they are generated each time Windows DNS Server processes a request. They need to be enabled on the DNS server before logging can happen.

Types of DNS analytical events include:

  • Look up events – response success/failure, CNAME lookups, internal lookups

  • Recursive query events

  • Dynamic update events

  • Zone XFR events

The following sample shows Event ID 280 (Type: Internal lookup additional, Category: Lookup) that is generated by ETW Provider Microsoft-Windows-DNSServer.

Internal Lookup Event Sample in JSON Format
{
  "SourceName":"Microsoft-Windows-DNSServer",
  "ProviderGuid":"{EB79061A-A566-4698-9119-3ED2807060E7}",
  "EventId":280,
  "Version":0,
  "ChannelID":16,
  "OpcodeValue":0,
  "TaskValue":1,
  "Keywords":"9223372105574252544",
  "EventTime":"2020-02-15T22:30:16.466802+00:00",
  "ExecutionProcessID":2064,
  "ExecutionThreadID":2220,
  "EventType":"INFO",
  "SeverityValue":2,
  "Severity":"INFO",
  "Domain":"NT AUTHORITY",
  "AccountName":"SYSTEM",
  "UserID":"S-1-5-18",
  "AccountType":"User",
  "Flags":"33152",
  "TCP":"1",
  "InterfaceIP":"::1",
  "Source":"::1",
  "RD":"1",
  "QNAME":"a.root-servers.net.",
  "QTYPE":"28",
  "Port":"58368",
  "XID":"23042",
  "BufferSize":"17",
  "PacketData":"0x5A02818000010001000000010000060001",
  "EventReceivedTime":"2020-02-15T22:30:17.473631+00:00",
  "SourceModuleName":"etw",
  "SourceModuleType":"im_etw"
}

Active Directory and Native DNS Auditing

DNS is automatically installed with Active Directory as the Global Catalog server for the forest and domain. There are a number of features available in Windows DNS Server, such as Native DNS Auditing.

However, systems prior to 2012 R2, or 2012 R2 without hotfix 2956577, do not have native DNS auditing capabilities included. When this is enabled, DNS changes can be audited by enabling AD Directory Services auditing. For more information, see the AD DS Auditing Step-by-Step Guide on Microsoft Docs.

Collecting File-based Microsoft DNS Debug Log Files

The DNS debug file is important since it contains detailed information on DNS queries and activity that is sent and received by the DNS server.

The following debug log sample displays a simple DNS query test from Windows DNS Server:

02/12/2020 9:49:38 PM 0820 PACKET  000001D5B29C4610 UDP Snd 172.31.12.204
43f0 R Q [8084 A  R  NOERROR] PTR    (1)1(1)0(1)0(3)127(7)in-addr(4)arpa(0)

Due to the amount of logs being generated from DNS debug logging, it is recommended to rotate logs and have them collected on a central server. Also, parsing the logs is suggested, in order to select which logs to enrich. Although DNS debug logging has some advantages, it does come with some additional caveats worth considering:

  • Due to the way Microsoft handles log rollover of DNS debug logs, if the log file is located on any drive other than the C: drive, the Windows DNS service may not recreate the debug log file after a rollover. See The disappearing Windows DNS debug log for an in-depth analysis of this issue.

  • The log information gleaned from DNS debug logging is inherently unstructured. Parsing is required to create usable event logs. If the Details option has been selected, regular expressions are needed to parse the event fields. Such configurations are complex and can be associated with additional performance overhead. For busy DNS servers, this would not be a recommended option. For more information see File-based DNS Debug Logging.

Performance Considerations

Depending on which of these logging methods you use, there are a few variables that can affect performance:

  • The DNS server’s hardware specifications.

  • The QPS (queries per second) rate.

  • The place where log enrichment or parsing is done. It can be done either locally or on a central logging server after the logs are received.

  • The type of logging taking place. It is recommended to enable DNS debug logging only temporarily and when needed.

All these factors play a role in influencing log performance.

What can NXLog do?

NXLog simplifies DNS log collection by providing a single software solution that incorporates the various technologies required to efficiently collect DNS related logs. NXLog offers the following methods for the previously mentioned DNS logging technologies.

Sysmon Log Collection

Use the im_msvistalog module and add the relevant Query in the configuration file. Find out more at Collecting DNS logs via Sysmon in the NXLog User Guide.

ETW (Event Tracing for Windows) Collection

The im_etw module is specifically designed to collect logs from ETW providers without much performance overhead. It acts both as a Controller and a Consumer (see Using NXLog as a Single Agent Solution to Collect ETW Logs).

Native Windows Event Log Collection

For DNS events that can be collected from the Windows Event Log, including Sysmon, use the im_msvistalog module and specify a query for the name of the channel and channel type. You can also add additional filtering to the query. See Windows Event Log.

File-based Log Collection from the Windows DNS Debug File

The NXLog User Guide details the steps to set up DNS debug logging including Parsing non-detailed logs with xm_msdns.

Conclusion

With this article, you have learned about the opportunities and challenges for the following modes of Windows DNS log collection: Sysmon, Event Tracing for Windows (ETW), Windows Event Log and Windows DNS debug file logging. You have also learned about possible DNS performance considerations and the NXLog solutions available for DNS log collection. With this knowledge of the various solutions available, you can avoid the pitfalls of deploying less efficient solutions or ending up with a deployment that is either logging too many or not enough DNS events.

DNS, for many reasons, is an important asset that must not be overlooked. It is known that attackers are abusing DNS, and it is through efficient and reliable DNS log collection that you can reap the benefits of this essential component of security monitoring. Our white paper, The Importance of DNS Logging in Enterprise Security expands on this theme.

Share
Related Posts