DNSDB Scout pivot tutorials

This guide walks through common DNSDB "pivots" and investigative exercises using DNSDB Scout. Understanding pivots is critical to utilizing DNSDB to its fullest potential.

A pivot is a sequential step between two sets of data, linked by some common factor or shared data element. Exploring DNSDB usually takes the form of following pivots to discover relationships between domains, IP addresses, and DNS infrastructure.

Prerequisites

Before starting these tutorials, ensure you have:

• A valid DNSDB API key configured in DNSDB Scout
• Access to DNSDB Scout (via website or browser extension)
• Basic understanding of DNS concepts (domains, IP addresses, record types)

See the DNSDB Scout user guide for setup instructions.

Tutorial overview

Tutorial	What you'll learn	Difficulty
#1: FQDNs to IP addresses	Find IP resolution history for a domain	Beginner
#2: IP addresses to FQDNs	Discover domains hosted on an IP	Beginner
#3: IP address ranges	Explore entire netblocks	Intermediate
#4: Subdomain wildcards	Map unknown subdomains	Intermediate
#5: Shared name servers	Find domains using same NS	Intermediate
#6: Shared MX servers	Find domains using same mail server	Intermediate
#7: Shared CNAMEs	Discover CNAME relationships	Intermediate
#8: TLD wildcarding	Search across multiple TLDs	Advanced
#9: Punycode/IDN	Work with international domains	Advanced

Pivot #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 are 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

The results that appear give us a timeline of what www.farsightsecurity.com been resolved to using DNS servers worldwide:

• Currently resolves to 104.244.14.13
• Previously resolved to 104.244.14.95 from Aug 2020 to Jan 2021
• Previously resolved to 104.244.14.108 from Sep 2018 to Aug 2020
• Previously resolved to 104.244.13.104 from Apr 2015 to Sept 2018
• Previously resolved to 66.160.140.81 from Sept 2013 to Apr 2015
• Previously resolved to 149.20.4.207 from Jul 2013 to Sept 2013

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!

Pivot #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

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.

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.

Pivot #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 a recent activity 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 observations
6. In this example case, that would be March 24, 2023 12:00 AM UTC
7. Click the Search button

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.

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.

Pivot #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, 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, 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

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.

Pivot #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.

This exercise examines the Smithsonian Institution's domains from the starting point of si.edu.

Step 1: Find 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

A 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.

Step 2: Find domains using that name server

Hover over the first name server and it'll present you with a pivot tooltip. In the tooltip are a number of pivot options. Clicking second pivot option, which says Standard for RData (name): si-names1.si.edu., performs the next step of this exercise automatically -- DNSDB Scout searches 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 changes automatically, and the results are displayed in the table. Click the pivot link to proceed.

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.

Alternative: Direct search

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

Pivot #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.

This exercise examines the University of Oregon's mail server and domains, starting from uoregon.edu.

Step 1: Find 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

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.

Step 2: Find domains using that mail server

Hover over the mailserver and it'll present you with a pivot tooltip. In the tooltip are a number of pivot options. Clicking second pivot option, which says Standard for RData (name): mxa-000bfd01.gslb.pphosted.com., performs the next step of this exercise automatically -- DNSDB Scout searches 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 changes automatically, and the results are 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.

Alternative: Direct search

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

Pivot #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.

This exercise starts from the University of Oregon's website, www.uoregon.edu.

Step 1: Find 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

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

Step 2: Find domains using that CNAME

Hover over the CNAME and it'll present you with a pivot tooltip. In the tooltip are a number of pivot options. Clicking second pivot option, which says Standard for RData (name): drupal-hosting-web-cluster5-prod.uoregon.edu., performs the next step of this exercise automatically -- DNSDB Scout searches 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 changes automatically, and the results are 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.

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.

Alternative: Direct search

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

Pivot #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 March 17, 2023 12:00 AM UTC is used
5. Click the Search Button

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.

Pivot #9: Punycode, unicode, and internationalized domain names

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 begin with xn--.

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

• Global Internationalized Domain Name Homograph Report

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 allows it, but some script blockers may disable it and a warning appears.

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.在线.

IDNs, Unicode, homoglyphs, and non-ASCII characters may come up in investigations that would stump other tools. DNSDB Scout automatically converts 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.

Next steps

Now that you've learned the common DNSDB pivots, you can:

• Explore the DNSDB Scout user guide for detailed feature explanations
• Learn about Flexible Search for advanced query capabilities
• Review the DNSDB API documentation for programmatic access

References

• Joe St Sauver's 8 Common DNSDB "Pivots" for Threat Hunting
• DNSDB Time Fencing: A Post-Attack "Time Machine"