DNS logging best practices for enterprise security
Attackers use DNS to steal data, disrupt services, and carry out other malicious activities. Proactive DNS logging and continuous monitoring for security helps network administrators quickly detect and respond to these threats.
This whitepaper provides an overview of how DNS works, lists key information provided by DNS logs, and covers DNS logging best practices to improve enterprise security.
Understanding the Domain Name System
What is DNS?
The Domain Name System (DNS) provides a hierarchy of names for computers and services on the Internet or other networks. Its most noteworthy function is translating domain names, such as example.com, into IP addresses. DNS is required for the Internet to function, operates globally, and is massively distributed.
DNS servers usually accept messages on UDP port 53. The DNS protocol has two message types, queries, and replies; both use the same format. These messages are used to transfer resource records (RRs). A RR contains a name, a time-to-live (TTL), a class (normally IN), a type, and a value. For example, an A-type resource record specifies the IPv4 address associated with a domain. The domain name space is divided into DNS zones, and a server is considered authoritative if it has authority for a particular zone.
example.com. 3600 IN A 93.184.216.34
A DNS request involves the following parts (in the typical case):
-
Recursing resolver: The resolver receives the request from the client and makes further requests as necessary to obtain the authoritative record.
-
Root nameserver: A root nameserver can be queried to acquire more information about a particular top-level domain (TLD), such as com.
-
TLD nameserver: A TLD nameserver provides information about domains ending in a particular TLD.
-
Authoritative nameserver: Finally, an authoritative nameserver contains the actual DNS records for a particular DNS zone.
For example, consider a user attempting to connect to a website at example.com. Before attempting to connect, the system must acquire the IP address for that domain (an A record for IPv4). Here is the basic process for resolving an uncached record:
What are DNS Logs?
DNS logs are records generated by DNS servers that detail DNS queries, responses, and other DNS activities. In other words, every time a domain name is looked up or updated, a DNS log can record details like the timestamp, requesting IP, queried domain, and the server’s response. These logs provide a trail of all DNS interactions, which is invaluable for troubleshooting and security monitoring.
Top DNS security concerns: hijacking, tunneling, and cache poisoning
Security was not a significant consideration when the Domain Name System was designed. Now, malicious actors are using DNS for data theft, denial-of-service attacks, command-and-control, and other malicious activity. According to an EfficientIP report for 2023[1], the average cost of a DNS attack was $1,000,000 (18% higher than in 2022), and 90% of organizations were subject to a DNS attack.
Common types of DNS attacks include:
- DNS hijacking
-
An attacker can perform DNS hijacking by manipulating either user workstations or DNS servers. In the first case, malware is used to modify a workstation’s configured name servers, causing DNS requests to be sent to malicious servers instead. Alternatively, a DNS server may be compromised and configured to return incorrect replies. Either way, users are directed to an attacker’s site, allowing the attacker to steal user credentials (phishing), generate traffic (pharming), distribute malware, or publish a defaced website version.
In early 2019, FireEye identified a DNS hijacking campaign[2] of "unprecedented scale" that has had a "high degree of success" targeting victims across the globe. Soon after, the United States Cybersecurity and Infrastructure Security Agency released Emergency Directive 19-01, which outlines actions for mitigating the risk of DNS hijacking—including DNS auditing and monitoring. The recent Cloudflare incident[3] reveals that DNS hijacking attacks are still present in 2024, and there is no sign of degradation in the number of attacks. Quoting from the Cloudflare incident: "This caused immediate unreachability for the DNS resolver address from over 300 networks in 70 countries".
- DNS tunneling
-
DNS queries and responses can contain data payloads capable of transporting malware, stolen data, command-and-control information, or bidirectional protocols such as SSH. DNS traffic is often considered benign and not monitored. Therefore, DNS tunneling may be particularly interesting to an attacker as a covert communication channel.
Many types of client malware use DNS tunneling, including point-of-sale (PoS) malware like Blackcat[4], remote backdoors such as DNSMessenger[5] and DNSpionage[6], and botnets like Mirai[7]. There are also several open-source DNS tunnel implementation examples: dnscat2, iodine, and DNS2TCP.
- Various denial-of-service (DoS) attacks
-
Several different types of denial-of-service attacks are used against DNS servers, including NXDOMAIN, phantom domain, and domain lock-up attacks. In each case, the attacker aims to increase the server’s load to the point where it cannot answer legitimate requests.
The 2024 Q2 threat report from Cloudflare[8] outlines the scale of an ever-emerging trend of DoS attacks. In Q2 alone, Cloudflare mitigated 4 million attacks.
- DNS cache poisoning
-
Cache poisoning (or spoofing) occurs when a DNS resolver accepts an invalid resource record due to a vulnerability. An attacker may use a long time-to-live (TTL) value, during which time the data is retained in the resolver’s cache, and the resolver is considered "poisoned." The result is similar to DNS hijacking. DNS cache poisoning is mitigated by cryptographic signatures such as those implemented by the Domain Name System Security Extensions (DNSSEC), but DNSSEC is not yet universally deployed.
By proactively implementing DNS logging and monitoring audit logs and query traffic, IT personnel can more quickly identify and respond to a DNS attack, reducing its impact.
Why is DNS logging important?
DNS logs are a goldmine for cybersecurity analysis, as they can reveal malicious domains and attack patterns that other logs might not show. The following are key reasons for implementing DNS logging on any organization:
-
Early threat detection: DNS logs can reveal signs of malware communication (via unusual DNS queries or tunneling) and ongoing phishing or hijacking attempts, enabling faster incident response.
-
Incident investigation: An audit trail of DNS activity is crucial for forensic analysis after a security incident. For example, tracing which domain was queried by a compromised host.
-
Network visibility: Comprehensive DNS security monitoring helps uncover misconfigurations or abuse that other logs might miss. For example, unauthorized zone transfers or suspicious external DNS queries.
-
Compliance and policy enforcement: In some security frameworks, DNS security monitoring is encouraged or required. DNS logs help demonstrate adherence to policies like Zero Trust (by auditing DNS traffic) and can support compliance reporting.
Key data for DNS logging
There are many different DNS-related events that can be collected from a DNS server. The actual data available is dependent on the DNS server in use. The following table provides a non-exhaustive list of events that may be available for collection:
| Events | Description |
|---|---|
Dynamic updates |
If a DNS server is configured to allow DNS updates via Dynamic DNS (DDNS), these events should be available for auditing, including approval and denial of update requests. |
Zone transfers |
DNS databases can be replicated between DNS servers with zone transfers (the |
Rate limiting |
A DNS server may implement rate limiting to help mitigate various types of DNS attacks, including response rate limiting (RRL) and client rate limiting. When rate limiting takes effect, some queries are ignored (for RRL), or client requests cannot be resolved. |
DNS signing |
Events may be logged for DNS transaction signing protocols, including DNSSEC and TSIG. |
DNS query logs |
DNS servers often provide some form of DNS query logging, called analytical logging. These events detail all requests that are handled by the server. |
Resolution queries |
Events may also be available for recursive lookups performed to resolve client queries. These logs may provide destination IP addresses and other details associated with these queries. They could also be categorized with analytical logs and may be included as part of query logging. |
The following metadata may be available for query logging (analytical) events:
| Metadata | Description |
|---|---|
Client IP address |
Source addresses can help administrators identify devices that may be compromised on a local network, or malicious actors on the public Internet. |
Domain name queried |
The domain name in requests can be compared with a list of known malware domains. Esoteric domain names or repeated lookups may indicate the presence of malware. |
Record requested |
The types of records requested may indicate malicious activity. The TXT record, in particular, is often used for command-and-control or DNS tunneling. |
Request flags |
A DNS message is associated with several status flags, including whether the message is a request or response, whether the query is recursive, and DNSSEC status. |
DNS logging best practices
Enterprise environments often employ a variety of DNS server technologies, each with unique logging and security capabilities. Understanding the differences in how these platforms handle DNS logging and security is crucial for ensuring comprehensive DNS threat detection and incident response.
The following sections discuss logging configurations and security best practices for BIND 9 and Windows DNS Server.
BIND 9 DNS logging
There are two types of logging to consider for BIND 9 servers:
- BIND 9 logging
-
The standard BIND 9 logging system uses channels and categories. Each channel logs messages to a specified Syslog facility or file. All log messages are organized into categories, ranging from security related (such as update-security) to analytical (such as queries). Each category specifies one or more channels to use for log messages in that category. For more information and a full list of categories, see the BIND 9 Administrator Reference Manual.
BIND 9 query log sample01-May-2019 00:27:48.084 queries: info: client @0x7f82bc11d4e0 10.80.0.1#53995 (google.com): query: google.com IN A +E(0) (10.80.1.88) - Configuration monitoring
-
File integrity monitoring can also be implemented for the BIND 9 configuration files (for example, in the
/etc/bind/directory). This could be done as part of a system-wide DNS server auditing plan.
Learn more about DNS log collection on Linux. ]}
Windows DNS Server logging
There are four types of logging available for Windows DNS Server events.
- Analytical logging
-
DNS analytical logging uses the Event Tracing for Windows (ETW) system to provide high-performance logging of all DNS transactions. The logs can be collected from the
Microsoft-Windows-DNSServerprovider. This functionality is available beginning with Windows Server 2016 or as a hotfix for Server 2012 R2 and is the preferred method for collecting DNS Server transaction logs. DNS Server performance should not be affected except during very high query rates. For more information, see DNS Logging and Diagnostics on Microsoft Docs. For the Server 2012 R2 hotfix 2956577, see Update adds DNS query logging and change auditing to Windows DNS servers on Microsoft Support. There is also a series of blogs Secrets from the Deep - The DNS Analytical Log, that discusses DNS Analytical logging in detail. - Native DNS auditing
-
DNS auditing was also introduced alongside the analytical DNS logging changes—with Windows Server 2016 or 2012 R2 with hotfix 2956577—and is enabled by default. These audit logs are written to the
Microsoft-Windows-DNS-Server/Auditlog in the Windows Event Log. This is the preferred method for collecting DNS audit logs. - Debug logging
-
For Windows DNS Server versions before Windows Server 2012 R2 or 2012 R2 without hotfix 2956577, "debug logging" can record DNS queries and replies to a log file. This type of logging can affect DNS Server performance and is not intended to be enabled permanently. However, without support for analytical logging, DNS debug logging is the only way to collect DNS transaction information from Windows DNS Server. For more information about debug logging, see Collecting file-based Microsoft DNS debug log Files, or Using server debug logging options in the Microsoft documentation.
DNS Server debug log sample4/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) - Active Directory auditing
-
On systems without native DNS auditing (prior to 2012 R2, or 2012 R2 without hotfix 2956577), DNS changes can be audited by enabling AD Directory Services auditing. These events are written to the
Microsoft-Windows-Security-Auditinglog in the Windows Event Log. For more information, see the AD DS Auditing Step-by-Step Guide on Microsoft Docs and Who Moved the DNS Cheese? Auditing for AD-Integrated DNS Zone and Record Deletions on Microsoft Tech Community.
Learn more about DNS log collection on Windows.
NXLog Platform: how it enhances DNS monitoring and security
The best way to monitor DNS logs is to centralize them in a SIEM or log management platform for real-time analysis and alerting. This approach helps detect anomalies, identify threats, and maintain compliance efficiently.
NXLog Platform provides several unique features for collecting and processing DNS log data:
- Native ETW collection
-
NXLog Platform’s log collection technology includes a feature that can collect logs by implementing an ETW consumer. This allows collecting DNS analytical logs directly from ETW, without requiring events to be first written to disk.
- Parsing of DNS debug logs
-
NXLog Platform offers a built-in capability specifically designed for parsing log messages read from Windows DNS Server debug logging files.
- Multiple types of Windows Event Log collection
-
NXLog Platform provides a possibility to configure the collection of Windows Event Logs as a local agent or remotely. NXLog Agent can also use Windows Event Forwarding to collect Event Log data remotely while running on Linux. As a result, especially in heterogenous environments, there are a variety of options for collecting DNS Server audit logs or Active Directory audit logs from a Windows DNS Server. See the Windows Event Log chapter in the NXLog Platform Documentation for more details.
- File integrity monitoring
-
With the help of NXLog Platform, you can implement several different types of checksum-based and real-time file integrity monitoring. This can be used to monitor BIND 9 configuration files or any other system files that are related to DNS. For more information, see File Integrity Monitoring.
- Parsing and structured logging
-
NXLog Platform incorporates many different techniques for parsing event messages, and is designed around the concept of structured logging. Log data that is structured at the source can be retained as structured data, reducing the need for further processing. By handling and forwarding logs as structured data, events can be easily filtered, classified, and correlated as required for monitoring. For an introduction to NXLog’s handling of event data, see Event Records and Fields.
- Output integrations and monitoring
-
Once log data has been collected and parsed, the structured data can be forwarded for centralized log collection or to a log analytics solution for continuous monitoring and analysis. NXLog Platform offers a range of techniques to process, convert, and forward logs to other systems, allowing you to efficiently implement DNS security monitoring. NXLog supports a variety of SIEM[9] products and many MSSPs[10]. See the Integration section in the NXLog Platform documentation.
- Log data storage
-
NXLog Platform allows for efficient log storage by supporting multiple formats and destinations, including cloud storage and SIEM systems. It helps manage large volumes of DNS logs without sacrificing performance or scalability. Besides this, NXLog Platform also provides optimized on-premises, high-volume storage. It supports data collection and storage in any format with schemaless capabilities and achieves up to a 7x compression ratio with block-level compression and decompression in real time.
- Log search and query capabilities
-
NXLog Platform offers powerful search and filtering capabilities, allowing users to analyze and visualize log data in detail. It supports advanced searches with full log details for deep analysis.
For more information about using these features to implement DNS logging for specific DNS servers, see the DNS Monitoring chapter in the NXLog Platform documentation.
