DomainTools App for Splunk and Splunk ES v5

Overview

Splunkbase: https://splunkbase.splunk.com/app/5226

The DomainTools App for Splunk provides direct access to DomainTools’ industry-leading threat intelligence data, predictive risk scoring, and critical tactical attributes to gain situational awareness of malicious domains inside Splunk.

What’s New

DomainTools App for Splunk 5.3 is the General Availability (GA) release of our app for Splunk, Splunk Enterprise, and Splunk Cloud.

5.3 Release Notes

New in 5.3

• Support for Newly Active Domains (NAD) and Newly Observed Domains (NOD) Threat Intelligence Feeds

Fixed in 5.3

• Public suffix list in Enrichment Summary
• Guided pivots failing for email addresses
• Newly observed domains race condition

5.2 Release Notes

New in 5.2

• Enrichment Explorer visualization and filters
• Enrichment dashboard panels: Top ASN; Top Registrars; Top SSL Expired Certificates; Top Nameservers; Top ISPs; Top IP

Updated in 5.2

• Additional fields in Enrichment Explorer summary view
• Error handling for Iris Investigate
• Allow multi-value inputs to dtirisenrich command

Fixed in 5.2

• dtwhoishistory documentation
• DNSDB error message specificity

5.1 Release Notes

Updated in 5.1

• Improved API usage reporting
• Improved information and responses around required API products

New in 5.1

• Support for new Iris fields

5.0 Release Notes

New in 5.0

• Send alerts sent to any SOAR platform with the new dt_alerts index
• New configurable Risk Score Increase alert from Iris Detect results.
• Log all domain enrichment values, and compare enrich values over time, using the new dt_enrich_history index.
• Track changes to Whois data with the dtwhoishistory custom search script
• Iris Investigate and Enrich API responses now include website_title, first_seen and server_type, as well as the SSL fields ssl.alt_names, ssl.duration, ssl.common_name, ssl.issuer_common_name, ssl.not_after, and ssl.not_before. These are available in the domain profile, enrichment explorer, and in Enrich and Investigate custom search commands.

Quick Start Guide

The following sections list the minimum steps to get started with Splunk in your environment. More detailed instructions are further below.

App Installation

Consult the Splunk Documentation for information about the Splunk platform.

The latest app is available on Splunkbase. Please ensure the prerequisites are met. For Splunk Cloud deployments, install the app directly from Splunkbase. For on-prem distributed environments, deploy the DomainTools App to both indexer and search head cluster members using the standard process for deploying apps and add-ons to clusters. Consult the App Installation section for more information.

Configure the Base Search

The base search is an SPL Query that allows users to define which log sources are to be monitored by the DomainTools App. It should output the required fields the DomainTools App uses to populate dashboards and enrich events. The app arrives with a pre-configured performance-optimized query. This query will work well in environments where data sources are Common Information Model (CIM) compliant.

To configure the base search, go to DT Settings→ Configure Log Source. The required fields are: url, src, dest, log_source, domain, and _time. Consult Configuring Base Search Using the Pre-Configured Query for more information.

Adding a DomainTools API Key

Enter your DomainTools API credentials in DT Settings → API Keys. DomainTools API credentials are available from your organization’s API administrator. Your Account Manager or DomainTools Enterprise Support (enterprisesupport@domaintools.com) can ensure your API key is appropriately provisioned.

Saving new API credentials will prompt you to enable default saved searches.

Enable Additional Saved Searches

Enable saved searches in DT Settings -> Configure Saved Searches. Consult Saved Search Names and Descriptions for a description of the searches available.

Enrich, Investigate, and Alert

Once initial setup is completed, the DomainTools app will query the DomainTools Iris Enrich API with domains found in the configured base search. Please allow 10-15 minutes after configuration for the enrichment process to start populating the dashboards.

New events will be enriched every 5 minutes by default. The Threat Intelligence panel is a good starting place to see what the enrichment data looks like. See the Key Capabilities section for more information on monitoring, alerting, and using DomainTools data as part of other workflows.

If the Threat Intelligence Dashboard remains empty after the initial 10-15 minute wait period, you may wish to enable logging, or see the Troubleshooting & Known Issues section for more information.

Deployment Guide

Deployment Overview

The following sections outline some background architecture and deployment information. Appendix A contains additional information on app components, including configuration files, stanzas and fields, KV store, macros, and saved searches.

High-level topology of both Splunk and DomainTools resources

The Saved Searches configuration file (savedsearches.conf) defines the processes for enrichment and the Queue Builder for the Iris Enrich KV store. In the Queue Builder process, raw logs in the Splunk Indexes are queried from the Web data model as defined by the DomainTools base search configuration (dt_basesearch).

This process includes checking to see if the domain already exists when comparing to existing Iris Enrich data, as that would indicate if the domain has already been enriched. If not, the new domain is queued for enrichment. Each domain is stored with the enriched data in the KV store.

Domain Enrichment Process between DomainTools and Splunk Indexes

Prerequisites

The DomainTools App works best with Splunk Enterprise Security (ES). With Version 5 of the DomainTools App, users of Splunk (without Enterprise Security) can receive a wide range of customized alerts.

DomainTools App Bundle

The latest app is available on Splunkbase.

API Keys

A DomainTools API username and API key is required to complete the app setup. DomainTools provides access to obtain API credentials by creating an account for the primary point of contact in your organization. If you wish to evaluate the app and need to obtain new API keys, contact us via email at enterprisesupport@domaintools.com. If you are an existing DomainTools customer, to ensure your DomainTools API key is appropriately provisioned, please contact your account manager.

For complete App functionality, your DomainTools API key should include access to the Iris Enrich API and Iris Investigate API. Limited app functionality is available for users without Iris Enrich API and Iris Investigate API access. Notably, management of Iris Investigate monitors, importing Iris Investigate and Detect terms, and ingesting Iris Investigate and Detect discoveries into Splunk will not be available.

Firewall Rules

Ensure you can reach https://api.domaintools.com/ from the Splunk server. If required, update firewall rules to allow access to this endpoint for the app to be functional. If you are on a managed infrastructure and cannot connect to the DomainTools endpoint, please contact enterprisesupport@domaintools.com.

Splunk Credentials to Install App

A Splunk account with admin access is required to install and configure the app. After installation, most user functions should be available with less privileged accounts.

You may also need command-line access (e.g., SSH) to perform some deployment and diagnostics functions, especially if deploying in a clustered environment.

Splunk Permissions to Operate App

Ensure that the list_storage_passwords privilege is added to the user operating the app. The admin role may need to be used to access the password storage within Splunk.

Users within the DomainTools App must have read privileges to all the components of the app. If a user expects to add, update, or append values in any of the internal stores (ex. monitoring lists, or Iris Detect terms), their user profiles must include write privileges to the KV stores involved. For the list of KV stores and descriptions, please see the App Components Appendix.

Validating the App in Non-Production Environments

If you use a staging environment or development environment to test new Splunk apps, ensure the same data sources you plan to use in production are also available to the Splunk search heads in the test environment.

App Installation

The DomainTools App is designed to be installed on a search head or within a search head cluster. It has been tested with the recommended Splunk deployment model for apps in a clustered environment, including distributed configuration.

We encourage customers to follow Splunk guidelines to ensure a successful deployment. Please review the Splunk docs on app install and config in a clustered environment, including the page on Distributed Search.

DomainTools provides support for apps deployed in this standard configuration model. Although it is possible to use an alternative method for deploying apps, such as a configuration management tool, those methods create scenarios that are unique to your environment. As such, DomainTools can provide only limited support for those deployments.

Uninstalling Prior Versions

If you are currently running a 3.x or 4.x version of the DomainTools app, we recommend uninstalling the older version first and performing a fresh installation when migrating to version 5.

For best results, use the Splunk web UI to uninstall any previous versions of the DomainTools App or TA (if using an older version). Use command-line access to completely remove any remaining DomainTools specific folders.

# from deployer
/opt/splunk/etc/apps/ $ rm -rf DomainTools-App-for-Splunk/

Splunk Cloud Deployment

The DomainTools app is vetted and available for Splunk Cloud. Please follow the instructions to Install apps on your Splunk Cloud Platform deployment to add or update it on your Splunk Cloud installation. The latest version of the DomainTools App can be found on Splunkbase (app ID 5226).

Once the app is installed, proceed to the Application Setup section.

Upgrade note for Splunk Cloud users: Users using the self-service app installation might run into issues installing the components of the app needed on indexers. The installation proceeds normally, but attempts to run dtdomainextract return an error. This may be due to Splunk self-service only installing apps on search heads. Please see the associated known issue and workarounds.

On-Premise Installation

For on-premise installation, first follow the instructions outlined here for Indexer Clusters.

Installation Steps

1. Obtain the latest version of the DomainTools App from Splunkbase.
2. Identify the server with the deployer role.
3. Obtain admin and console access to the server, then ssh into the deployer server.
4. If performing a fresh Install, skip this step: Remove the existing app bundle from the deployer.

# from deployer
/opt/splunk/etc/apps/ $ rm -rf DomainTools-App-for-Splunk/

1. scp tar file to deployer /tmp directory.

# from local
scp -i ~/.ssh/**.pem ./domaintools-App-for-splunk_xxx.tgz user@hostname:/tmp

1. Extract the app to the directory.

/tmp $ sudo tar -xvf domaintools-App-for-splunk_xxx.tgz -C /opt/splunk/etc/apps/
$ sudo chown -R splunk:splunk /opt/splunk/etc/apps/DomainTools-App-for-Splunk/

1. Restart the app.

$ sudo /opt/splunk/bin/splunk restart

1. If performing a fresh Install, skip this step: In the deployer, remove the app from /opt/splunk/etc/shcluster/apps

/opt/splunk/etc/shcluster/apps/ $ sudo rm -rf DomainTools-App-for-Splunk/
/opt/splunk/etc/shcluster/apps/ $ sudo cp -r /opt/splunk/etc/apps/DomainTools-App-for-Splunk/ ./

1. Ensure correct permissions are used.

$ sudo chown -R splunk:splunk

1. Then copy the new one from app/dir.

/opt/splunk/etc/shcluster/apps/DomainTools-App-for-Splunk/

1. Ensure to run the deploy command as a splunk user.

sudo su - splunk

1. Copy out the app to search clusters.
   1. The IP is the IP for one of the searchheads.
   2. Use admin credentials if it asks for them.
   3. Target is the private IP of any one of the search heads in the cluster.
   4. The admin password is the default (SPLUNK-\<instanceid>) - instance-id of the deployer.

/opt/splunk/bin/splunk apply shcluster-bundle -target https://172.16.1.xxx:8089 -auth <user>:<password>

1. Verify the app is deployed by SSH into one of the searchheads. Run a status check on the search head. See below for an example output.

[splunk@ip-172-16-01-xxx ~]$ /opt/splunk/bin/splunk show shcluster-status
Captain:
    dynamic_captain : 1
    elected_captain : Wed Nov 20 15:56:03 2023
    id : D6327B1F-6898-477D-928E-xxx
    initialized_flag : 1
    label : ip-172-16-01-xxx
    mgmt_uri : https://hostname:8089
    min_peers_joined_flag : 1
    rolling_restart_flag : 0
    service_ready_flag : 1

Members:
 ip-172-16-01-xxx
    label : ip-172-16-01-xxx
    mgmt_uri : https://hostname:8089
    mgmt_uri_alias : https://172.16.1.xxx:8089
    status : Up

1. Log in to your splunk instance and verify you can see the DomainTools app installed:

DomainTools App shown on a successful installation

Application Setup

This section covers the base items needed to get your DomainTools App for Splunk instance up and running.

Configuring Base Search Using the Pre-Configured Query

The app arrives with a pre-configured performance-optimized query. This query will work well in environments where data sources are Common Information Model (CIM) compliant.

First, identify relevant CIM-compliant data sources for ingestion. It may be data sources already configured to use web proxy events, for example. If your base search involves working with relevant data sources that are not CIM-compliant, please go to the Configuring Base Search Using the Custom SPL section.

To use the pre-configured query:

1. Go to DT Settings → Configure Log Source page.
2. Confirm the details of the pre-configured Splunk search query.

The app natively supports logs with multivalue URLs contained in a single event entry, commonly seen in Proofpoint logs. Users who previously may have used mvexpand url to workaround this issue can remove that command to have the urls more accurately reported as a single event.

A regex-based dtdomainextract2 macro is available for high-throughput environments and can significantly increase performance of the url-to-domain conversion with a slight trade-off in accuracy. Notably, some wildcard and exception tlds (e.g. \*.np, \!city.kawasaki.jp) can be misidentified as a domain. Note that mvexpand url would still be needed with dtdomainextract2 in environments processing multivalue URLs. The updated base search would look like this:

tstats summariesonly=true count FROM datamodel=Web BY Web.url Web.src Web.dest source \_time | rename Web.url AS url | rename Web.src AS src | rename Web.dest AS dest | rename source AS log\_source | mvexpand url | \`dtdomainextract2\` | eval domain=lower(domain) | fields url src dest log\_source domain \_time

1. If needed, customize the pre-configured base search to ensure the required fields are available.
2. Select the Save button.
3. Select the Timeframe for the Base Search.

Base search requirements and recommendations:

• domain and _time are required output fields to operate the app.
• We recommend adding the optional fields Source, Destination, and Log Source in your base search. They provide additional contextual information on the events. The app will also not error out in the absence of these fields.

Performance considerations:

• The Web data model must have acceleration turned on.
• If acceleration is not turned on, yet data has been mapped to the CIM, you can modify the base search to use summariesonly=false with some potential degradation in performance.

If you already have the domains extracted out in the CIM, you can remove the dtdomainextract function from your base search. This will further improve performance.

Configure Log Source

DomainTools extracts domain names from your data input sources that contain domain names - including proxy logs, DNS logs, SMTP server logs, and more.

To define a Base Search that is used across the app:

1. Go to DT Settings → Configure Log Source.
2. Add the Base Search. Please go to the following sections in this User Guide to read more: Configuring Base Search Using the Pre-Configured Query; Configuring Base Search Using the Custom SPL.

The app automatically validates the base search by retrieving events from your environment. It displays the following fields: URL, Domain Name, _time, and the optional fields Source, Destination, and Log Source.

Managing API Connectivity

Adding and Testing API Connectivity

1. Navigate to DT Settings → API Keys.
2. Enter your DomainTools API Username and API Key
3. Optionally enter a Farsight API key, if enabled. It enables the Farsight Flexible and Standard pDNS search options, as well as the in-line DNSDB enrichment.
4. Click the Test Connection button to validate the connection(s).
5. Once validated, Update to save the settings. A successful test will show the API licenses associated with the API username along with additional information.

Adding Proxy Configuration

1. Configure proxy configuration and proxy credential support in the same API Key section.
2. Select Enable Proxy.
3. Add the Proxy Server and Proxy Port.
4. If required, select Enable Proxy Authentication, and add the proxy credentials on the Proxy Username and Proxy Password fields.

Adding SSL

1. Configure SSL details in the same API Key section.
2. Select Enable Custom SSL Certificate and add the path in the Custom SSL Certificate Path field.

Configure Saved Searches

Saved Searches automate some operational tasks within Splunk. The full list of saved searches can be found in the Saved Search Names and Descriptions table in Appendix A.

Upon clicking Test Connection after entering your API key above, if the "Queue Builder for Iris Enrich KV Store" saved search is disabled, you will be prompted to enable the default set of saved searches. Selecting enable will turn on the set of seven minimum required saved searches for the Core App functionality noted in the saved searches table.

To enable Iris Investigate and Detect capabilities or alerting in Splunk Enterprise Security, you will need to enable additional saved searches outlined in the table.

To manage saved searches, select the DT Settings menu in the app, and select Configure Saved Searches to load the list of saved searches used by the DomainTools app.

To enable a Saved Search, select Edit, and select Edit Schedule.

Confirm the schedule, and enable the Saved Search by selecting Save.

Further Configuration

The above sections describe the minimum steps required to get started. The following sections go into additional detail to help configure the application to provide the most value in your environment.

Configuring the Base Search Using the Custom SPL

Configuring Base Search using your own custom Search Processing Language query (SPL) may be necessary if data is not yet CIM compliant, or input data sources are from ingested data from several different sources.

First, identify relevant data sources for ingestion. It may contain URLs or hostnames, in addition to domain names. IP addresses are not supported for processing with this app.

The DomainTools solution provides data on domain names, not IPs, subdomains, or full URLs. IPs sent to the Iris APIs will not return useful data and consume rate-limited resources. Querying a URL will result in inconsistent results. The default base search converts URLs to apex domains for the enrichment.

To configure using custom SPL:

1. Craft the Splunk search query that efficiently finds events from your preferred data source(s).
2. It is not necessary (or effective) to write regular expressions or other parsing rules to extract domains in logs filled with hostnames or URLs or de-duplicate logs. This task is handled by DomainTools queue builder search jobs.
3. We recommend using tstats. It is also used in the pre-configured base search for optimization.
   1. If the default tstats base search is not used, there is a known issue in clustered SH environments for both Splunk 7.x and Splunk 8.x; consult the Workaround and Known Issue section and Splunk documentation.
4. Add the query as the base search via DT Settings → Configure Log Source page.
5. Add the query in the Base Search input field and select Save.

Your custom SPL must meet these criteria:

• If your custom search does not begin tstats you must add search to ensure proper functionality once it is merged into the DomainTools scheduled searches.
• Must not start with a pipe | character.
• Ensure the result contains a field named domain or use rename function.
• The search must efficiently return results from the last 10 minutes of events. Ideally in a few seconds, but no longer than two or three minutes.

Example:

search index=mycustomindex | rename url AS domain

The query should be performant in your environment. At a minimum, the query should return ten minutes of events in no more than two minutes of search execution time, with minimal impact on your search head or search head cluster.

Pros and Cons Between Pre-Configured and Custom SPL for Base Search

Ensure to select the correct base search method for your environment before proceeding with the installation. The following table lists the tradeoffs between the two methods.

Base Search	Pros	Cons
Pre-Configured	No post-install customization or configuration required, other than the API username and key initial app setup. Finds domain names in every CIM-compliant data source from the Web data model. Fast for most environments.	Requires CIM compliant data sources that use the Web data model with hostnames in the Web.url field. DomainTools Threat Hunting Dashboard will be empty if the base search can’t find domains. Must have acceleration turned on for the Web data model.
Custom SPL	Does not require your data source to be CIM compliant. Can be optimized to your environment and data sources.	May cause performance problems if the search is not manually optimized. May require additional tuning after installation, making this option unsuitable for rigorous change management cycles. Must return the hostname or domain name in a field explicitly named domain.

Add Custom Fields for Notable Events

This section only applies to Splunk Enterprise Security (ES) Notable Events, which are events generated by DomainTools detection rules. Users of Splunk (without ES) can generate notifications with the dt_alerts index.

To ensure that Notable Events provide context for triaging, we have extended some of the key enrichment fields already available from DomainTools into Splunk Enterprise Security.

Add the following fields and labels during the initial setup within your Enterprise Security module:

Enrichment Field Name	Label
dt_num_of_times_enriched	Enrichment Count
dt_looyn_date	Last Seen
log_source	Log Source
dt_age	Domain Age
en_threat_profile_type	DomainTools Threat Profile
dt_is_active	Domain Status
en_risk_score	Risk Score
domain	Domain

Once created, the notable events will automatically display these fields. There is no programmatic way to provision these fields during app deployment. For detailed steps to add custom fields, please refer to this Splunk documentation.

Enable Mass Enrichment

We recommend leaving the current settings as a default. Visit DT Settings → Configure Enrichment and Alerting to change these settings.

The Queue Wait Time is how often the app enriches Domain information, and defaults to 5 minutes.. Decreasing the frequency can be helpful to reduce API usage or if the enrichment is taking longer than 5 minutes to run on a higher volume Splunk cluster.

The Cache Settings is the cache DomainTools maintains to reduce API query usage. Disable or reduce the cache retention times (for example, when monitoring volatile domains) in Cache Settings:

• DomainTools maintains a cache to reduce API query usage. A user may wish to disable or reduce the cache retention period times when monitoring volatile domains.
• Enable Cache: Enabled by default to optimize API consumption. Disable the cache to monitor for changes < 1 day old. (CAUTION: this can result in high API consumption.)
• Add the Cache Retention Period: Sets how long domain enrichment should live in the cache before being re-queried. 30 days is the default.

Enable Enrichment History

The DomainTools App supports enrichment history with the custom dt_enrich_history index. This index stores all Enrich values for all domains. When a domain is re-enriched, this index records the new values. The index can be used to compare changes in values across whois info, IPs, SSL fields, risk scores, and other indicators. Indexes including dt_enrich_history can be created and configured in Configure DT Indexes.

DomainTools Thresholds

This section defines thresholds used in creating dashboard KPIs and alerts (if enabled) throughout the app.

• Risk Score Threshold (default value of 75): DomainTools Risk Score used when defining a "suspicious" domain in dashboard KPIs and creating alerts (if enabled) throughout the app. See the Domain Risk Scoring section for more information on DomainTools Risk Score.
• Young Domain Age (default value of 7 days)
• Newly registered domains are often an indicator of interest. Specify the age threshold in days for a domain to be included in dashboards and optionally alerting.
• Guided Pivot Threshold (default value of 500)
• When a small set of domains share an attribute (e.g. registrar), that can often be pivoted on in order to find other similar domains of interest. DomainTools tracks how many domains share each attribute and can highlight it for further investigation when the number of domains is beneath the set threshold.
• High Risk Threshold (default value of 90)
• Used by the Risky Observed Domains graph on the Threat Intelligence Dashboard. This sets the minimum DomainTools Risk Score threshold for flagging a domain as High Risk for this graph. Higher risk scores indicate riskier domains.
• Medium Risk Threshold (default value of 70)
• Used by the Risky Observed Domains graph on the Threat Intelligence Dashboard. This sets the minimum DomainTools Risk Score threshold for flagging a domain as Medium Risk for this graph. Higher risk scores indicate riskier domains.

Alert Settings for Splunk Enterprise Security (ES)

To generate notable events and enable alerts with Splunk Enterprise Security:

1. Select the Create Notable Event checkbox under the Alert Settings section.
2. Select or deselect relevant alert criteria in the Monitor Domains, Monitor Young Domain, Monitor Risk Score Increase, and Iris Detect panels. When multiple criteria are selected, they narrow down the alert generation rule. In other words, they form a logical ‘AND’ narrowing.
3. Only Monitor Domains in the DomainTools Monitoring list (default): an alert will only fire against domains that have been added to the monitoring list.
4. Exceeds Domains Risk Score Threshold: Only alert if the domain exceeds the risk threshold defined above.
5. Exceeds Domain Threat Profile Score Threshold: Only alert if the domain exceeds the threat profile threshold defined above.
6. Ignore Iris Detect Domains in DomainTools Monitoring list: ignores anything in the monitoring list where the Source equals "Iris Detect".
7. Monitor DomainTools Iris Tags in Tag Monitoring List: The app will monitor any domains that are tagged in DomainTools Iris investigation platform. Selecting this option will alert you when new domains are observed in your environment that match any Iris tags that have been specified on the Monitoring Tags page.
8. Select the Urgency Tag to associate with the Notable Event: applies the specified urgency level within Splunk Enterprise Security’s Incident Review panel.
9. Monitor young domains: creates a notable event whenever a young domain (lower than the young domain threshold) is observed. Optionally restricted to new domains on the monitoring list. This is useful in conjunction with Iris Investigate monitors that can keep track of newly registered domains. Similarly, select the separate Urgency Tag to associate with the "young domains" Notable Event will apply the specified urgency level within Splunk Enterprise Security’s Incident Review panel.

Alert Settings in Splunk (without Enterprise Security)

Alerting is supported in Splunk (without Enterprise Security) with indexes. Consult the Configure DT Indexes section for more information.

Set Up Monitoring for Domains with Iris Tags

If you use the Iris investigation platform for domain investigations, you can monitor for domains that are associated with tags your team has applied within Iris, optionally alerting when a tagged domain is observed in Splunk.

The Manage Monitored Tags page with examples of Tags being monitored

To monitor for Iris-tagged domains in Splunk, visit Monitoring → Manage Monitored Tags to add tags to be added to the proactive monitoring list. Once tags are added, domains that share the same tag in Iris are monitored in Splunk.

Adding Domains to the Allowlist

Add your list of trusted domains, within your security operations workflow, to help reduce noise and false positives when creating alerts based on domain monitoring.

To add or remove domains in the Allowlist, visit DT Settings → Manage Allowlist and select the allowlist behavior:

1. Exclude from alerts and dashboards (default): Domains in the allowlist won’t be counted towards dashboard visuals, or alerts, if configured
2. Exclude from alerts: Domains won’t be alerted on (applies to users of Splunk Enterprise Security only), but will still appear in dashboard visuals
3. Exclude from dashboards: Domains won’t appear in dashboard visuals but will still appear in alerts (applies to users of Splunk Enterprise Security only).
4. Exclude from all enrichment: Fully ignores the domain in all enrichment, alerts, and visuals
5. Do Nothing: Allowlist is informational-only. Domains remain enriched, alerted upon, and appear in dashboard visuals. This setting can be helpful for temporary use when debugging.

Successfully added domains will show in the Allowlist along with Domain Name, Last Updated Date Time, Last Updated By, Added Date Time, Added By, and Action.

Configure Iris Detect

The Iris Detect Splunk integration allows you to triage new domains matching Iris Detect Monitors within Splunk, and synchronize the Iris Detect Watch List with the Splunk Monitoring list to watch for new domain activity within your environment.

To configure Iris Detect within Splunk, first ensure your API key is provisioned for Iris Detect. Visit DT Settings → API Keys, select Test Connection, and it will list Iris Detect APIs.

The DomainTools App requires the following APIs for base product functionality:

• iris-enrich
• iris-investigate
• iris-detect-monitors: required for read-only access to the configured monitored Iris Detect terms within Splunk.
• iris-detect-new-domains: required for read-only access to the new domains matching monitored terms within Splunk.
• iris-detect-watched-domains: read-only access required to access the list of domains marked as “watched” in Iris Detect and pull updates to that list. Optionally, synchronize those domains with the Splunk Monitoring List.

Optionally enable:

• iris-detect-manage-watchlist-domains: useful for triaging domains, adding to the Iris Detect Watchlist to track changes to domain infrastructure over time.
• iris-detect-escalate-domains: used to enable additions to the blocklist and submissions to Google Safe Browsing.

Iris Detect functionality will work without the optional permissions but a user will receive an error if they attempt to watch, block, escalate or ignore a domain within the Iris Detect Results panel.

To configure Iris Detect monitors on the Iris Detect page (Monitoring → Iris Detect), first make sure that the DomainTools - Import Iris Detect Monitors and DomainTools - Import Iris Detect Results saved searches are enabled (DT Settings → Configure Saved Searches).

An Iris Detect Monitored Term (also referred to as “terms”) refers to the series of characters being searched against new domain observations. A term is the basis for an Iris Detect Monitor. It is frequently used as a company or brand name. Adding and editing monitors can currently only be done within the Iris Detect UI.

Import new Iris Detect Monitored Terms

Refresh the list of monitored terms in one of two ways:

1. Select the Refresh Now button on the Iris Detect Monitored Terms page to import any new terms.
2. Under DT Settings → Configured Saved Searches assign an update frequency on the DomainTools - Import Iris Detect Monitors saved search to sync daily or weekly.

Reading the Iris Detect Monitored Terms Table

In the Monitoring → Iris Detect Monitored Terms pane:

• Term: The term itself as it appears in Iris Detect. Adding and editing monitored terms can currently only be done within the Iris Detect UI.
• Monitor Last Updated In Splunk: The date as to when the monitor was refreshed, either manually or via the Daily or Weekly detections. Click “Refresh Now” to force a manual refresh.
• Ingest Daily Detections in Splunk: Select the term(s) to ingest Iris Detect-monitored domains into Splunk so they show up on the Monitoring → Iris Detect Dashboard page.

Import new Iris Detect Results

The Iris Detect Dashboard contains the list of new or changed domains matching the enabled monitored terms. The Iris Detect API allows up to hourly synchronization.

Synchronize Iris Detect results in one of two ways:

1. Select the Refresh Iris Detect Results button on the Iris Detect Dashboard to manually import new domains.
2. Under DT Settings → Configured Saved Searches assign an update frequency on the DomainTools - Import Iris Detect Results. The default schedule is every 2 hours. Note that the DomainTools Iris Detect API is limited to an hourly refresh frequency.

Reading the Iris Detect Results

The Monitored Term filter at the top of the page displays the results for all monitors or a selected monitor. The Time Range Filter filters for updates within a specified time period. The Type filter tab at the top of the results page allows you to select between New domains matching the enabled search terms, or Watched domains (domains that have been added to your account’s Iris Detect Watch List) matching the selected terms, or the list of Ignored domains in case of erroneously triaging a domain to the wrong queue.

When new domains are discovered for the Enabled Monitors Terms, they are added in the results table with these fields. Click on a field heading to sort:

• Domain: The full domain name including TLD.
• TLD: The top-level domain for the selected domain.
• Country Code: The country code where the domain is registered.
• ISP: the Internet Service Provider associated with the IP address used by the domain.
• Registrar Name: The name of the registrar.
• Risk Score: The DomainTools Risk Score. See the Domain Risk Scoring section for more information on Risk Score.
• Risk Score Status: The risk score status indicates whether the scoring is provisional or full. Newly discovered domains will have only initial proximity or phishing scores and the score is designated as provisional. After 24-36 hours, a full risk score is calculated and adds malware and spam scoring values. At that point, the score becomes “full”.
• First Seen/Lifecycle First Seen: the date and time that DomainTools learned that a domain is likely active (or reactivated after going inactive).
• Last Updated: The date Iris Detect last observed any changes to the DNS or Whois attributes associated with the domain.
• IP Address: The numerical address that the domain name resolves to.
• Name Server: The server that translates a domain name into its numerical IP address.
• Mail Server: The server that handles emails sent to the domain.

The Act Column in Iris Detect Results helps triage discovered domains with the following actions:

• Add to the Iris Detect Watchlist: Adds the listed domain to the Iris Detect Watchlist, which provides alerts on changes to these domains if hosting infrastructure or webpage changes are seen. This gives you the ability to track evolving threat campaigns, classify, and identify which domains are most likely to do harm. Such domains are candidates for escalation. The Iris Detect Watchlist can optionally be synchronized with the Splunk Monitoring list.
• Add to the Detect Blocklist API: Marks the domain for blocking. Useful for internal network defense infrastructure. The blocking designation is transmitted through the Iris Detect APIs.
• Escalate to Google Phishing Protection: Domains can be sent to Google’s Phishing Protection team. If Google agrees the domain is malicious, it will be blocked in Chrome browsers globally. This list is also picked up by Safari and Firefox.
• Add to the Splunk Monitoring List: Adds the listed domain to the Monitored Domains List within the DomainTools Splunk App. This can enable detection and alerting if the domain is seen within your monitored log sources.
• Ignore This Domain: If a domain is obviously a false positive, Ignoring the domain removes it from the “new” list on the next refresh. Watched Domains can be ignored if they are no longer of interest for change tracking.
• View Domain Profile: Load the Domain Profile page within Splunk, pulling up the Iris Investigate results for the listed domain.
• Farsight pDNS Search: Run a Farsight pDNS Standard Search (if provisioned) in DNSDB for RRNames containing the listed domain. This is useful for finding any active subdomains as well as seeing the dates when a domain has been active based on DNS traffic observed on Farsight’s Security Information Exchange (SIE).

See the Iris Detect User Guide for more information.

Alerting on Iris Detect Monitors

The DomainTools App for Splunk supports additional monitoring and alerting against domains in the Monitoring List. See Set Up Monitoring for Domains for more information. Synchronize the Iris Detect Watch List with the Monitored Domains List under Monitoring → Managed Monitored Domains.

Selecting the option for Automatic Sync will add and remove watched domains on an automatic schedule based on the Sync Iris Detect Watchlist saved search. The default schedule is every day. Sync Splunk Monitoring List and Iris Detect Watch List will perform the sync on a one-time basis.

This option is also available under the Monitoring → Manage Monitored Domains page, where Sync with Iris Detect Monitoring List means that Automatic Sync will be enabled (both pages mirror the same setting).

Consult the Set up Monitoring section for more details and to set up alerting against monitored domains.

Configure DT Indexes

Both the dt_alerts and dt_enrich_history are built from Splunk indexes, and must be created. To create a Splunk index, consult the Splunk documentation on Creating Event Indexes.

Using Key App Capabilities

Iris Enrich - Threat Intelligence Dashboard

The Threat Intelligence Dashboard is designed to help organizations gain quick situational awareness of the risk presented by domain names on their network. The dashboard also helps guide teams to effectively leverage DomainTools data in their SOC workflows, with drill-downs that expose the underlying events.

Keep the dashboard and current with the latest information open on an always-on tab or dedicated display, turning on the Auto Refresh. Panels will refresh individually at 5-minute intervals.

Interacting With and Reading the Dashboard Panels

The Threat Profile dashboard panels provide insights based on Splunk Timecharts (consult Reading the Splunk Time Charts for more information).

• Unique Domains Observed: Number of unique domains observed in your network currently being monitored within the DomainTools cache for the selected time period, compared to the previous time period.
• Dangerous Domains: Uses a combination of the suspicious Risk Score threshold being exceeded, threat profile threshold being exceeded, and domain age being younger than the set threshold to determine a domain’s likelihood to be dangerous. Thresholds can be configured on the Enrichment & Alerting settings page. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Suspicious Domains: Number of Domains with a DomainTools risk score higher than the configured Suspicious Risk Score threshold on the Enrichment & Alerting settings page. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Young Domains: Number of Domains observed which were recently created, based on the number of days set on the Enrichment & Alerting settings page. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Events Enriched: Displays the total number of Events associated with Domains enriched by DomainTools during the selected time period.

The following panels provide additional information either as a graph or paginated results:

• Risky Observed Domains
• See the Domain Risk Scoring section for more information on Risk Score.
• Risk Scores are classified by default as either 100 (Known Malicious), 90-99 (High), 70-89 (Medium), or 69 and below (Low).
• Risk score thresholds may be configured under DT Settings → Configure Enrichment & Alerting, Risky Observed Domains Threshold Settings.
• Click on a data point to view the underlying events.
• Filtering by Risk level: All would show the default view used in earlier versions of the application.
• Newly Observed Domains
• The paginated results show newly observed domains, risk score, the time and date that it has been first and last observed, and the number of events associated with that domain observed during the selected time period.
• Threat Map
• Maps the number of suspicious domains observed during the selected time period, based on the GeoLocation of their Hosting IPs or Registrant Country (use the pull-down to select). The Risk Score threshold for a suspicious event is configurable on the Enrichment & Alerting settings page.
• Threat Portfolio
• Plots the number of events associated with domains broken out by Threat Profile category over the selected time range. Click on a category in the legend to display the associated events from the filtered time period. See the Domain Risk Scoring section for more details.
• Top 10 Tags from Cache
• Lists the top Iris Investigate Tags in use and the number of associated domains observed with that tag in the selected time period.

Interacting with the Dashboards

To drill down on the metric, click on each panel. This will show the total instances of all domain detections within the time filter applied to the dashboard. Results can also be filtered over a specified period of time. Hover over each panel to Open in Search, Export, go Fullscreen, or Refresh.

Interacting with the Threat Map

Hover over each country to find the unique domain count with a geo-located IP associated with that country. It is possible to reset to the original position and zoom.

Reading the Splunk Timecharts

The indicators on the top of the Threat Intelligence Dashboard and Monitoring Dashboard utilize Splunk’s "Single Value Visualization" feature to provide a trending context to some of the dashboard metrics. The value displayed matches the filter time (e.g. "Last 15 Minutes") selected, compared to the previous filter time (e.g. previous 15 minutes). These are "bins" in Splunk nomenclature. Regardless of whether the trend is up or down, a green indicator represents a relatively desirable trend (fewer Suspicious Domains, for instance), while a red indicator represents a relatively undesirable trend.

Iris Enrich - Domain Monitoring Dashboard

The Domain Monitoring dashboard, available from the Monitoring menu, enables the monitoring of suspicious domains within Splunk. The dashboard highlights monitoring KPIs for comprehensive reporting.

Interacting With and Reading the Dashboard Panels

Hover for the tooltips about the panel sections and select the data points to interact. Use these results for further investigations in DomainTools, or to triage and analyze the results in ES Incident Review by selecting the Alerts Generated panel.

Keep the dashboard and current with the latest information open on an always-on tab or dedicated display, turning on the Auto Refresh. Panels will refresh individually at 5-minute intervals.

Details on the individual panels are below:

• Detected Domains: Shows the number of domains detected within your network that are in the Monitored Domains List (configurable under Monitoring → Manage Monitored Domains). This includes any domains in the Allowlist. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Tagged Suspicious Domains: Suspicious Domains with an Iris Investigate Tag that are being monitored in the DomainTools Tags List, excluding any in the Allowlist. Tags, the Risk Score threshold is configurable under DT Settings → Configure Enrichment & Alerting. The Monitored Tags and Allowlists are configurable under the Monitoring menu. Tags can be added to domains within the DomainTools Iris Investigate UI. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Iris Detect Domains Observed: Domains Discovered by DomainTools Iris Detect and observed in your network events. This includes any domains in the Allowlist. Add and configure Monitors in Iris Detect, then select how Splunk uses them using the Monitoring → Iris Detect page. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Iris Investigate Domains Observed: Domains discovered by DomainTools Iris Investigate and observed in your network events. This includes any domains in the Allowlist. The displayed value indicates the number of domains observed in the selected time period compared to the previous time period.
• Total Alerts Generated: Shows the number of alerts that were triggered within the selected time period, compared to the previous. Alerts are created based on rules set on the DT Settings → Configure Enrichment & Alerting page and can be triaged within Splunk Enterprise Security Incident Review or by clicking on the number displayed.
• Total Events Monitored: Shows the number of events associated with the domains detected within your network that are in the DomainTools Monitoring List (configurable under Monitoring → Manage Monitored Domains). This includes any domains in the Allowlist. The displayed value indicates the number of events observed in the selected time period compared to the previous time period.
• Currently Monitoring: Total number of Domains currently being monitored. This panel is not impacted by the dashboard time filter. Add domain monitors via Monitoring → Manage Monitored Domains.
• Suspicious Domains over Time: Shows a timeline of the suspicious domains observed over the filtered time period. Suspicious domains have a Risk Score at or above the suspicious Risk Threshold defined in the Enrichment & Alerting settings page .
• Suspicious Domains Attribute Table: Lists the domains observed with a Risk Score at or above the Risk Threshold defined in the DT Settings → Configure Enrichment & Alerting page.
• Threat Map: Plots the number of unique domains based on their GeoLocation, Hosting IPs and Registrant Country associated with Detected Domains in your cache.
• DomainTools Alerts over Time: Shows a timeline of the unique alerts observed over the filtered time period. Alerts are created based on rules set on the DT Settings → Configure Enrichment & Alerting page.
• DomainTools Top Notable Events: Displays the activity and status of DomainTools alerting rules within your environment. These can be configured on the DT Settings → Configure Enrichment & Alerting page.

Iris Investigate - Domain Profile

The Domain Profile page provides a search function for ad hoc lookups of a single domain. The results provide a single pane of glass view of the domain, a contextual panel, tags, connected infrastructure information, contact details, and related events. Hover over the tooltips about the panel sections and click on the data points to interact. Use these results for further investigations in DomainTools.

Tip: Users can import lists of domains of interest into Splunk. All domains are imported along with their DomainTools Risk Profile for convenient triaging and subsequent monitoring. See the Importing Domains from an Iris Investigation section for more information.

To access and interact with the Domain Profile, visit Investigate → Domain Profile and add the domain in SLD.TLD format.

Domain Risk Scoring

Consult the Domain Risk Score User Guide.

Tags

The tags associated with the domain. Consult the Set Up Monitoring for Domains with Iris Tags section for more information.

Connected Infrastructure

Connected Infrastructure information (such as Mail Servers, IP addresses, SPF information, Name Servers, SSL information, Registrar/Registry) are obtained from DomainTools datasets.

Guided Pivoting and Discovery

Ad hoc investigations with guided pivots will surface potential investigation points.

Hover over the gray gear icon wheel to show the number of connected domains. If the gray icon is clickable, a blue Pivot button appears. Select this button to import the list of domains associated with this data point.

In cases where the connected domains are larger than the Guided Pivot threshold configured, the gray gear icon is not made into a guided pivot and is not clickable. The Guided Pivot threshold is configurable under DT Settings → Configure Enrichment & Alerting.

Contact Information

The contact information (Admin, Technical, Billing and Registrant) are gleaned from the DomainTools Whois dataset and surfaced on the Splunk app.

Recent Events

While investigating a domain, users can see any related and recent events from their configured log sources across different timeframes.

Domain intelligence from such investigations is automatically added to the cache for future references.

Importing Domains from an Iris Investigation

Import the list of domains from Iris into Splunk using the Export and Import functionalities.

1. In the Iris Investigation platform, go to the Navigation Menu (3 lines) → under Search → select Import/Export.
2. The subsequent dialog contains the Search Hash to export.
3. From the DomainTools Splunk App, go to Investigate → Import from Iris Investigate, and paste the copied Search Hash in the input field.
4. After submitting, if the Search Hash has no results in the Iris Pivot Engine, there are no domains to import and Splunk will show the message "No results found". The imported domains will be shown as below:

Farsight DNSDB pDNS Searching

Investigate current and historical domain infrastructure with Passive DNS (pDNS) using Farsight’s DNSDB Standard or Flexible search (API Key Required). Please contact enterprisesupport@domaintools.com for provisioning.

DNSDB is a database that stores and indexes both the passive DNS data available via DomainTools Security Information Exchange (SIE), as well as the authoritative DNS data that various zone operators make available.

Enter your Farsight DNSDB API key on the API Keys page.

Farsight pDNS Standard Search (found under the Investigate menu) is a powerful search tool used to uncover related infrastructure against a specific Domain or IP.

Input parameters are as follows:

• Time Range: the time range that should be queried for DNS observations.
• Resource Record Type (RRType): Optionally specify which Record Resource Type (RRType) to search for. RRtype declares the type of mapping that a Resource Record Set establishes. ANY will match all RRTypes except DNSSEC RRTypes and is the default. ANY-DNSSEC will match only the DNSSEC RRTypes. Or enter a custom RRtype in the following text field.
• IP or Domain Name: Specify an IP (IPv4/IPv6), CIDR netblock, hostname (FQDN), or domain to search for. Left- or right-side wildcards are supported. Internationalized Domain Names (IDNs) will be automatically converted to Punycode.

Farsight pDNS Flexible Search (found under the Investigate menu) extends the Farsight DNSDB API with additional search capabilities. It provides more powerful searching capabilities (e.g. wildcards, regular expressions) than Standard Search, but the results will not be as complete as those from Standard Search.

Input parameters are as follows:

• Time Range: the time range that should be queried for DNS observations.
• Query: Flexible Searches support strings and patterns. This field will use the selected Syntax under "Match type". For an expanded explanation please visit the user guide.
• Query Type: Specifies which field of the DNS resource record to search. RDATA is the record data value or the "right hand side" of a DNS resource record set. Its content can be IP address(es), domain names, or other content (such as text), depending on the RRtype. An RRname is the owner name of the RRset, or the "left hand side" of a DNS resource record set. It will always be a domain name.
• Match Type: Which Flexible Search syntax to use. Regex is more common and represents the egrep-like Farsight Compatible Regular Expression ("FCRE") syntax, and Globbing is simpler wildcard pattern matching. See the user guide for examples.
• Resource Record Type (RRType): Optionally specify which Resource Record Type (RRType) to search for. RRtype declares the type of mapping that a Resource Record Set establishes. ANY will match all RRTypes except DNSSEC RRTypes and is the default. ANY-DNSSEC will match only the DNSSEC RRTypes.

Investigate Domains Within Incident Review

Investigate any domain or URL listed in an Incident Review event with a couple clicks. (Note that URLs are shortened to a domain lookup). Expand the arrow on the incident review event, and next to a domain or URL, expand the arrow under Action.

Threat Intelligence Feeds: Newly Active Domains (NAD) and Newly Observed Domains (NOD)

Create a NAD/NOD Index

To create a NAD and/or NOD Splunk index, consult the Splunk documentation on Creating Event Indexes. In Settings -> Indexes -> New Index, create the NAD index as dtfeednad and/or the NOD index is dtfeednod.

Information about NAD and NOD is available in our Real-Time Threat Intelligence Feeds documentation.

Real-time Access and Searching

In the Search section, construct queries with either dtfeednad or dtfeednod.

The following parameters are available, and their behavior is documented in Real-time Threat Intelligence Feeds:

Parameter	Type	Valid Values	Description	Example	Required
after	integer	Negative integer, range 60-432,000	The start of the query window in seconds, relative to the current time, inclusive.	after=-60	Required if sessionID not provided.
after	string	ISO 8601 datetime string in UTC form	The start of the query window, inclusive.	after=2024-10-16T10:20:00Z	Required if sessionID not provided.
sessionID	string	1-64 alphanumeric characters ([a-zA-Z0-9-]+)	A string that serves as a unique identifier for the session, used for resuming data retrieval from the last point.	sessionID=mySIEM	Required if after not provided.
domain	string	Domain character set restricted by the DNS specification (Letters, Digits, Hyphens). International characters should be specified in punycode. A trailing dot is acceptable. Multiple domain filters are accepted in a request.	Filter for an exact domain or a substring contained within a domain by prefixing or suffixing your substring with * (at the start and/or end of the value). Multiple parameters are supported. The URL-encoded version of * (%2A) may be required.	domain=*apple*&domain=*microsoft*	No
top	integer	Positive integer, 1-1,000,000,000.	Limits the number of results in the response payload. Primarily for testing.	top=10	No

Schedule NAD/NOD Results

Create scheduled NAD or NOD activities in DT Settings -> Configure Saved Searches.

Enrichment Explorer

The Enrichment Explorer section available from the main menu provides a user-facing front of the DomainTools enrichment dataset or cache. This allows the user to browse and search from the enrichment cache based on filters.

Selecting the Monitor field to add or remove a domain from your monitoring list. Clicking on the "Allowlist" button will add or remove a domain from your allow list.

If the information for a domain observable appears to be dated (i.e., enrichment date from the past, or a set of domains from an Iris Investigate Search Hash import), the user can explicitly refresh their KV store with the latest Domain Intelligence, or reduce the Cache Retention Period under DT Settings → Configure Enrichment & Alerting.

Enrichment Dashboard

The Enrichment Dashboard visualizes and lists information in a set of panels for frequently encountered domain attributes. Use each panel to search, set the time period of the search, and click through to Splunk search for more information.

• Top Registrars
• Top Nameservers
• Top ISPs
• Top IP Addresses
• Top ASNs
• Top Expired SSL Certificate

Alerts for Splunk (without ES) with the dt_alerts Index

The dt_alerts index enables alerting in Splunk (without Enterprise Security). Create the dt_alerts index, and utilize it in the Search Page.

Extending DomainTools Commands

You can use the packaged commands from the DomainTools app to enrich domains and execute custom Splunk searches. Appendix A lists all the commands available with the DomainTools application. The more frequently-used commands are defined below.

dtdomainextract

Extracts a domain out of a URL field, based on the tldextract library. Note that the DomainTools APIs expect a domain name as an input. Passing subdomains or URLs to the APIs will result in inconsistent data enrichment, so we recommend using dtdomainextract command or the dtdomainextract2 macro.

Syntax

| dtdomainextract field_in=string field_out=string include_subdomains=bool feature=string

Parameters

• field_in: Field to extract domains from (required).
• field_out: Field to output domain in (required).
• include_subdomain: Boolean flag to include subdomains. Default is false.
• feature: Feature in the app where this was called. Default is adhoc.

Example

| dtdomainextract field\_in=url field\_out=domain

dtirisenrich

An eventing command that queries Iris Enrich against up to 100 comma-separated domains at a time. The Iris Enrich API endpoint is optimized for fast volumes and high-volume lookups. Add inline_results to keep event data inline.

Syntax

| dtirisenrich domain=string inline_results=string feature=string

Parameters

• domain: Apex-level domain name and TLD (required).
• inline_results: Enrich events inline. Default is false.
• feature: Feature in the app where this was called. Default is adhoc.

Example

| makeresults | eval domain="domaintools.com" | dtirisenrich domain=domain inline_results=true

dtirisinvestigate

A generating command that queries Iris Investigate with up to 100 comma-separated domains at a time, or pivot on a domain-related attribute to further your investigation. The Iris Investigate API is ideally suited for investigation and orchestration use cases at human scale.

Syntax

| dtirisinvestigate domain=string pivot_type=string pivot_value=string feature=string no_cache=bool

Parameters:

• domain: optional
• pivot_type: Data type of pivot value.
• pivot_value: A non-domain data point to resolve to a domain(s).
• no_cache: Override switch to ensure a new Investigate API query is executed.
• feature: Feature in the app where this was called. Default is adhoc.

Example:

| dtirisinvestigate pivot_type="ip" pivot_value="x.x.x.x"

dtformatinvestigate

Formats the JSON returned by an Iris Investigate query into a row with component names. Use the output parameter to specify the section of the response to format.

Syntax

| dtformatinvestigate output=string feature=string

Parameters

• output: Name of the section to flatten (summary, admin_contact, technical_contact, billing_contact, ip, mx, ns, risk, ssl, email, tags). Required.
• feature: Feature in the app where this was called. Default is adhoc.

Example

| dtirisinvestigate domain="domaintools.com" | dtformatinvestigate output=risk

dtdsndb

Queries DNSDB for Passive DNS information against a given IP, Domain, Hostname, or Subnet.

Syntax

| dtdnsdb target=ip/hostname type=rdata/rrset/raw rrtype=a/aaa/cname/etc time_first_before=time time_first_after=time time_last_before=time time_last_after=time target_type=auto/ip/name bailiwick=bailiwick

Parameters

• target: The data point used to search for historical DNS observations. Required.
• type: Indicates the type of search to perform with the target value. Required.
• rrtype: Enables the ability to filter on a specific resource record type. Required.
• bailiwick: The “bailiwick” of an RRset in DNSDB observed via passive DNS replication is the closest enclosing zone delegated to a nameserver which served the RRset.
• time_first_before: Unix Timestamp. Provide results before the defined timestamp for when the DNS record was first observed.
• time_first_after: Unix Timestamp. Provide results after the defined timestamp for when the DNS record was first observed.
• time_last_before: Unix Timestamp. Provide results before the defined timestamp for when the DNS record was last observed.
• time_last_after: Unix Timestamp. Provide results after the defined timestamp for when the DNS record was last observed.

Example

| dtdnsdb target=domaintools.com target_type=domain type=rdata rrtype=CNAME

dtdnsdbflex

Performs a DNSDB Passive DNS Flexible Search.

Syntax

| dtdnsdbflex query_type=<rdata|rrnames> match_type=<glob|regex> query=<glob or regex pattern> rrtype=**A/mx/cname/etc bailiwick=bailiwick time_first_before=time time_first_after=time time_last_before=time time_last_after=time

Parameters

• query_type: Indicates the type of search to perform with the query value. Required.
• match_type: Used to specify the type of flexible search to perform. Required.
• query: The data point pattern used to search for historical DNS observations. Required.
• rrtype: Enables the ability to filter on a specific resource record type. Required.
• bailiwick: The “bailiwick” of an RRset in DNSDB observed via passive DNS replication is the closest enclosing zone delegated to a nameserver which served the RRset.
• time_first_before: Unix Timestamp. Provide results before the defined timestamp for when the DNS record was first observed.
• time_first_after: Unix Timestamp. Provide results after the defined timestamp for when the DNS record was first observed.
• time_last_before: Unix Timestamp. Provide results before the defined timestamp for when the DNS record was last observed.
• time_last_after: Unix Timestamp. Provide results after the defined timestamp for when the DNS record was last observed.

Example

| dtdnsdbflex query_type=rdata match_type=regex query="[0-9]{5,6}-ledger\.com\.$"

dtdnsdblimit

Returns the dnsdb api query limit, number of queries remaining, as well as the time the remaining queries will reset.

Syntax

| dtdnsdblimit

Parameters

No parameters

Example

| dtdnsdblimit

dtdnsdbenrich

Enrich the Splunk events returned by a given SPL_QUERY with Passive DNS information reported by Farsight DNSDB, part of DomainTools.

Syntax

| dtndsdbenrich field_in=string field_type=domain/ip/raw lookup_type=rrset/rrdata max_count=int time_first_before=time time_first_after=time time_last_before=time time_last_after=time rrtype=<any/A/ns/...> bailiwick=string include_subdomains=bool

Parameters

• field_in: Field to extract targets from. Required.
• field_type: Target type. Domain, IP, or Raw. Required.
• lookup_type: Specify either rrdata or rrset. Required.
• max_count: Max number of dnsdb results to return in Splunk UI per row.
• rrtype: Enables the ability to filter on a specific resource record type.
• bailiwick: The “bailiwick” of an RRset in DNSDB observed via passive DNS replication is the closest enclosing zone delegated to a nameserver which served the RRset.
• time_first_before: Unix Timestamp. Provide results before the defined timestamp for when the DNS record was first observed.
• time_first_after: Unix Timestamp. Provide results after the defined timestamp for when the DNS record was first observed.
• time_last_before: Unix Timestamp. Provide results before the defined timestamp for when the DNS record was last observed.
• time_last_after: Unix Timestamp. Provide results after the defined timestamp for when the DNS record was last observed.
• include_subdomains: Boolean value that will preface each lookup with “*.” (e.g. *.inputdomain.com) when true. Default it false.
• feature: Feature in the app where this was called. Default is adhoc.

Example

| dtdnsdbenrich field_in=domain field_type=domain lookup_type=rrset rrtype=A include_subdomains=true time_first_after=1593070040 | eval dnsdb_time_first=strftime(dnsdb_time_first, "%Y-%m-%d %H:%M:%S"), dnsdb_time_last=strftime(dnsdb_time_last, "%Y-%m-%d %H:%M:%S")

dtwhoishistory

Performs a whois history search on a given domain using the Whois History API endpoint.

Syntax

| dtwhoishistory domain=string mode=string

Parameters

• domain: Domain name and TLD. Required.
• mode: Mode in which to express the results. Either list, check_existence, or count.
• sort: Sort results based on date. Either date_desc or date_asc.
• feature: Feature in the app where this was called. Default is adhoc.

Example

| dtwhoishistory domain=domain mode="check_existence"

Additional Examples

The following are a few example SPL commands that leverage DomainTools data for reference:

Enrich 300 events from the main index

index=main | dtdomainextract field_in=url field_out=domain | table url domain | dedup domain | head 300 | dtirisenrich domain=domain

The dtirisenrich command will batch API requests into groups of 100. The head 300 filter in the example limits the example search to three API queries in case this is copy/pasted directly. It should be able to handle as many domains as you want to input if you want to remove that filter.

Use | makeresults | eval domain="domaintools.com" instead of pulling events if you have a set list of domains to enrich.

Use Iris Investigate for a domain

| dtirisinvestigate domain=domaintools.com

Use pivot_type with an ip address

| dtirisinvestigate pivot_type="ip" pivot_value="199.30.228.112"

Look through the DomainTools cache to see when a URL was first and last observed on your network

| lookup dt_stats _key AS domain OUTPUT dt_fooyn_timestamp AS first_observed, dt_looyn_timestamp AS last_observed

Or to provide full context against a datasource and format the date strings

| tstats summariesonly=true count FROM datamodel=Web BY _time Web.url Web.src Web.dest source
|` `rename Web.url AS url | rename Web.src AS src | rename Web.dest AS dest | rename source AS log_source
| dtdomainextract field_in=url field_out=domain
| eval domain=lower(domain)
| fields url src dest log_source domain _time
| table _time domain url
| lookup dt_stats _key AS domain OUTPUT dt_fooyn_timestamp AS first_observed, dt_looyn_timestamp AS last_observed
| eval first_observed=strftime(first_observed, "%Y-%m-%d %H:%M:%S"), last_observed=strftime(last_observed, "%Y-%m-%d %H:%M:%S")

View the latest Domains, URLs and risk scores from the DomainTools cache:

| lookup dt_iris_enrich_data en_domain_name AS domain OUTPUT en_risk_score AS "risk score"

Again, with more context against a data source:

| tstats summariesonly=true count FROM datamodel=Web BY _time Web.url Web.src Web.dest source
| rename Web.url AS url | rename Web.src AS src | rename Web.dest AS dest | rename source AS log_source
| dtdomainextract field_in=url field_out=domain | eval domain=lower(domain) | fields url src dest log_source domain _time | table _time domain url
| lookup dt_iris_enrich_data en_domain_name AS domain OUTPUT en_risk_score AS "risk score"

Show domains associated with an IP using DNSDB

… | dtdnsdbenrich field_in=dest_ip field_type=ip max_count=5

Find recent subdomains under a domain using DNSDB and format the returned unix date fields to be human-readable

... | dtdnsdbenrich field_in=domain field_type=domain lookup_type=rrset rrtype=A include_subdomains=true time_first_after=1593070040 | eval dnsdb_time_first=strftime(dnsdb_time_first, "%Y-%m-%d %H:%M:%S"), dnsdb_time_last=strftime(dnsdb_time_last, "%Y-%m-%d %H:%M:%S")

Enrich 30 events from the main index with Iris Enrich and DNSDB Passive DNS information

index=main
| dtdomainextract field_in=url field_out=domain
| table url domain
| dedup domain
| head 30
| dtirisenrich domain=domain
| dtdnsdbenrich field_in=en_domain_name field_type=domain max_count=5

Set up a recurring search in Splunk using an Iris Investigate search hash

| dtirisinvestigate pivot_type=search_hash pivot_value=U2FsdGVkX196b8iZhQooljda3uKOGzja/B4HY8cyDzz0EOGg5/8CQutnvoxO3KXfkrAjiCVk//8P5JW3aot3V48dDF65m6tMLls9oKnq0kdjmTA6wb1j1yYFUESK6K3/WbVpftsVtr15qmrcXM0xWrIYlpl01b6SBCheVhm+g5MrXLqQ/0bTkihLTtO9OMO5tuzHS8ik/8wkN7THUN/PEN9Sj9E5cFpRb8qojjGAktWj7DLuSbPTfD+hv/qoZTS3 no_cache=true
| eval json = replace(_raw, "^[^\{]+", "")
| spath input=json path=first_seen.value
| rename first_seen.value as first_seen
| table first_seen domain
| collect index=summary_index_icloud

• This example search is using the Iris Investigate command to look up domains containing the substring “icloud” that have been first seen within the last 7 days.
• The output is parsed and put into a table before being collected in a summary index as well. The search could then be saved as a report within Splunk and set up for weekly recurring updates.
• For further documentation on scheduling a report, please see the Reporting Manual in Splunk documentation.

Set up a recurring search in Splunk using a DNSDB regex flexible search

| eval thirty_days_ago=relative_time(now(), "-30d@d")
| eval thirty_days_ago_unix=thirty_days_ago
| dtdnsdbflex query_type=rrnames match_type=regex query="-icloud\.(net|com)\.$" rrtype=A time_last_after=thirty_days_ago_unix

• This example search is using the DNSDB Flexible Search command to look up domains that match a specific pattern.
• For this example, whenever the search executes it will look for domains matching the regex pattern last observed in DomainTools’ DNS sensor network over the past 30 days.
• Note: Creating a relative Unix timestamp and storing it in a variable establishes a relative time fence. This ensures the time window will shift appropriately with the schedule, such as in a report.
• For further documentation on scheduling a report, please see the Reporting Manual in Splunk documentation.
• For further documentation on how to use regular expressions with our DNSDB flexible search command visit the regular expression user guide.

Troubleshooting & Known Issues

Enabling Logging

Logging is disabled by default. To enable logging to help with diagnostics, go to DT Settings → Diagnostic Panel and select Enable Diagnostic Panel. Allow a few minutes for logs to populate, then refresh the page.

Checking the Status of Saved Searches

Having one or more required saved searches disabled is a common customer issue that could manifest itself as incomplete app functionality.

To check on the status of saved searches:

1. Select the DT Settings menu within the app.
2. Select Configure Saved Searches to load the list of saved searches used by the DomainTools app

Compare the scheduled time on the resulting set of reports against the table of Saved Search Names and Descriptions in Appendix A to ensure the required core app saved searches, as well as the additional ones if required for Iris Investigate or Alerting in Splunk Enterprise Security are enabled.

Appendix A: App Components

The Splunk app is provisioned with the following main components.

Table: Main Configuration Files, Stanzas, and Fields

These configuration files are relevant to utilizing the app and DomainTools datasets.

Note: The configuration files are relevant for this version only. The configuration files, stanzas and fields will be different in other versions.

Conf File	Stanza Tag	Fields	Description
app.conf	package	id	Add details for the Splunk App.
	install	is_configured
	ui	is_visible, label
	launcher	author, description, version
commands.conf	dtaccountinfo	chunked, filename	These are helper commands for the app. The most commonly used ones outside the app are described in greater detail in Extending DomainTools Commands Outside the App, as well as the in-app documentation. chunked is used to indicate the search command supports Splnuk’s “chunked” custom protocol, used by all of these stanzas filename Indicates the location of the Python .py filenames for these commands.
	dtimportirisdetectmonitors	chunked, filename
	dtimportirisdetectresults	chunked, filename
	dtirisdetectescalate	chunked, filename
	dtirisdetectchangestate	chunked, filename
	dtsyncirisdetectwatchlist	chunked, filename
	dtirisinvestigate	chunked, filename
	dtirisenrich	chunked, filename
	dtformatenrich	chunked, filename
	dtformatinvestigate	chunked, filename
	dtexpirecache	chunked, filename
	dtdomainextract	type, filename, streaming, local, passauth, chunked	The template to modify the DomainTools domainextract function to use Splunk SDK SCP1, should the latest SDK face throughput issues.
	dtdnsdb	filename, retainevents, supports_multivalues, streaming, overrides_timeorder, passauth	Queries DNSDB for Passive DNS information against a given IP, Domain, Hostname, or Subnet.
	dtdnsdbflex	filename, retainevents, supports_multivalues, streaming, overrides_timeorder, passauth	Performs a DNSDB Passive DNS Flexible Search.
	dtdnsdbenrich	chunked, filename	Enrich the Splunk events returned by a given SPL_QUERY with Passive DNS information reported by Farsight DNSDB, part of DomainTools.
	validateip	filename, retainevents, supports_multivalues, streaming, overrides_timeorder
	dtdnsdblimit	filename, retainevents, supports_multivalues, streaming, overrides_timeorder, passauth	Returns the dnsdb api query limit, number of queries remaining, as well as the time the remaining queries will reset.
	flushcache	filename, retainevents, supports_multivalues, streaming, overrides_timeorder, passauth
searchbnf.conf	dtaccountinfo-command	syntax, shortdesc, usage, comment1, example1	The syntax (shorter name), description and if the usage is public.
	dtirisinvestigate-command	syntax, shortdesc, usage, comment1, example1, comment2, example2, related
	dtirisdetectmonitors-command	syntax, shortdesc, usage, comment1, example1
	dtsyncirisdetectwatchlist-command	syntax, shortdesc, usage, comment1, example1
	dtirisenrich-command	syntax, shortdesc, usage, comment1, example1, comment2, example2, related
	dtformatinvestigate-command	syntax, shortdesc, usage, comment1, example1, related
	dtformatenrich-command	syntax, shortdesc, usage
	dtdomainextract-command	syntax, shortdesc, usage, comment1, example1, comment2, example2
	dtexpirecache-command	syntax, shortdesc, usage, comment1, example1
	dtdnsdb-command	syntax, description, shortdesc, example1, example2, example3, usage
	dtdnsdbflex-command	syntax, shortdesc, example1, example2, example3, usage
	dtdnsdbenrich-command	syntax, description, shortdesc, example1, example2, example3, usage
	dtdnsdblimit-command	syntax, description, shortdesc, example1, usage
server.conf	shclustering	conf_replication_include.domaintools	Default value is set to true.
transforms.conf	dt_iris_enrich_queue	external_type, collection, fields_list, case_sensitive_match	These are KV store fields. Please see the table in this section KV Store/Collection Name with Descriptions and Fields for the array of fields_list for each stanza.
	dt_iris_enrich_data	external_type, collection, fields_list, case_sensitive_match
	dt_stats	external_type, collection, fields_list, case_sensitive_match
	dt_allowlist	external_type, collection, fields_list
	dt_monitoring_list	external_type, collection, fields_list
	dt_tags_list	external_type, collection, fields_list
	dt_iris_detect_monitors	external_type, collection, fields_list
	dt_iris_detect_results	external_type, collection, fields_list
	dt_iris_investigate	external_type, collection, fields_list
	dt_public_suffix_list	filename, match_type, max_matches	Needed for macro dtdomainextract2
domaintools.conf	domaintools	proxy_enabled	Use a proxy when connecting to the DomainTools API. To enable, set to 1.
		proxy_server	The proxy server address to use.
		proxy_port	The proxy server port to use.
		ssl_enabled	Use SSL when connecting to the DomainTools API. To enable, set to 1.
		custom_certificate_enabled	Use a custom SSL certificate for the SSL connection. To enable set to 1.
		custom_certificate_path	The path to the custom SSL certificate.
		guided_pivot_threshold	The Guided Pivot Threshold on the Domain Profile page. Set a lower value to narrow investigations. 500 is the default and recommended value.
		bulk_enrichment_batch_size	Number of domains batched in an API call. Set the value from 1 to 100.
		optimize_enrichment_searches	This setting enables quicker correlation of cached data of known domains from the Enrichment table. Requires additional disk space. Disabling will reduce disk space consumption but will slow down searches. Set 1 to enable.
		populate_scores	Checks for whether or not to use the Risk Score over lower tiered scores. Turned off (set to 0) by default.
		logging_on	Toggles whether or not to write logs to file.
macros.conf	See the table in this section Key Macros for Enrichment.
savedsearches.conf	See the table in this section Saved Search Names and Descriptions.
collections.conf	See the table in this section KV Store/Collection Name with Descriptions and Fields.
distsearch.conf	replicationWhitelist	domainextract	Path to domainextract custom search command to be copied to indexers
		lib	Path to python libs to be copied to indexers
workflow_actions.conf		dt_iris_lookup	Lookup domain using Iris Investigate
		dt_domain_profile	Lookup domain using Domain Profile
		dt_dnsdb	Lookup passive dns using Farsight pDNS Standard Search

Table: KV Store/Collection Names and Fields

KV Store/ Collection Name	Fields
dt_iris_enrich_queue	_key, domain, queued, observed
dt_iris_enrich_data	_key, _raw, dt_queued, dt_retrieved, dt_observed, en_domain_name, en_is_active, en_adsense_code, en_google_analytics_code, en_alexa_ranking, en_domain_create_date, en_domain_updated_timestamp, en_domain_expiration_date, en_tld, en_website_response_code, en_redirect_url, en_registrant_name, en_registrant_org, en_registrar, en_spf_info, en_additional_whois_email, en_additional_soa_email, en_additional_ssl_raw, en_ssl_info_1_hash, en_ssl_info_1_organization, en_ssl_email, en_ssl_info_1_subject, en_risk_score, en_proximity_score, en_threat_profile_type, en_threat_profile_malware, en_threat_profile_phishing, en_threat_profile_spam, en_threat_profile_evidence, en_additional_name_servers_raw, en_name_server_1_domain, en_name_server_1_host, en_name_server_1_ip, en_name_server_2_domain, en_name_server_2_host, en_name_server_2_ip, en_additional_mx_raw, en_mx_1_domain, en_mx_1_host, en_mx_1_priority, en_mx_1_ip, en_additional_ips_raw, en_ip_1_address, en_ip_1_country_code, en_ip_1_isp, en_ip_1_asn, en_ip_2_address, en_ip_2_country_code, en_ip_2_isp, en_ip_2_asn, en_admin_contact_city, en_admin_contact_country, en_admin_contact_fax, en_admin_contact_name, en_admin_contact_org, en_admin_contact_phone, en_admin_contact_postal, en_admin_contact_state, en_admin_contact_street, en_admin_contact_email, en_billing_contact_city, en_billing_contact_country, en_billing_contact_fax, en_billing_contact_name, en_billing_contact_org, en_billing_contact_phone, en_billing_contact_postal, en_billing_contact_state, en_billing_contact_street, en_billing_contact_email, en_technical_contact_city, en_technical_contact_country, en_technical_contact_fax, en_technical_contact_name, en_technical_contact_org, en_technical_contact_phone, en_technical_contact_postal, en_technical_contact_state, en_technical_contact_street, en_technical_contact_email, en_registrant_contact_city, en_registrant_contact_country, en_registrant_contact_fax, en_registrant_contact_name, en_registrant_contact_org, en_registrant_contact_phone, en_registrant_contact_postal, en_registrant_contact_state, en_registrant_contact_street, en_registrant_contact_email, en_tag, en_tag_raw
dt_stats	_key, dt_last_enriched_datetime, dt_num_of_times_enriched, dt_num_of_AdhocLookups, dt_fooyn_timestamp, dt_looyn_timestamp, en_attribute_name, en_attribute_type, en_risk_score
dt_allowlist	_key, en_attribute_type, _dt_updated, _dt_updated_by, _dt_created, _dt_created_by
dt_monitoring_list	_key, en_attribute_type, _dt_updated, _dt_updated_by, _dt_created, _dt_created_by, _dt_source
dt_tags_list	_key, en_attribute_type, _dt_updated, _dt_updated_by, _dt_created, _dt_created_by
dt_iris_detect_monitors	_key, monitor_id, term, state, match_substring_variations, nameserver_exclusions, text_exclusions, created_date, updated_date, status, created_by, discover_new_domains, dt_updated
dt_iris_detect_results	_key, dt_domain, dt_state, dt_status, dt_discovered_date, dt_escalations, dt_risk_score, dt_risk_status, dt_mx_exists, dt_tld, dt_domains_id, dt_monitor_ids, dt_create_date, dt_ip_address_1, dt_ip_address_2, dt_ip_raw, dt_nameServer_1, dt_nameServer_2, dt_nameServer_raw, dt_mailServer_1, dt_mailServer_2, dt_mailServer_raw, dt_registrar, dt_registrant_contact_email, dt_proximity_score, dt_threat_profile_malware, dt_threat_profile_phishing, dt_threat_profile_spam, dt_threat_profile_evidence, dt_monitor_flag, dt_imported
dt_iris_investigate	_key, dt_pivot_type, dt_pivot_value, dt_investigate_raw, _dt_created
dt_rrset_kvstore
dt_rdata_kvstore

Table: Key Macros for Enrichment

Macro Field Name	Default Value	Description
dt_basesearch		The value that is defined is the base search. Data is pulled directly from the datamodel. We use this search to search for and queue up domains for the app and certain features such as the dashboards.
enable_cache	1 (enabled)	Enrichment setting to determine caching of enriched data. DomainTools will always enrich every domain in the queue. When turned off (set to 0) an API call will be made for every domain.
dt_cache_retention_period	30 (in days)	Enrichment setting. Set the value to how many days back before removing older data from the enrichment kvstore. There is also a saved search that will remove records that are over 30 days old.
dt_proximity_score_threshold	65	Enrichment setting. Set the threshold throughout the app when filtering based on the Proximity score.
dt_threat_profile_score_threshold	85	Enrichment setting. Set the threshold throughout the app when filtering based on the Threat Profile score.
dt_high_risk_threshold	90	Enrichment setting. Set the threshold throughout the app.
dt_medium_risk_threshold	70	Enrichment setting. Set the threshold throughout the app.
dt_refresh_interval	15 (in minutes)	The refresh interval.
dtdomainextract2	rex field=url "(.*:\/\/)?(?P\<temp_domain>[^:#\/?]+)" \	lookup dt_public_suffix_list wildcard_tld AS temp_domain OUTPUT tld AS tld \
dt_risk_score_threshold	75	Enrichment setting. Set the threshold throughout the app when filtering based on the Risk Score.
dt_young_domain_age	7 (in days)	Enrichment setting. The number of days the app considers a domain to be young.
dt_include_allowlisted_domains	0 (false)	Allowlist setting. Set to 1 (enabled) to exclude showing domains in the allowlist in our dashboards.
dt_include_monitoring_list_domains	0 (false)	Setting to include monitoring list domains.
dt_enrich_to_stats_lookup		A partial search that is used by the saved searches that update the enriched data KV Store.
dt_include_allowlisted_domains_in_notable_events	0 (false)	Enrichment alert setting for notable events.
dt_only_monitored_domains_in_notable_events	1 (enabled)	Enrichment alert setting for notable events.
dt_use_risk_threshold_in_notable_events	0 (false)	Enrichment alert setting for notable events.
dt_use_threatprofile_threshold_in_notable_events	0 (false)	Enrichment alert setting for notable events.
dt_ignore_iris_detect_in_notable_events	0 (false)	Enrichment alert setting for notable events.
dt_monitor_tags_in_notable_events	0 (false)	Enrichment alert setting for notable events.
dt_notable_events		Search for notable events provided by the DomainTools App for Splunk ES.
dt_rename_base_fields		Renames the base search fields. For example, rename src to Source, dest as Destination, log_source as Log Source and domain as Domain Name.
dt_rename_iris_fields
unknown_domain_retry	1 (enabled)	Retry enrichment of domains that are unknown to DomainTools.
unknown_domain_retry_time	60 (in minutes)	Number of minutes to wait before trying to re-enrich a domain.
toEpoch(1)	if(isnull(round(relative_time(time(), "$reltime$"))), "$reltime$", round(relative_time(time(), "$reltime$")))	Changes timestamp to epoch.

Table: Saved Search Names and Descriptions

The following is a complete list of Saved Searches, descriptions, and supported functionalities.

Saved Search Name	Type	Description of the Saved Search	Required (Yes, No, Optional)	App Functionalities
DomainTools - Queue Builder for Iris Enrich KV Store	Reports	A search to extract domains from raw events based on your configured base search and store them in the dt_iris_enrich_queue KV store for enrichment. Default cron_schedule \= */2 * * * *	Yes*	Core App
DomainTools - Expire Old Queue Data	Reports	A search to remove domains from the dt_iris_enrich_queue collection that are over a day old. Default cron_schedule \= 0 0 * * *	Yes	Core App
DomainTools - Iris Enrichment	Reports	A search to enrich domains found in dt_iris_enrich_queue, and store results in dt_iris_enrich_data collection. By default, the search is scheduled to run every 5 minutes and pulls data over the past 30 minutes. Customize this frequency in the app. Default cron_schedule \= */5 * * * *	Yes*	Core App
DomainTools - Expire Old Iris Enrich Data	Reports	A search to remove enrichment data from the dt_iris_enrich_data collection based on the cache retention settings configured in the app. Default cron_schedule \= 0 0 * * *	Yes	Core App
DomainTools - Iris Enrich Monitored Domains	Reports	A search to refresh enrichment data for monitored domains based on the frequency configured in the app. Default cron_schedule \= 0 0 * * *	Yes	Core App
DomainTools - Summary - Timechart count by domain with latest time	Reports	A search to summarize events from the base search whenever the selected time window is greater than 2 hours in any of our dashboards. Default cron_schedule \= */5 * * * *	Yes**	Core App
DomainTools - Expire Old Investigate Data	Reports	A search to remove investigative results older than 24 hours. Default cron_schedule \= 0 0 * * *	Yes	Core App
DomainTools - Iris Enrich Monitored Domains Live	Reports	A search to refresh enrichment data for monitored domains, whenever it is seen on your network. Default cron_schedule \= 5 * * * *	No (DomainTools app will manage this automatically)	Core App
DomainTools - Import Iris Detect Monitors	Reports	A search to import newly discovered and watched domains from Iris Detect monitors in the app. Customers using Iris Detect functionalities in the app must enable this saved search in Splunk. Default cron_schedule \= 0 0 * * *	Optional (Required for Iris Detect)	Iris Detect
DomainTools - Import Iris Detect Results	Reports	A search to import newly discovered domains from Iris Detect for monitors enabled in the app. Customers using Iris Detect functionalities in the app must enable this saved search in Splunk. Default cron_schedule \= 45 */2 * * *	Optional (Required for Iris Detect)	Iris Detect
DomainTools - Sync Iris Detect Watchlist	Reports	A search to automatically sync Iris Detect Watchlist with DomainTools Monitoring List inside of Splunk. Default cron_schedule \= 0 0 * * *	Optional (Required for Iris Detect)	Iris Detect
DomainTools - Expire Old Iris Detect Data	Reports	A search to remove Iris Detect domains that were imported more than 14 days ago. Customers using Iris Detect functionalities in the app must enable this saved search in Splunk. Default cron_schedule \= 0 0 * * *	Optional (Required for Iris Detect)	Iris Detect
DomainTools - DomainTools Domain Monitoring - Rule	Alerts	A saved search to create events based on the criteria selected in DomainTools App → DT Settings → Configure Enrichment & Alerting. Customers wanting to create Notable Events within Enterprise Security must either enable this saved search or enable the correlation search inside Splunk ES. Default cron_schedule \= */30 * * * *	Optional (Required for Enterprise Security)	Alerting in Splunk Enterprise Security
DomainTools - DomainTools Young Domains - Rule	Alerts	A saved search to create events based on the criteria selected in DomainTools App → DT Settings → Configure Enrichment & Alerting. Customers wanting to create Notable Events within Enterprise Security must either enable this saved search or enable the correlation search inside Splunk ES. Default cron_schedule \= */30 * * * *	Optional (Required for Enterprise Security)	Alerting in Splunk Enterprise Security

*The app will function with "DomainTools - Queue Builder for Iris Enrich KV Store" and "DomainTools - Iris Enrichment" disabled, but won’t automatically enrich events. Some customers choose to disable these when building their own enrichment pipelines, using the DomainTools app for ad hoc search or monitoring only.

**The app will function with "DomainTools - Summary - Timechart count by domain with latest time" disabled, but dashboard views 4 hours or above will fail to show any data. These larger time frames rely on the summary data generated by this saved search. In some customer environments, this may be an acceptable tradeoff for performance considerations.