Microsoft dns server audit

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.

Collecting DNS query logs via Sysmon. Collecting from the relevant Windows Event Log channels. File-based DNS debug logging. 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. As of Sysmon version These events are generated when a process executes a DNS query, whether the result is successful or fails, cached or not.

This is advisable due to the noisy nature of this type of event. These types of additions can be:. 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 omit queries involving popular third-party applications like Google, Mozilla, as well as CDNs. 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.

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. Something big. The wheels are falling off the enterprise. People can't log in. Please try again later. No one can print. Many can't even get an IP address. Mission-critical apps are erroring out left and right.

The Helpdesk phone tree is lit up like a Christmas tree. People whose title starts with "C" are briskly walking the floor, asking questions. Desk and cell phones are ringing all over the place. Stomachs are turning. Throats are tightening up, especially for one person in particular but who? After some craziness and high-stress troubleshooting, it turns out someone deleted the main, internal corporate DNS zone. The reputation of IT took a hit but we're glad we had viable and tested AD backups and recovery plans do you?

If not, go here for some tips and get started! Now, people want answers. W hat happened? W ho did it? W hen did it happen? W hy did it happen? Sound familiar? Luckily, this was a fictional situation - but based on true stories. If you've followed this blog or gone Internet searching for auditing in Windows, you've likely seen the posts here and elsewhere about auditing AD for OU, GPO and other AD deletions, file and folder edits and possibly failed user logons.

DNS auditing is much less frequently covered. Even in my prior post, I didn't delve into DNS auditing. So let's get proactive and configure some settings to help ensure we are positioned to answer those "W" questions for DNS. Once the word gets out that 'we're watching AD changes like a hawk,' we often see a drastic reduction in something I refer to as 'casual administration.

No change-control requests or communications have gone out. This is just someone trying make things better without making any ripples, implementing seemingly minor changes. For more information about using tracelog. The following examples demonstrate how to use tracelog. You can stop tracing by issuing a stop command:. After stopping the trace, you can view the. The following example enables just the analytical channel and matches only the keywords to 0x7FFFF:.

A logging level of 5 is used in the previous examples. The following logging levels are available:. Only critical events are logged, for example process exit or termination. If no logging level is given by the user this level is used by default. Errors that can cause a service issue, but are acceptable or recoverable, for example the first attempt to contact a forwarder has failed.

Very high-level events are recorded in the event log. These might include one message for each major task performed by the service. Use this setting to begin an investigation when the location of the problem is in doubt, for example a scavenger thread was started.

All events are logged. This provides a complete log of the operation of the service. Use this level when the problem is traced to a particular category or a small set of categories. An audit event is logged each time server, zone, or resource record settings are changed. The following table summarizes DNS server audit events. The key will be removed after the rollover completion. The in-memory contents of all the zones on DNS server have been flushed to their respective files.

The DNS server has been prepared for demotion by removing references to it from all zones stored in the Active Directory. The information about the root hints on the DNS server has been written back to the persistent storage.