DNSDB Scout® is a GUI for the DNSDB® API. Available in all popular web browsers via a website or browser extension, it supports all of the major features of the DNSDB API including:

Until you are accustomed to working with passive DNS, DNSDB Scout’s form and function may seem confusing. The purpose of this guide is to introduce you to Scout and its many features by walking through a few of the most common DNSDB “pivots” and investigative exercises in DNSDB Standard Search. Understanding pivots is critical to utilizing DNSDB to its fullest potential.

Table of Contents

DNSDB API Keys

To use DNSDB Scout you must have a DNSDB API Key.

If you’re already a DNSDB customer then your existing API Key will work just fine. If you don’t have an API Key yet then you should sign up for DNSDB Community Edition https://www.farsightsecurity.com/dnsdb-community-edition/ or a DNSDB API Free Trial key https://www.farsightsecurity.com/trial-api/.

Google Chrome Extensions & Mozilla Firefox Add-ons

If you plan on using DNSDB Scout as a browser extension in either Google Chrome or Mozilla Firefox then the rest of this guide presumes that it’s already installed. If you haven’t installed it, please visit the store page for your respective web browser and install it.

Scout Icon

After the extension has been added to your browser, click the orange Scout icon in the top-right corner to bring up the Scout Popup menu. This is the primary way to open the Scout extension to check on your API key status and to navigate to the Dashboard and Options pages.

Website Version

DNSDB Scout can be accessed by visiting https://scout.dnsdb.info/ in any popular web browser, including on smaller devices like phones and tablets. Accessing DNSDB Scout this way may be preferred or required depending on your device owner’s restrictions, device platform restrictions, or web browser compatibility. Some platforms, such as iOS, do not allow for web browser extensions, and other web browsers may not have a DNSDB Scout extension release available yet.

Setting an API Key in DNSDB Scout

Upon loading up DNSDB Scout for the first time you will likely encounter a message stating that your API Key hasn’t been set yet. DNSDB Scout doesn’t ship with a default API Key so you’ll need to set your own. To do this, visit the Options page by clicking the purple ‘gear’ icon near wherever you saw the warning message.

Set API Key 1

Most users will visit the Options page only once to set and save their API keys. Enter yours into the field and click the Save API Key button.

Set API Key 2

Upon clicking the save button DNSDB Scout will query the default DNSDB server for your API Key status to verify its validity. API Key status checks do not count against your DNSDB query quota and are free of charge.

If your API Key is valid then a confirmation message will appear and the API Status area at the top of the screen will update to resemble one of the following, depending on how your API Key was provisioned. The status will indicate how many DNSDB queries you have left and time until your API Key expires (if applicable):

DNSDB Community Edition Set API Key 3
DNSDB Trial and Standard Editions Set API Key 4

If your API Key isn’t valid then the API status area will revert to the message stating your API Key is expired or hasn’t been set yet. In this case ensure you’ve copy-pasted the correct API Key and try saving it again. If you continue to have trouble setting your API Key please contact our Technical Support team at support@farsightsecurity.com.

Now you may make DNSDB queries on the Dashboard page. Click the DNSDB Scout logo, the link that appeared when you entered your API Key, or the purple search button to go to the Dashboard:

Set API Key 5

Common Pivot & Exercise #1: FQDNs to IP Addresses

Finding the IP Address for a Fully Qualified Domain Name (FQDN) is a simple task for a DNS server – it’s basically what they were made to do. However, the answer you’ll receive from a “regular DNS server” lacks any history and context.

$ dig www.farsightsecurity.com A +short
104.244.13.104

In the example above the dig command can only tell us what a FQDN is resolving to right now and for wherever the DNS server is located. Results from the dig command will be both time and location dependent.

DNSDB can provide a history and global observation for the same data, and thus add context to how a FQDN has resolved over time. To do this in DNSDB Scout for the same FQDN:

  1. Go to the Standard Search tab
  2. Enter www.farsightsecurity.com into the RRSET Domain field
  3. Restrict the RRType field to A records
  4. Click the Search button

Common Pivot 1 Instructions

With the results that appear we can make a timeline of www.farsightsecurity.com has been observed resolving using DNS servers worldwide:

Common Pivot 1 Results

From this simple query we now know how long this subdomain has existed and where it has been before – that’s a very powerful capability!

Common Pivot & Exercise #2: IP Addresses to FQDNs

An IP address is a great starting point for an investigation. With normal DNS you can sometimes find what host currently resides at a given IP address by using in-addr and PTR records.

$ dig -x 104.244.13.104 +short
archive.farsightsecurity.com.

Like in the previous exercise, dig is great for telling us what’s happening now from the perspective of a given DNS server. But what if we want more?

DNSDB can provide the history and context for FQDNs sharing a common IP address. To do this in DNSDB Scout:

  1. Go to the Standard Search tab
  2. Switch over to RData mode from RRSet mode so we can search the right-hand response/answer part of a DNS record instead of the left-hand query part
  3. Select the IP or Network option
  4. Enter 104.244.13.104 into the Record Data field
  5. Click the Search button

Common Pivot 2 Instructions

In the results that appear we can make a list of all of the FQDNs that have been observed resolving to 104.244.13.104.

Common Pivot 2 Results

Utilizing this pivot you may find that hundreds or thousands of domains have shared or are sharing an IP address. Sometimes these may be totally unrelated domains from multiple unrelated owners. Other times you may find that an IP address is commonly used by a single owner for multiple brands, or for hosting a particular theme of traffic – you’ll often be able to see this based on the naming schema of the FQDNs you find.

Caution: The domains you find with this method may not be harmless or may be purposefully misleading. Take precautions if you decide to probe the results outside of DNSDB Scout.

Common Pivot & Exercise #3: IP Address Range to Domain Names

During an investigation it’s helpful to check out an entire netblock instead of IP addresses individually. DNSDB and DNSDB Scout support CIDR range queries to facilitate this. Additionally, it can be useful to only focus on recent activity – this sort of “time fencing” is also supported.

Let’s continue using the recent activity in Farsight’s own address space as an example – let’s see what domain names have been seen using the 104.244.14.108 to 104.244.14.111 address range in the last week.

In DNSDB Scout:

  1. Go to the Standard Search tab
  2. Switch to RData mode like in the previous pivot
  3. Select the IP or Network option
  4. Enter 104.244.14.108/30 into the Record Data field. The CIDR block represents the IP address range above
  5. Expand the Time Fencing section and select a date from a week ago for the ‘Seen After’ option to restrict the query to the last week of obervations.
  6. In this example case, that would be March 25, 2020 12:00 AM UTC
  7. Click the Search button.

Common Pivot 3 Instructions

In the results that appear we can make a list of the domains that have recently been seen using the given address range over the last week.

Common Pivot 3 Results

This pivot is also called the “Know Your Neighborhood” exercise. By exploring a netblock you may find new names you didn’t know about previously and get a better feel for what a “neighborhood” of the Internet is like – however, explore with skepticism as any domain name owner can point one of their hostnames “at” any IP address of their choice and generate traffic.

Caution: Keep in mind the Count and UTC Dates of the data you find; you may need to interpret your results differently depending on the frequency and time range. A low frequency result from a long time ago may be a “test” server, and spikes over short time ranges could be worth a closer look. UTC Dates can also blend together if you’re not reading closely; check both the Time Last Seen and Time First Seen columns before making a conclusion about a FQDN and its activity in regard to your investigation.

Common Pivot & Exercise #4: Subdomain Wildcards

While investigating a domain you may need to create a map of unknown subdomains and hostnames. Normally this could be challenging, but DNSDB and DNSDB Scout significantly simplify this task.

To perform a subdomain and hostname search in DNSDB Scout:

  1. Go to the Standard Search tab
  2. Enter a domain with a subdomain wildcard in front of it – in this example we’ll use *.farsightsecurity.com in the RRSet Domain field. Wildcards like this can be placed at either end of a FQDN or label, but not both.
  3. Restricting the Record Types to A, AAAA, or CNAME will help add some clarity – intermingled record types can be hard to parse if you’re not familiar with all of their uses. For this exercise we’ll restrict the Record Types to A records
  4. Additionally restricting the query to a specific time range will also add clarity. Open the Time Fencing Section
  5. Set a ‘Seen After’ time fence for observations after January 1, 2020 12:00 AM UTC
  6. Click the Search Button

Common Pivot 4 Instructions

The results that appear can be sorted for increased readability – click the RRName heading to alphabetize the results. With sorted results we now have a list of subdomains and hostnames observed since the beginning of 2020.

Repeat this pivot with a different Record Type (AAAA, CNAME, or ANY) for a different view of the observed traffic.

Common Pivot 4 Results

Common Pivot & Exercise #5: Hosts Using A Shared Name Server

Another way to discover associated hostnames beyond subdomains and IP addresses is to explore shared name servers. This is a two-step pivot and can lead to a lot of results.

In this example we’ll go through the exercise while examining the Smithsonian Institution’s domains from the starting point of si.edu.

Let’s set up the first step of this pivot – finding a name server.

  1. Go to the Standard Search tab
  2. Enter si.edu into the RRSET Domain field
  3. Restrict the Record Type to NS
  4. Set the Limit to 1000 (optional)
  5. Click the Search Button

Common Pivot 5 Instructions

The most recent observation for this example should be a high-count name server record with the data: si-names1.si.edu. and si-names2.si.edu.

Common Pivot 5 Results 1

Hover over the first name server and it’ll present you with a pivot tooltip. In the tooltip will be a number of pivot options. Clicking second pivot option, which says Standard for RData (name): si-names1.si.edu., will perform the next step of this exercise automatically – DNSDB Scout will search for an RData Name matching si-names1.si.edu. while also using the Record Type and Limit fields we set earlier. The query form at the top of the page will change automatically, and the results will be displayed in the table. Click the pivot link to proceed.

Common Pivot 5 Results 2

The results that appear after clicking the pivot link can be sorted for increased readability – click the RRName heading to alphabetize the results. With the sorted results we now have a large list of hosts and domains to paginate through that use si-names1.si.edu. as a shared name server.

Running this pivot in two steps isn’t required. If you already have a name server to start with then you may enter it as a name in an RData query to skip step one.

  1. Go to the Standard Search tab
  2. Switch to RData mode
  3. Enter the name server into the Record Data field
  4. Click the Search Button

Common Pivot 5 Results 3

Common Pivot & Exercise #6: Hosts Using A Shared MX Server

Similar to the previous exercise, another way to discover associated hostnames is to explore shared mail servers. This is also a two-step pivot that could yield a lot of results depending on the starting domain.

In this example we’ll go through the exercise while examining the University of Oregon’s mail server and domains, starting from uoregon.edu.

Let’s set up the first step of this pivot – finding a mail server

  1. Go to the Standard Search tab
  2. Enter uoregon.edu into the RRSET Domain field
  3. Restrict the Record Type to MX
  4. Set the Limit to 1000 (optional)
  5. Click the Search Button

Common Pivot 6 Instructions

In the most recent observation for this example should be a high-count MX record with mxa-000bfd01.gslb.pphosted.com. in the record data.

Common Pivot 6 Results

Hover over the mailserver and it’ll present you with a pivot tooltip. In the tooltip will be a number of pivot options. Clicking second pivot option, which says Standard for RData (name): mxa-000bfd01.gslb.pphosted.com., will perform the next step of this exercise automatically – DNSDB Scout will search for an RData Name matching mxa-000bfd01.gslb.pphosted.com. while also using the Record Type and Limit fields we set earlier. The query form at the top of the page will change automatically, and the results will be displayed in the table. Click the pivot link to proceed.

The results that appear can be sorted for increased readability – click the RRName heading to alphabetize the results. With the sorted results we now have a list of hosts and domains that use mxa-000bfd01.gslb.pphosted.com. as a shared mail server.

Common Pivot 6 Results 2

Like in the previous exercise, running this pivot in two steps isn’t required. If you already have a mail server to start with then you may enter it as a name in an RData query to skip step one.

  1. Go to the Standard Search tab
  2. Switch to RData mode
  3. Enter the mail server into the Record Data field
  4. Click the Search button

Common Pivot 6 Results 2

Common Pivot & Exercise #7: Hosts Using a Shared CNAME

Similar to the previous two exercises, another way to discover associated domains is to explore shared CNAMEs. This is another two-step pivot that could yield a lot of results depending on the starting domain.

In this example we’ll go through the exercise starting from the University of Oregon’s website, www.uoregon.edu.

Let’s set up the first step of this pivot – finding a CNAME

  1. Go to the Standard Search tab
  2. Enter www.uoregon.edu into the RRSET Domain field
  3. Restrict the Record Type to CNAME
  4. Set the Limit to 1000 (optional)
  5. Click the Search Button.

Common Pivot 7 instructions

In the most recent observation for this example should be a CNAME record with drupal-hosting-web-cluster5-prod.uoregon.edu. in the record data.

Common Pivot 7 results 1

Hover over the CNAME and it’ll present you with a pivot tooltip. In the tooltip will be a number of pivot options. Clicking second pivot option, which says Standard for RData (name): drupal-hosting-web-cluster5-prod.uoregon.edu., will perform the next step of this exercise automatically – DNSDB Scout will search for an RData Name matching drupal-hosting-web-cluster5-prod.uoregon.edu. while also using the Record Type and Limit fields we set earlier. The query form at the top of the page will change automatically, and the results will be displayed in the table. Click the pivot link to proceed.

The results that appear can be sorted for increased readability – click the RRName heading to alphabetize the results. With the sorted results we now have a list of hosts and domains that use drupal-hosting-web-cluster5-prod.uoregon.edu. as a shared CNAME.

Common Pivot 7 results 2

Notably, in this case we see enumerated subdomains and CNAMEs – there may be a www3.uoregon.edu. or a drupal-hosting-web-cluster4-prod.uoregon.edu. that could be worth investigating in subsequent queries. This is one of many patterns to watch for when investigating subdomains and CNAMEs.

Like in the previous two exercises, running this pivot in two steps isn’t required. If you already have a CNAME to start with then you may enter it as a name in an RData query to skip step one.

  1. Go to the Standard Search tab
  2. Switch to RData mode
  3. Enter the CNAME into the Record Data field
  4. Click the Search Button

Common Pivot 7 post results

Common Pivot & Exercise #8: TLD and Suffix Wildcarding

DNSDB supports wildcards before or after a given search parameter – this is particularly useful when searching for similar names across multiple TLDs and suffixes.

For example, www.paypal.com is a well-known website – but has www.paypal recently appeared on any other TLDs and suffixes besides .com? Let’s find out.

In DNSDB Scout:

  1. Go to the Standard Search tab
  2. Enter www.paypal.* into the RRSet Domain field to set up a right-hand wildcard query
  3. Open the Time Fencing section
  4. Set a ‘Seen After’ Time Fence for the last couple of days. In this example case April 1, 2020 12:00 AM UTC will be used
  5. Click the Search Button

Common Pivot 8 instructions

Note: Right-hand wildcard queries take longer than other queries because of the large amount of data DNSDB is searching. Results for right-hand wildcard queries may take some time to appear. The results for this query can be highly varied depending on RRType, Time Fencing, and current events. Try lowering the Limit to decrease the amount of time these queries take.

In the results that appear we can make a list of all the domains, subdomains, and hosts that match our query.

Caution: A common use case for this pivot is to search for domains and websites that look similar to a canonical/real one. The domains and hosts you find with this method may not be harmless or may be purposefully misleading. Take precautions if you decide to probe the results outside of DNSDB Scout.

Common Pivot 8 results

Common Pivot & Exercise #9: Punycode, Unicode, and Internationalized Domain Name Conversions

DNSDB Scout Standard Search supports converting Internationalized Domain Names (IDNs) containing Unicode and Unicode suffixes to ASCII by way of Punycode.

For example, the domain bbc.在线 is used to host an instance of a BBC news website. The suffix, 在线, is an internationalized domain name suffix meaning “online” in simplified Chinese. The characters 在线 are written in Unicode, but to make it usable in DNS something called “punycode” is used as a conversion layer. With Punycode, this Unicode suffix is converted to xn--3ds443g. In DNS, all IDN conversions will begin with xn--.

For more information about the What/How/Whys of IDNs and Punycode, we recommend:

The Standard Search Domain tooltip has an indicator of whether or not your web browser has allowed Punycode conversions to work. By default, all major web browsers will allow it, but some script blockers may disable it and a warning will appear.

Common Pivot 9 instructions

As an exercise, try entering an IDN into Scout as part of a basic RRSet Domain query. If you don’t know one off the top of your head, try bbc.在线.

Common Pivot 9 instructions 2

IDNs, Unicode, homoglyphs, and non-ASCII characters may come up in investigations that would stump other tools. DNSDB Scout will automatically convert these using Punycode for use in DNSDB queries.

Even if you don’t intend to go on to make a real query, DNSDB Scout can be used as a convenient convert-to-punycode tool.

Feature Explanation: Recent Queries

DNSDB Scout stores your DNSDB queries locally, via your web browser’s cache. This is convenient for re-running and loading previous queries, but this may also be something you’ll want to explicitly clear if you’re conducting a sensitive investigation on a shared system.

Some web browsers will automatically prune your Recent Query cache; if not, DNSDB Scout will self-prune whenever 2GB of queries have been stored or 75 queries have been made (the specific details of the pruning process will depend on which web browser you’re using).

To review queries you’ve previously made, click the “Recent Queries” tab in the Dashboard.

Recent Queries

In the Recent Queries tab is a table that shows all of your previous queries.

Recent Queries 2

Each query has a few functions:

At the top-right of the Recent Queries tab is a button to clear the Recent Queries completely. If your Recent Queries are taking a while to load then you may want to clear them manually.

Feature Explanation: Time Fencing

Time Fencing is used to improve the signal to noise ratio of results by filtering results to specific time ranges that are more relevant to an investigation or event.

Time Fencing is controlled by a set of three query parameters, all of which are optional:

By itself, the Seen After parameter defines a ‘soft’ limit for a date range and kicks off a ‘Last Seen After’ query where observations have a Last Seen date sometime after the date specified. When the Strict Mode is enabled, the Seen After parameter defines a ‘hard’ limit and kicks off a ‘First Seen After’ query where observations have a First Seen date sometime after the date specified. These types of queries are exclusive; you cannot use both a ‘Last Seen After’ and ‘First Seen After’ query at the same time.

Time Fence Last Seen

Similarly, the Seen Before parameter define a ‘soft’ limit for a date range and kicks off a ‘First Seen Before’ query where observations have a First Seen date sometime before the date specified. When the Strict Mode is enabled, the Seen Before parameter defines a ‘hard’ limit and kicks off a ‘Last Seen Before’ query where observations have a Last Seen date sometime before the date specified. These types of queries are exclusive; you cannot use both a ‘First Seen Before’ and ‘Last Seen Before’ query at the same time.

Time Fence First Seen

Using both Seen After and Seen Before parameters together define a left bound and right bound date range for query results, and the Strict Mode defines their strictness. When looking at a timeline, the Seen After is used as the left bounding parameter while Seen Before is used as the right bounding parameter. Results that appear in-between satisfy the either the Seen After parameter, the Seen Before parameter, or both simultaneously.

Time Fence Hard

Time Fence Soft

In DNSDB Scout the Time Fencing parameters have their own section. Click the [+] Time Fencing header to expand the section. Once expanded, the fields for entering the Seen After and Seen Before parameters will appear. Click the header again to hide the section.

Time Fence 1

Time Fence 2

DNSDB and DNSDB Scout operate using Coordinated Universal Time (UTC); when selecting a Time Fencing date it will be in UTC.

Click a Time Fencing field to open a date picker – in order, select the Year, Month, Day, Hour, and Minute for the date you want. DNSDB Scout also supports Unix timestamp conversion. Typing or pasting in a Unix timestamp will automatically convert it to a human readable date. For example, copy-pasting 1577959872 into a field will result in January 2, 2020 10:11 AM.

The Clear button in the Time Fencing section only applies to the Time Fencing fields. Use this to quickly clear Time Fencing parameters between queries as needed.

For a more in-depth exploration into DNSDB Time Fencing we recommend

Feature Explanation: Exporting to CSV, JSON, and PDF/Print

After running a successful query or loading a query from the Recent Query tab a table of results will appear on the main Dashboard. Just above the results is an ‘Export’ dropdown – the CSV option will export the current table to a CSV file while the JSON option will export the current table to a JSON file. The PDF/Print option will take you to a new tab to help optimize the table results for paper-like formats. If you have filtered your results using the fields just above the table then the ‘Export Filtered’ options will be enabled. Your browser will handle the file exporting process and will store it in your default downloads directory.

Exporting to CSV, JSON, and PDF/Print

Use these export options to transfer your query results to another tool and format.

Summary

If you’ve followed this guide to the end then you should now be familiar with all of DNSDB Scout’s major features as well as the more common DNSDB pivots. We hope that it has been both enlightening and useful.

If you have any feedback or would like to see us break down more complicated DNSDB pivots in the future please let us know at: https://www.farsightsecurity.com/about-farsight-security/contacts/.

Glossary of Acronyms and Terms

References

The greater part of this guide was adapted from Joe St Sauver’s 8 Common DNSDB “Pivots” for Threat Hunting:

For more information about IDNs, Homographs, and Punycode please see Mike Schiffman’s Farsight Security Global Internationalized Domain Name Homograph Report:

For more information about DNSDB Time Fencing please see Joe St Sauver’s Farsight’s DNSDB Time Fencing: A Post-Attack “Time Machine”:

About Farsight Security

Farsight Security, Inc. is the world’s largest provider of historical and real-time DNS intelligence solutions. We enable security teams to qualify, enrich and correlate all sources of threat data and ultimately save time when it is most critical - during an attack or investigation. Our solutions provide enterprise, government and security industry personnel and platforms with unmatched global visibility, context and response. Farsight Security is headquartered in San Mateo, California, USA. Learn more about how we can empower your threat platform and security team with Farsight Security passive DNS solutions at www.farsightsecurity.com or follow us on Twitter: @FarsightSecInc.