Логи dns сервера windows

To turn on DNS logging for a Microsoft Windows Server 2012 system which is functioning as a DNS server, take the following steps:

1. Hit Ctrl-Esc.
2. Click on Administrative Tools.
3. Select DNS.
4. Right-click on the DNS server and select Properties.
5. Click on the Debug Logging tab.

Check the box next to Log packets for debugging. Ensure that at least Incoming, UDP, Queries/Transfers, and the packet type of Request are checked. You may also want to log TCP packets, outgoing packets, and response packets as well to see the IP addresses returned by the DNS server for queries on names. Specify the directory path and file name for the log file. You can also specify a maximum size, if you wish. The default value is 500,000,000 bytes, i.e., 500 MB. If you only want to log DNS queries/responses from/to a particular system that is querying the DNS server, check the check box next to «Filter packets by IP addess» and then specify the IP address or addresses of systems for which you wish to record data on DNS queries and/or responses.

Click on OK.

If you don’t want to see any other entries in the log, e.g., for problems on the DNS server, you can click on the Event Logging tab and set the value for «Log the following events» to «No events» and click on OK.

If you wish to delete an existing log file that is in use and start a new one, right-click on the DNS server in the DNS Manager window, select All Tasks, then Stop. You can then move or delete the log file, right-click on the DNS server again, select All Tasks, then Start to restart logging.

When you check the log file, entries will appear such as the following:

The entries above show the system with IP address 192.168.0.42 queried the DNS server for the address of imap-mail.outlook.com. The Windows Server 2012 DNS server did not know the IP address, so it in turn queried a DNS forwarder system at 10.255.176.137. It received a response from the DNS forwarder and returned the response to the system at 192.168.0.42. The numbers you see for (9)imap-mail(7)outlook(3)com(0) reflect the number of characters in various parts of the address. E.g., imap-mail is 9 characters, outlook is 7 characters, and com is 3 characters.

A valuable and free tool which can aid you in examining Microsoft Windows DNS log files is Windows DNS Log Analyser.

If you wish to rotate the log file daily, you can use the instructions at Rotate the DNS server log file on a Windows server, though, since the at command is deprecated, you will need to use the schtasks command, instead of the at command. A command similar to the one shown below can be used to run the batch file at one minute after midnight every night:

I can check on the status of the avove scheduled task as shown below:

In the above example, the task was submitted on February 19, 2015.

Отладочное протоколирование и отслеживание активности DNS

Как правило, журнал событий DNS-сервер (DNS Server) используется для наблюдения за деятельностью DNS-сервера. В этом журнале записаны вес события DNS, а просмотреть его можно в узле Просмотр событий (Event View) консоли Управление компьютером (Computer Management). При поиске неисправностей DNS весьма полезной может оказаться настройка временного журнала для отслеживания определенных событий DNS. Не забывайте очищать события после окончания отладки.

Чтобы настроить отладку, выполните следующие действия:

1. В консоли Диспетчер DNS (DNS Manager) щелкните правой кнопкой нужный сервер и в контекстном меню выберите Свойства (Properties).

2. На вкладке Ведение журнала отладки (Debug Logging), установите флажок Записывать пакеты в журнал для отладки (Log Packets For Debugging). Затем установите флажки событий, временное наблюдение за которыми хотите вести.

3. В поле Имя и путь к файлу (File Path And Name) введите имя файла журнала, например, dns.log. По умолчанию журналы хранятся в папке %SystemRoot%\System32\Dns.

4. Щелкните ОК. Завершив отладку, отключите протоколирование, сбросив флажок Записывать пакеты в журнал для отладки (Log Packets For Debugging).

DNS Log Collection — Part 2

DNS Log Collection — Part 2

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 numerous ways of collecting DNS logs within the Windows environment:

Collecting DNS query logs via Sysmon

Collecting traces directly with Event Tracing for Windows (ETW) DNS Providers

Collecting from the relevant Windows Event Log channels

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

As of Sysmon version 10.0, there is 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 additions can be:

Exclusion rules to avoid logging reverse DNS lookups

Exclusion rules about which domains to exclude. If excluding certain top level domains (to reduce the amount of logs collected), be more specific 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.

Collecting from DNS ETW Providers

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

Table 1. List of ETW Providers

DNS Server Trace Provider

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.

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.

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 .

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:

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 as 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 above discussed DNS logging technologies.

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

There is a module, im_etw, that 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

There is a section in our User Guide detailing the steps involved for the setup of DNS debug logging including Parsing Non-Detailed Logs With xm_msdns.

Conclusion

With this article, you have learned about the opportunities and challenges with these 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 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.

NXLog Ltd. develops multi-platform log collection tools that support many different log sources, formats, transports, and integrations. The tools help administrators collect, parse, and forward logs so they can more easily respond to security issues, investigate operational problems, and analyze event data. NXLog distributes the free and open source NXLog Community Edition and offers additional features and support with the NXLog Enterprise Edition.

This document is provided for informational purposes only and is subject to change without notice. Trademarks are the properties of their respective owners.

ETW Provider Name	GUID