Skip to main content
Do you build apps on Splunk or are a Splunk admin? If so, we want to hear from you. Help shape the future of Splunk and win a $35 gift card!
 
 
Splunk Lantern

DNS data

 

The Domain Name System (DNS) is the Internet's phone book/contact list, that translates (maps) a domain name into an IP address (A and AAAA records), which computers and devices use to communicate with each other. It is a distributed directory that also contains information about:

  • where emails should be delivered (MX records)
  • aliases to another hostname (CNAME records)
  • authoritative name servers (NS records)
  • associations of an IP address with a hostname (PTR records)
  • associations of arbitrary text with a domain (TXT records)

Inspecting DNS traffic for patterns, anomalies, and deviations between client devices and the DNS server(s) could reveal misconfigured DNS endpoints and the presence of security threats, such as using DNS for data exfiltration, denial of service attack, or remote access and control.

A DNS query (or request) identifies the domain or subdomain that was requested by the client. The DNS query can come from debug-level logs, although this method incurs considerable load on the servers and usually requires additional filtering, or from protocol-specific wire data sources like Splunk Stream, Bro/Zeek, or a network analysis solution like ExtraHop. The request message at a minimum should contain a timestamp, the fully qualified domain name (FQDN) of the requested resource, the type of record that the client is trying to resolve, and the source and destination IP addresses. DNS query composition or request patterns offer signs of malicious activity, such as suspicious or blacklisted domain name requests, unauthorized queries (spoofing), unusual query lengths (characteristics common to domain generation algorithms), off hours communication, an abnormal volume of DNS queries, and more.

A DNS response (or answer) identifies where the DNS query is resolving to. The DNS response can come from debug-level logs, although this method incurs considerable load on the servers and usually requires additional filtering, or from protocol-specific wire data sources like Splunk Stream, Bro/Zeek, or a network analysis solution like ExtraHop. The response message at a minimum should contain a timestamp, the fully qualified domain name (FQDN) of the requested resource, the type of record that the client is trying to resolve, and the source and destination IP addresses. DNS responses can offer signs of server misconfiguration (e.g., excessive failures) or malicious activity, such as brand infringement, malicious data being delivered to endpoints (identified by response length or size), resolution from unauthorized/suspicious IP addresses, and more.

In the Common Information Model, DNS data is typically mapped to the Network Resolution data model

Before looking at documentation for specific data sources, review the Splunk Docs information on general data ingestion: 

Common data sources

In addition, Splunk Stream lets you capture, filter, index, and analyze streams of network event data. For guidance on installing and configuring Splunk Stream, click here

Use cases for Splunk security products

Explore the Splunk Security Content site to see what detections you can run in Splunk Enterprise Security with network resolution data.