Skip to content

Iris Investigate User Guide

Getting started

Access Iris Investigate at https://iris.domaintools.com/investigate/.

RDAP (Registration Data Access Protocol) support

The suite of Iris products now supports the Registration Data Access Protocol (RDAP). In locations where an Iris UI or API previously served only WHOIS data, Iris now serves registration data. Registration data defaults to the RDAP or WHOIS record that the system infers to be the most useful:

  • RDAP and WHOIS records gathered for a domain within 3 days of each other surface the record with the most data, with ties going to RDAP.
  • RDAP and WHOIS records gathered more than 3 days apart favor the newer record.

The UI and API can also serve either WHOIS or RDAP data in response to user specification.

The RDAP FAQ and the letter to Iris customers explain how RDAP works in DomainTools products. This guide contains RDAP-specific information in:

Provision access

The organization provisions access in the DomainTools Enterprise account. Contact enterprisesupport@domaintools.com for help.

For information about the Iris Investigate API and the DomainTools API suite, consult the Iris Investigate API documentation.

Investigations overview

Investigations are containers that organize a collection of search queries and results, search trails, data pivots, notes, and more. The Collaboration section explains how to share and export investigations.

When a search begins, Iris Investigate automatically starts the investigation.

Search for domains

Adding historical results to an advanced search.

Perform the first search from the DomainTools Research page (), the Iris Investigate landing page (), or from within the search bar or advanced search tab in the web application.

Begin searches with any of the accepted search parameters, and Iris Investigate guesses which type of data was provided: for example, it interprets 4.2.2.2 as an IP address and domaintools.com as a domain name. (The Iris Investigate UI accepts 'de-fanged' values for IP and host addresses such as example[.]tld and 4[.]2.2.2.) Include shortcodes in the query string to specify the data type, and pass these codes from non-DomainTools applications in the API.

Base search parameters

Filter or expand results through the Advanced button next to the search box. Add additional filters with logical AND (narrow results) and OR (expand results) operators. Each filter can use a match rule available for its specific data type.

Domain Information

Domain Name parameter
  • Shortcode: domain
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Does Not Contain, Does Not Exactly Match, Does Not Match, Ends With, Exactly In, Exactly Match, In, Matches, Not Exactly In, Not In
Create Date parameter
  • Shortcode: cre
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches, Within
Expiration Date parameter
  • Shortcode: exp
  • Historical Search: No
  • Accepted Operators: Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches, Within
First Seen parameter
  • Shortcode: current_lifecycle_first_seen
  • Historical Search: No
  • Accepted Operators: Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches, Within
Rank parameter
  • Shortcode: popularity_rank
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches
Risk Score parameter
  • Shortcode: cr
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches
Status parameter
  • Shortcode: active
  • Historical Search: No
  • Accepted Operators: Matches
Tags parameter
  • Shortcode: tags
  • Historical Search: No
  • Accepted Operators: Contains, Contains All, Does Not Contain, Does Not Contain All
TLD parameter
  • Shortcode: tld
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, In, Matches, Not In
Website Title parameter
  • Shortcode: title
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Does Not Match, Exactly Matches, Exists, Matches
Server Type parameter
  • Shortcode: server_type
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Does Not Match, Exactly Matches, Exists, Matches
Redirect Domain parameter
  • Shortcode: rdd
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Whois Record parameter
  • Shortcode: whois
  • Historical Search: Yes
  • Accepted Operators: Contains, Contains All

Contact Information

Contact Country Code parameter
  • Shortcode: cons.cc
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Contact Name parameter
  • Shortcode: cons.nm
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Exactly Matches, Exists
Contact Phone parameter
  • Shortcode: cons.ph
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Contact Street parameter
  • Shortcode: cons.str
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Exactly Matches, Exists
Registrant parameter
  • Shortcode: r_n
  • Historical Search: Yes
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Does Not Match, Exactly Matches, Exists, Matches
Registrant Organisation parameter
  • Shortcode: r_o
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Does Not Match, Exactly Matches, Exists, Matches
Registrar parameter
  • Shortcode: reg
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Does Not Match, Exactly Matches, Exists, Matches

Email Information

Email parameter
  • Shortcode: em
  • Historical Search: Yes
  • Accepted Operators: Begins With, Does Not Match, Exists, In, Matches, Not In
Email - Admin parameter
  • Shortcode: empa
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Email - Billing parameter
  • Shortcode: empb
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Email - DNS/SOA parameter
  • Shortcode: ema
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Email - Registrant parameter
  • Shortcode: empr
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Email - Technical parameter
  • Shortcode: empt
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Email - Whois parameter
  • Shortcode: emw
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Email Domain parameter
  • Shortcode: emd
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, In, Matches, Not In

IP Information

IP parameter
  • Shortcode: ip.ip
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, In, Less Than, Less Than or Equal To, Matches, Not In
IP ASN parameter
  • Shortcode: ip.asn
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches
IP Country Code parameter
  • Shortcode: ip.cc
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
ISP IP Information parameter
  • Shortcode: ip.isp
  • Historical Search: No
  • Accepted Operators: Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Exactly Matches, Exists

DNS Information

Name Server parameter
  • Shortcode: ns.ns
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Matches
Name Server Domain parameter
  • Shortcode: ns.nsd
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
Name Server IP parameter
  • Shortcode: ns.nip
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, In, Less Than, Less Than or Equal To, Matches, Not In
MX Server parameter
  • Shortcode: mx.mx
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
MX Server Domain parameter
  • Shortcode: mx.mxd
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
MX Server IP parameter
  • Shortcode: mx.mip
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, In, Less Than, Less Than or Equal To, Matches, Not In

SSL Certificate Information

SSL Alt Names parameter
  • Shortcode: ssl.alt_names
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Does Not Contain, Does Not Match, Exists, Matches
SSL Duration (days) parameter
  • Shortcode: ssl.duration
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches
SSL Email parameter
  • Shortcode: ssl.em
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
SSL Hash parameter
  • Shortcode: ssl.sh
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
SSL Issuer Common Name parameter
  • Shortcode: ssl.issuer_common_name
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Does Not Contain, Does Not Match, Ends With, Matches
SSL Not After Date parameter
  • Shortcode: ssl.not_after
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches, Within
SSL Not Before Date parameter
  • Shortcode: ssl.not_before
  • Historical Search: No
  • Accepted Operators: Does Not Match, Greater Than, Greater Than or Equal To, Less Than, Less Than or Equal To, Matches, Within
SSL Subject parameter
  • Shortcode: ssl.s
  • Historical Search: No
  • Accepted Operators: Begins With, Does Not Match, Exists, Matches
SSL Subject Common Name parameter
  • Shortcode: ssl.common_name
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Does Not Contain, Does Not Match, Ends With, Matches
SSL Subject Org Name parameter
  • Shortcode: ssl.so
  • Historical Search: No
  • Accepted Operators: Begins With, Contains, Contains All, Does Not Contain, Does Not Contain All, Does Not Exactly Match, Does Not Match, Exactly Matches, Exists, Matches

Web Analytics and Trackers

Adsense parameter
  • Shortcode: ad
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Matches
Baidu Analytics parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Facebook (Meta Pixel) parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Google Analytics parameter
  • Shortcode: ga
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Google Analytics 4 parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Google Tag Manager parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Hotjar parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Matomo parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Statcounter - Project Codes parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Statcounter - Security Codes parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches
Yandex Metrica parameter
  • Shortcode: None
  • Historical Search: No
  • Accepted Operators: Does Not Match, Exists, Does Not Exist, Matches

Match operations determine how the search query compares against the data stored in Iris Investigate. Understanding these operations helps create more precise searches and find relevant domains efficiently.

Understanding tokenization

Many match operations use tokenization to analyze text. When searching for a value like help-facebook.com, the system breaks it into individual tokens: help and facebook.com. Similarly, this is an example becomes tokens: this, is, an, and example.

Some operations use these tokens to match records (such as Matches and Contains), while others perform exact string matching without tokenization (such as Exactly Matches). Understanding whether an operation uses tokenization helps predict and control search results.

String Matching Operations

Begins With

Searches for records where the field value starts with the specified string.

Ends With

Searches for records where the field value ends with the specified string.

Contains

The Contains operation searches for records that include at least one token from the search query. This operation uses OR logic between tokens.

How it works:

  • The search value is tokenized.
  • Returns records containing any of the tokens (OR logic).
  • More permissive than both Contains All and Matches.

Example: Searching for help-facebook.com returns records containing either help OR facebook.com. Records with just one of these tokens match.

Contains All

The Contains All operation searches for records that include all tokens from the search query. This operation uses AND logic between tokens.

How it works:

  • The search value is tokenized.
  • Returns records containing all of the tokens (AND logic).
  • Tokens don't need to be in a specific order or adjacent.
  • Equivalent to Matches for text fields.

Example: Searching for help-facebook.com returns only records containing both help AND facebook.com tokens.

Matches

For text fields, the Matches operation searches for records that contain all tokens from the search query. This operation uses AND logic between tokens.

How it works:

  • The search value is tokenized into individual tokens (words and domain parts).
  • Returns records where all tokens are present (AND logic).
  • Tokens don't need to be in a specific order or adjacent.
  • Token matching is case-insensitive.
  • Equivalent to Contains All for text fields.
  • For quantitative fields (numbers, dates), Matches works as "Equal To".

Example: Searching for help-facebook.com finds records containing both help AND facebook.com tokens.

Exactly Matches

The Exactly Matches operation searches for records that contain the exact search value. This operation uses exact string matching without tokenization.

How it works:

  • No tokenization or analysis occurs.
  • Performs a precise, exact string match.
  • Case-insensitive comparison.
  • Opposite of Does Not Exactly Match.

Example: Searching for help-facebook.com only returns records with that exact string. Records with help or facebook.com alone don't match.

Does Not Contain

The Does Not Contain operation excludes records that contain any token from the search query. This operation uses OR logic between tokens for exclusion.

How it works:

  • The search value is tokenized.
  • Excludes records if any token is found (OR logic for exclusion).
  • More restrictive than Does Not Contain All.

Example: Searching for help-facebook.com excludes records containing either help OR facebook.com. Any record with at least one of these tokens is excluded.

Does Not Contain All

The Does Not Contain All operation excludes records that contain all tokens from the search query. Returns records missing at least one token.

How it works:

  • The search value is tokenized.
  • Excludes records only if all tokens are present (AND logic for exclusion).
  • Returns records that are missing at least one token.
  • More permissive than Does Not Contain.

Example: Searching for help-facebook.com excludes only records containing both help AND facebook.com. Records with just one of these tokens are included in results.

Does Not Match

The Does Not Match operation finds records that do not contain all tokens from the search query. This operation uses AND logic for tokenization.

How it works:

  • The search value is tokenized.
  • Returns records where at least one token is missing (AND logic for matching).
  • Excludes records that contain all tokens.

Example: Searching for help-facebook.com returns records that don't contain both help AND facebook.com. Records with only help or only facebook.com are included in results.

Does Not Exactly Match

The Does Not Exactly Match operation finds records that do not contain the exact search value. This operation uses exact string matching without tokenization.

How it works:

  • No tokenization occurs.
  • Returns records that don't have the exact character-for-character match.
  • Case-insensitive comparison.
  • Opposite of Exactly Matches.

Example: Searching for help-facebook.com returns records that don't contain that exact string. Records with help or facebook.com alone would be included in results.

List Matching Operations

In

Searches for records where the field value matches any value in a specified list.

Not In

Searches for records where the field value does not match any value in a specified list.

Exactly In

Searches for records where the field value exactly matches any value in a specified list, using case-sensitive comparison.

Not Exactly In

Searches for records where the field value does not exactly match any value in a specified list.

Existence Operations

Exists

Returns records where the specified field contains any value.

Does Not Exist

Returns records where the specified field is empty or not present.

To quickly build an advanced search based on values in the Pivot Engine, drag/drop values from the Pivot Engine into the (opened) Advanced Search pane. Iris Investigate supports a maximum of 1024 filters per advanced search.

Comparison Operations

Greater Than

Returns records where the field value is greater than the specified value.

Greater Than or Equal To

Returns records where the field value is greater than or equal to the specified value.

Less Than

Returns records where the field value is less than the specified value.

Less Than or Equal To (also Equal To or Less Than)

Returns records where the field value is less than or equal to the specified value.

Guided search parameters, codes, and operators

Guided search inputs are accepted in the Iris Investigate search bar, and by passing the guided search parameters to Iris Investigate via a URL. Guided search uses opcodes.

For example, searching Iris Investigate for 209242 to locate domains on the Autonomous System Number (ASN) ASN209242 returns results for the string 209242, including user accounts and email addresses.

However, the search string ip.asn:"209242" instructs Iris Investigate to search only ASNs.

These two searches can also be accomplished with a URL query parameter. A generic search for 209242 is constructed as:

https://iris.domaintools.com/investigate/search/?q="209242"

A guided search for ASN209242, however, is written as:

https://iris.domaintools.com/investigate/search/?q=ip.asn:"209242"

Supported operators:

Operator Definition
: or = Equal
!= or <> Not equal
> Greater than
>= Greater than or equal to
< Less than
<= Less than or equal to

Viewing results in the web UI

The search brings the user to the Iris Investigate web UI, the interface to start at if a recent search was made or if continuing an investigation. Start interacting with search results with three major components of the Iris Investigate web UI:

  1. The Search Area, including a navigable 'breadcrumb' investigation graph.
  2. The Panel Navigation, Tabs, and Selector, for navigating and re-ordering Data Panels.
  3. The Results Panel, which begins with the Pivot Engine in the leftmost spot.
Viewing results in the web UI
Viewing results in the web UI

Review the results of the search query in the Pivot Engine panel:

  • If Iris Investigate provides a single domain for the search, it populates the Data Panels with information for that domain.
  • If the search query returns multiple domains, Iris Investigate lists multiple entries in the Pivot Engine, and populates the remaining Data Panels with the domain selected.

The Data Panels remain populated with the selected domain's information while creating new branches, or performing searches with no results. This means that the active domain remains populated in the Data Panels until a different domain is selected.

From Advanced Search, selecting either RDAP or WHOIS in place of "auto"
From Advanced Search, selecting either RDAP or WHOIS in place of "auto"

Searches by default use registration data. From Advanced Search, a new "auto" mode searches on the registration data for the given field. To search specifically against RDAP or WHOIS, change the "auto" value from "auto" to the protocol-specific option.

Pivot engine

The concept of a "pivot" is fundamental to many investigations—that is, given a starting point, discover connections to one or more related items. For example, if the starting point is a domain lookup, a common pivot is on the email address of the registrant of the domain. This pivot shows all of the other domains in the DomainTools database that are connected to that email address. Many data points serve as pivots—IP addresses, registrant names, name servers, etc. Most data types shown in Iris Investigate can function as pivot points.

Execute advanced searches directly from search results by pivoting on specific data points. Pivots advance the investigation by modifying the search with data selected from search results.

The Pivot Engine aggregates search results, displaying key data points which can be pivoted on or explored further in the relevant associated data panel.

Right-clicking on a data point brings up the Operations Menu, which pivots on or (with many data types) further inspects the data.

The operations menu
The operations menu

Pivoting with the operations menu

By right-clicking a data point, the Operations Menu lets the user narrow or expand the search with the data point's string, start a new search, or exclude results containing that string. These operations mirror what is available in the advanced search panel. For example, Expand Search uses the new search term to create an OR search with the previous query. Trigger an OR search with the original and means that the new search is a logical AND of the original query and additional queries.

Pivoting with RDAP and WHOIS

Right-clicking a registration data point shows the count for the registration data, and below it, the data for each RDAP and WHOIS. By default, either the RDAP or WHOIS value appears normally, and the other is dimmed. This signifies which protocol has been chosen for populating Registration data - the one that is not dimmed is what is used for Registration data.

RDAP results appearing normally during a guided pivot, while WHOIS is de-emphasized
RDAP results appearing normally during a guided pivot, while WHOIS is de-emphasized

The counts for guided pivots are similarly based on registration data, not just WHOIS data. As RDAP data populates registration data (when the RDAP record is used over the WHOIS record) then RDAP data is included in counts for guided pivots. That means data points like emails and contact information have counts that bridge RDAP and WHOIS - making the transition from WHOIS to RDAP seamless in most cases.

Viewing current and historical email results
Viewing current and historical email results

Pivoting with historical results

Filter for historical results much like in advanced search: when pivoting on a historical compatible field with pivotable data, select the magnifying icon to load the domains that share the value. Toggle between Current Only, Historical Only, or Current & Historical.

Previewing and inspecting results with the operations menu

In addition to the filter controls for pivots, the Operations Menu offers preview and inspection information, depending on the type of data selected.

When selecting a domain, the Operations Menu links to domain-specific information across multiple Data Panels.

When selecting a non-domain field (e.g. IP address, contact information), the Operations Menu displays:

  • The number of domains that share that value.
  • The option to list and further investigate those domains from a side panel (for guided pivots).
  • A link to investigate the data point in the pDNS panel.
  • The Domain Risk Score.

The Operations Menu also displays information specific to the type of field selected. For example, if right clicking an IP it shows IP Profile, Ping, Traceroute, and PTR. A SSL field provides a link to the SSL Profile.

Guided pivots

Iris Investigate highlights any field that can pivot to 500 or fewer domains, a range that typically indicates a useful investigation target. Often, the smaller the number of pivots, the more useful the connection to another domain may be. For each of the Guided Pivots, the average risk of the associated domains is shown as a quick indicator of severity.

Configure the threshold or disabled Guided Pivots in settings, accessible from the Product Menu or the settings icon on the top left of the Pivot Engine.

Domain risk score

The Domain Risk Score predicts how likely a domain is to be malicious, often before it is weaponized. Consult Domain Risk Score documentation for more information.

Each time you pivot on your results, Iris Investigate moves your investigation forward to a new node in your Search History. Each new node connects to its originating node with a line/edge. Toggle fullscreen mode with h. For a complete list of Iris Investigate UI keyboard shortcuts, consult https://iris.domaintools.com/investigate/help/.

The search history graph codes details about each search node. For example, green nodes indicate your active investigation path, orange nodes indicate searches outside of your active investigation path, and the blue 'document' icon nodes indicate passive DNS results. Consult the Reference section for all Search History indicators.

Return to any point in your investigation by selecting the node, and Iris Investigate loads your Pivot Engine and Data Panels for that query. Continue with new pivots, and Iris Investigate creates a new branch of nodes.

Create a new, empty history branch by selecting the + button near the top right corner of the Pivot Engine. Your next query becomes the root node of the new branch (note how this feature can aid in organizing your investigation). Start a new branch with the current node as the root. To do this, select Manage History > New History Branch > Start it with the Current Search.

Once you delete a node or a branch, it cannot be recovered.

Annotating in search history with the search node drawer

Hovering over a search node invokes the search node drawer, which can:

  • Highlight nodes with the Mark as Important button.
  • Export this node's search hash to the clipboard.
  • Review and add Search Notes.

When notes exist for a node, a number on the node indicates how many notes it has. The search nodes in your investigation history also indicate (with a number bubble) the Search Notes count, as well as the nodes Marked as Important.

Enter an IP address, domain name, or email address in your notes, and Iris Investigate enables Operations Menus to search or filter directly from the notes.

Tag domains and share tags

Tags attach to domains, include an editable description field, and can be modified by the Iris Investigate APIs. Edit, search, and filter by tag. The Tag Manager displays all the domains associated with a single tag, across your group.

You can apply tags to these and other use cases:

  • Attribution labeling.
  • Threat profile type.
  • Operational status.
  • Inclusion in a specific case.
  • Triage or other status.
  • Programmatic decision-making.

In addition to the API, access tags through the following sections of the Iris Investigate UI:

  • The Pivot Engine lets you modify tags from one or multiple domains by selecting the domains and the Tag button (you can also export tags).
  • The Operations Menu, when opened from a domain, allows you to edit tags for that domain.
  • The Tag Manager (accessible from the Product Menu) displays all tags from your investigations. It also includes tags used in your group: consult the Collaborating section, below.
  • The Stats Data Panel visualizes tags.

Your tags automatically share with other users in your group. Your investigations are private by default, but you can also share them to your group.

If you export a Search Hash to a user outside of your group, your tags are not visible.

Product menu

Create or open investigations, start an ad-hoc search, adjust the layout, or return to the home page from the navigation column. Click "Iris Investigate" in the upper left corner to open it. The Product Menu contains the Settings menu.

Collaboration

Groups

A Group consists of the other Iris Investigate users at your company.

Search hashes

Search Hashes share a specific search to anyone with Iris Investigate, including people outside of your group. Search hashes reproduce search terms, but do not include tags or other investigation-specific information. The Investigate API can also use search hashes to query for the results of an advanced search first created through the Investigate web UI.

Sharing investigations

By default, investigations are private to the originating user.

Share your investigations from the Product Menu by hovering over your active investigation, and then selecting Edit Investigation. Three access levels are available for your group members: view, add branches, and delete branches.

When another user creates a new search node in your shared investigation, that node appears in Search History with a sharing icon, and triggers a browser notification.

When an investigation is shared with you, the investigation appears in your investigation list in the Product Menu, grouped under the heading Investigations shared with you.

If you unshare an investigation, the investigation disappears for other group members.

Reporting

The Generate Investigation Report button in the Product Menu creates a PDF containing the following information:

  • Title and description.
  • Investigation path in tabular form, and including search notes.
  • Pivot Engine data in tabular form, with columns matching your Pivot Engine Panel columns. For search results numbering over 500, the report includes the page of Pivot Engine results that are displayed at the time of generation.
  • Statistics, via the Stats Data Panel.
  • Visualizations, generated from the current appearance of the Visualization Data Panel (large result sets may not display well in this format; download high-res images from the Visualization Data Panel directly).

The system generates reports from the viewpoint of the current selected node in your investigation. For a report of the full investigation, select the final node before generating the report. The Stats, Visualization, and Pivot Engine Data Panels must be displayed in the investigation UI in order for their contents to be included in the report.

Export pivot engine results

Export your full Pivot Engine table at any time by selecting the DOWNLOAD button next to page navigation near the top of the Pivot Engine Data Panel, and selecting the format (CSV, STIX (https://stixproject.github.io/) 1.2, or STIX (https://stixproject.github.io/) 2.0).

Fields containing multiple values have repeated columns in order to maintain a single value per table element.

Multiple Iris Investigate data panels contain web-related data that the web crawler gathers.

By default, the web crawler gathers data upon the first discovery of a domain. If a domain has a domain risk score of 70 or above, the web crawler automatically gathers data every 3 months. If the user group uses Iris Detect to watch a domain, the web crawler gathers data every day.

To update web-related data at a cadence outside of our default settings, you can trigger the web crawler to gather web-related data for a domain or group of domains. Select the Update Content button in the relevant data panels (Pivot Engine, Screenshot History, Domain Profile, SSL Profile) to trigger the web-crawler to gather fresh web-related data including:

  • Screenshot.
  • Website title.
  • Website response code.
  • Redirect domain.
  • Server type.
  • Website trackers.
  • Aspects of the SSL certificate.

Data panels

Iris Investigate uses Data Panels to present domain information in containers.

Navigate Data Panels with the Data Panel Tabs, and select which Data Panels are visible through the 'hamburger' menu on the far right of the ribbon.

You can resize Data Panels with the 'resize' icon on the far right of the Data Panel's title ribbon. Most panels have settings options, accessible through the settings icon in the panel's title bar.

The Operations Menu and Pivot Engine can invoke context-appropriate Data Panels, as can other Data Panels.

Domain profile data panel

The Domain Profile Data Panel serves as a snapshot of all domain related data in one data panel. It is especially useful for getting an overview of the domain-related data, and choosing the next data panel to review for your investigation.

The Domain Profile panel shows the following information:

  • Domain name.
  • Domain Risk Score.
  • Screenshot.
  • Recent Passive DNS resolutions.
  • Dates: First Seen date/time, WHOIS Create Date, Expiration Date.
  • Email address(es).
  • Registrant Organization.
  • Registrar.
  • Registrar Status.
  • Name Servers.
  • IP addresses.
  • IP location.
  • ASN.
  • WHOIS History summary.
  • Website title and server type.
  • "Raw" WHOIS record.
RDAP record displayed in Domain Profile
RDAP record displayed in Domain Profile

Domain profile - RDAP content

A new element at the bottom shows the most recent parsed RDAP record. You can alternatively toggle to view the WHOIS record. You can copy the raw RDAP record's JSON to the clipboard for viewing in a code editor of your choice. When the Parsed RDAP record uses data from both the registry and registrar, you can choose which record to copy to your clipboard.

Domain history data panel

Domain History shows how a domain has evolved over time. It replaces the legacy Hosting History service, covering many more fields and covering all domains tracked by DomainTools.

The tracked data elements include:

Data Element Description
Status When DomainTools sees a domain as newly active, or when a domain becomes inactive
WHOIS data Create/expiration dates, registrar and registrant names, contact emails, and more
DNS data Results of daily DNS resolutions for A, NS, MX and SOA active resolutions
Web content Website title, response code, server type, trackers, and more
Screenshots The date/time when a new screenshot is captured
SSL Certificate updates The SHA 1 hash, validity dates, Issuer Common Name, and up to the first 5 Subject Alt Names

The system tracks each data element for differential changes, and generates records when a value in a tracked field changes. The newly added element is shaded green and also has a short vertical bar. Unchanged elements have no special formatting.

Filter the list by primary and secondary categories in the Domain History: Fields Settings menu, accessible through the gear icon on the left of the Domain History panel title bar. Show and hide the new subset of your results by toggling in the Field button, located in the panel's column rows.

Domain history versus historical pDNS and WHOIS data

Domain History is available for over 98% of active domains, and for all domains created since 2021. For some domains, additional historical information is available in the legacy Hosting History Data Panel Panel (via the Investigate UX), and in our 20+ years of records in the WHOIS History Data Panel.

Screenshot history data panel

The Screenshot History data panel provides an index of dates for which DomainTools has an archived screenshot for the domain. If Screenshot History is empty, select the Update Content button to queue the web crawler to gather an updated screenshot for the domain (typically available within five minutes, and up to 24 hours).

When multiple historical screenshots are available, browse through them using < or >.

Stats data panel

The Stats Data Panel shows the number of occurrences of data points within the displayed results set, and can help you understand the level of connection of the domains in your pivot engine. In some cases, such as date fields and domain risk score, the system groups domains in the result set in sets, rather than by individual values.

Each of the data types is represented graphically (a map for IP country and pie charts for all others), organized in a table.

In the settings menu within the Stats Panel, under Sorting, you can order guided pivots first.

Stats aggregates data for the first 2,500 records in the results set.

Visualization data panel

The Visualization Data Panel is a visual representation of connections between domains in the Pivot Engine. It depicts domains as blue nodes; the legend in the upper left shows the color-coding for the others. A domain can either be a larger or normal sized dot. The larger dots represent domains with high domain risk scores of 70 or higher. The legend also shows how many instances there are for each field in the graph. Select Edit Fields to choose up to 4 fields (plus domain) to view.

Double-clicking a domain or IP address node makes it the current domain and populates all domain-centric panels. When you hover over a node on the graph, that node and those directly connected to it are highlighted. Zoom in and out on the graph, and drag an item in the Force layout in order to put the most interesting data in the center.

The Link Degree slider in the lower-right lets you filter out data that either have too many or too few connections.

Node inspector

Use the Node Inspector on the right of the panel to view the values for each of the fields. You can search for a specific value or filter by field, and perform guided pivots.

This is a great way to see a list of all the different values used by the domains in the pivot engine for a specific field (data point).

Passive DNS (pDNS) data panel

Passive DNS (pDNS) shows current and past domain to IP resolutions, as well as date stamps bracketing and relative dates, for when a given resolution was observed.

Query pDNS data from a search, or as a pivot with the Operations Menu. The pDNS data in Iris Investigate include the following record types:

Record Type Description
A IPv4 resolutions for domains and subdomains/hostnames (by default, the pDNS panel shows A records only)
AAAA IPv6 resolutions for domains and subdomains
NS Name server
SOA Start Of Authority email addresses and name servers
MX Mail server host names and IP addresses
CNAME Alias records mapping one hostname to another
TXT Optional catch-all record that may contain arbitrary descriptive information

Understanding pDNS results

The pDNS panel displays results in columns that provide context about each DNS observation:

Query : The Fully Qualified Domain Name (FQDN), domain, or subdomain that was queried via DNS. Also known as the question, left-hand-side data, or RRNAME.

Source : The pDNS provider that supplied this observation. The pDNS panel in Iris Investigate aggregates data from multiple sources, and this column identifies which source provided each specific observation.

Type : The DNS record type for this observation (A, AAAA, CNAME, MX, NS, SOA, or TXT). Also known as RRTYPE.

Count : The number of times this specific combination of Query, Type, and Response has been observed by the Source. Since pDNS sensors are positioned above the Recursive DNS Server layer and capture "cache misses" (DNS lookups made when the answer is not already cached locally or in the Recursive DNS Server), the count does not represent the total traffic volume to a website or the number of emails sent to/from a mail server.

Response : The answer provided by the authoritative name server (bailiwick) to the DNS query. The bailiwick is the DNS zone that has authority to answer queries for a particular domain. The data type shown depends on the DNS record Type: IPv4 addresses for A records, IPv6 addresses for AAAA records, name server hostnames for NS records, and so on. Also known as the answer, right-hand-side data, or RDATA.

First Seen : A timestamp indicating when the pDNS source first captured this observation. When only a date appears without an associated time, the pDNS source does not provide time-level granularity.

Last Seen : A timestamp indicating when the pDNS source most recently captured this observation. When only a date appears without an associated time, the pDNS source does not provide time-level granularity.

Duration : The time span between First Seen and Last Seen. This is a DomainTools metadata field, not part of DNS itself, that shows at a glance how long the DNS record set (RRSET) has been observed. A tilde (~) indicates an approximate time frame, typically shown when the pDNS source does not provide exact timestamps.

Apex domains

The pDNS Panel supports searching by apex domain, subdomain, or both. Consult the note in the Searching section for a definition of apex domain.

Query vs response

pDNS data is available from the query and response 'directions':

  • The query direction, also known as rrname, shows historical results for when the domain was queried and IP addresses were returned.
  • The response direction, also known as rdata, shows historical results for when the IP or IP CIDR range was queried and domain(s) were returned.

The response direction often yields fewer or no records This is because in DNS A records, domain is the query and the IP address is the response. If you enter a domain with the toggle set to response, or an IP address with the toggle set to query, if no results appear, try flipping the toggle and re-running the search.

Send results to pivot engine

Send pDNS results to the Pivot Engine by selecting Send domain results to pivot engine. You can modify or restart your search with pivots.

IP profile data panel

IP Profile is analogous to the Domain Profile panel. It provides key data points as well as the raw WHOIS record for the IP address. Pivot on the IP itself in order to modify or begin a search on that address.

In most places where an IP address is displayed across Iris Investigate, a magnifying glass icon appears just to the right of the address. Selecting the icon brings up the IP Inspect view, which is a fast way to view the IP Profile and IP Tools data for an IP address without losing your place in the UX.

IP tools data panel

The IP Tools panel provides three tools to investigate IP address information:

  • Ping generally tells you whether the IP address is reachable. When you trigger a ping through the interface, the ping originates from DomainTools and includes no record of your involvement.
  • Traceroute gives insights into the hosting, routing, and reachability of the IP address. As with Ping, when you trigger a traceroute through the interface, it originates from DomainTools and includes no record of your involvement.
  • PTR, the DNS Pointer (PTR) record, is commonly used as a form of Reverse DNS lookup. It shows the CNAME of the IP address, which tells you about the actual owner of the address (often a hosting provider) but not necessarily about the domains that may be hosted on that address.

SSL profile data panel

The SSL Profile panel provides SSL certificate details, including additional potential pivots. When DomainTools finds more than one certificate on a domain, Iris Investigate shows the certificates in separate tabs. For additional information on DomainTools collection and validation processes, consult the SSL Certificate Collection reference section.

You can find the additional pivots from an SSL/TLS certificate in the Extensions -> Subject Alt Name section, from which you can open the Operations Menu. To examine all the domains covered by a certificate, use the ADD TO FILTERS button.

Note that when using the contain operator for SSL Alt Names, the search term must exactly match any substring resulting from the domain being split by dots. For example, in example.domain.com, matches would be generated from example, domain, and com.

WHOIS history data panel

The WHOIS History Data Panel shows, by default, the current WHOIS record for the domain, with a vertical timeline of earlier dates for which DomainTools has a historical WHOIS record.

View changes to WHOIS records with three methods: Side by Side and Inline highlight the differing rows in the WHOIS record, while Raw records show the two records together.

The Operations Menu lists unique emails for pivoting.

Settings

The Product Menu contains the Settings panel.

Pivot engine settings

Guided pivots settings

Configure guided pivot ranges for each available data type.

Historical search settings

In addition to current records, Iris Investigate can find historical records matching email address and registrant information queries. Specifically, the three query types supported are email address, registrant, and WHOIS record contains. By default, historical search is enabled.

Per-search override: on an individual search, enable or disable historical queries on the three supported fields. To override, open Advanced search, select the history icon, and re-run your query.

Historical searching can return domains that do not match your query. The reason for this is that at some time in the domain's history, it did match the query. To see the record(s) where the domain matched the query, select See Historical Matches. This opens WHOIS History to the most recent record that matched your search term.

Active and Inactive Domains: Iris Investigate indicates when a domain is inactive with an icon near the domain name in Pivot Engine, and in the Status column. To be marked inactive, the domain must no longer resolve in DNS. Because there can be unusual cases in which registered domains do not resolve, or where unregistered domains do resolve, both conditions (not registered, not delegated) must be true for the domain to be marked inactive.

Appendix

Use the q query parameter to specify the type of search the URL links to and executes in Iris Investigate.

You can input domain names and IP addresses as the value for the q query parameter without using a short code, as seen in the examples in the previous section and below.

https://iris.domaintools.com/investigate/search/?q=domaintools.com

To create a URL to search for domains that have specific data field values such as an email address, ASN number, registrant, etc, you need to add the short code to the value of the q parameter value. Consult the fields and their corresponding short codes.

For example, creating a search for domains with a specific Autonomous System Number (ASN) you'll need to use the ip.asn short code followed by the ASN number in parentheses.

https://iris.domaintools.com/investigate/search/?q=ip.asn:"209242"

Not specifying the short code returns unpredictable results and misinterprets the search feature.

Use the q query parameter to specify the domain and the tab query parameter to specify the data panel to directly link to for a domain or IP address.

Build the URL using a domain name or IP address and a data panel identifier: https://iris.domaintools.com/investigate/search/?q={DOMAIN NAME or IP ADDRESS}&tab=panel-{IDENTIFIER}

Possible data panel identifiers for domain names include:

  • domain-profile
  • domain-history
  • screenshot-history
  • whois-history
  • ssl-profile

Possible data panel identifiers for IP addresses include:

  • ip-profile
  • ip-tools

Example: Creating a URL to domaintools.com screenshot history data panel

https://iris.domaintools.com/investigate/search/?q=domaintools.com&tab=panel-screenshot-history

Example: Creating a URL to 141.193.213.20 IP profile data panel

https://iris.domaintools.com/investigate/search/?q=141.193.213.20&tab=panel-ip-profile

Pivot engine table columns (fields)

By default, the table includes all fields:

  • Domain.
  • Status (active or inactive).
  • Tags.
  • Domain Lifecycle First Seen (when DomainTools first became aware of the current Domain Lifecycle).
  • Domain Risk Score.
  • Email (registrant email).
  • Email domain.
  • Contact Information (registrant, admin, tech, billing, SOA, etc.).
  • Registrant.
  • Registrant Organization.
  • Registrar.
  • Registrar Status.
  • Create Date.
  • Expiration Date.
  • Name Server.
  • IP (Address, ISP, ASN, Country).
  • Trackers – screenshots gather the following web trackers:
  • Google Adsense.
  • Google Universal Analytics.
  • Google Analytics 4.
  • Google Tag Manager.
  • Baidu.
  • Facebook.
  • Hotjar.
  • Matomo.
  • Statcounter.
  • Yandex.
  • Rank.
  • Website Response.
  • Website Title.
  • Server Type.
  • Redirect.
  • Redirect Domain.
  • MX (Mail Exchanger) Information.
  • SSL certificate Hash.
  • SSL certificate Organization.
  • SSL certificate Subject Alt Names.
  • SSL Certificate Issuer.
  • TLD (to enable sorting/filtering by TLD in large result sets).

SSL certificate collection criteria

Collect SSL certificate data

DomainTools employs three separate methods to gather certificate data:

  1. Certificate Transparency Log Certificates. DomainTools constantly monitors industry-known certificate transparency logs to find newly published certificates. The system collects these in parallel with our web crawler and active collection sources and won't replace certificates gathered through the other methods.

  2. Web Crawler. When gathering web-related data on a domain, the web crawler also attempts to collect a certificate from both the apex domain and www subdomain. This certificate can replace the certificate gathered through active collection if it is more recent.

  3. Active certificate crawls. We attempt to gather certificates for domains identified by DomainTools on a weekly basis. Found certificates replace the certificate gathered through web crawl if they are more recent.

Validate certificates

  • For certificates the weekly crawl gathers, we check that the requested hostname is in either the cert's Common Name or Subject Alt Names fields. If the hostname is not present, the system does not collect the certificate.

  • The system gathers certificates regardless of the trustworthiness of the issuing Certificate Authority so the broadest set of certificates is available for analysis.

  • The system gathers all certificates, even when their validity dates are outside of the gathering date.

  • There is no support for certificate revocation in current certificate processing.
  • The quality and security of the checked server's SSL/TLS configuration is not checked: a server may have a valid certificate, but still have a weak SSL/TLS configuration.

For example, consider the self-signed certificates from the SSL Organization "Internet Widgits Pty Ltd".

The certs are self-signed, and cannot be trusted publicly, but Iris Investigate still collects and returns them. Some may find certificates of this sort to be useful indicators, notwithstanding their non-public-trust status.

Iris query quotas and duplicate queries

The system measures quotas at the group level and resets them each month. Understanding what counts as quota consumption helps you optimize your usage of Iris Investigate.

For complete details on quota consumption policies, including duplicate query policies, search hash reloading, and revisiting search nodes, consult the Iris API Rate Limits documentation.

Pivot engine queries in the Iris Investigate UI

The following activities consume your quota:

  • Executing an omnisearch (from landing or search pages) that returns results
  • Executing an advanced search that returns results
  • Sending a result to the Pivot Engine (including narrow, expand, new, and exclude functions)
  • Revisiting a search node more than 30 days since it was created
  • Loading new pages in the Pivot Engine
  • Sorting Pivot Engine results

The following activities do not consume your quota (duplicate queries):

  • Queries with identical filter, sorting, and page parameters made within 30 days of a previous query that counted toward quota
  • Reloading a search hash within 30 days of its creation

Passive DNS (pDNS) queries in the Iris Investigate UI

The following activities consume your quota:

  • Executing a search query that returns results (from either the search field or popovers throughout the UI)
  • Executing/triggering the load more (infinite scroll) function in search results
  • Revisiting a search node more than 30 days since it was created

The following activities do not consume your quota (duplicate queries):

  • Queries with identical parameters (filters, sorting, pagination) made within 30 days of a previous query that counted toward quota

Queries in the Iris Investigate API

The following activities consume your quota:

  • Executing a query
  • Loading additional pages of results

The following activities do not consume your quota (duplicate queries):

  • Identical queries made within 1 hour of a previous query that counted toward quota