Why Do Incident Responders and Other Investigators Focus on Particular DNS Record Types?

1. Introduction

In a previous blog post, “A Quick Overview of the Top Seven DNS Record Types”, we described a number of common DNS record types that are available in DNSDB.

What we DIDN’T discuss is WHY investigators look at particular record types as they work with passive DNS.

Why “A” records? Why “NS” records? Etc.

This blog post is meant to help fill that gap. Before we dive in, let’s just quickly recap a few key points:

• To use passive DNS, you need an initial “clue” or “starting point.” How you find that initial “clue” is up to you — it may be a domain you saw in a spam or phishing email, an IP address you saw in a firewall log or a malware writeup, or maybe your starting point is something you found in a web search engine. Whatever it may be, it’s up to you to uncover that initial starting point for your investigation.
• For example, we recently looked at Joe Wein’s blocklist log page. He lists a number of name servers that he refers to as “rogue-ns” on his bl-log.htm page. On that page, Joe Wein explains that a “rogue-ns” is:

Same as ns= except that the server is known to host multiple spam domains. In some cases it may be under the control of spammers or its owners tolerate clients who send spam (often advertised as “bullet-proof hosting.”)

With that quick recap out of the way, let’s dig into the record types that investigators often actually use.

2. “The Basics:” “A” Records, “AAAA” Records, and “CNAME” Records

Once you’ve got an initial lead, such as a fully qualified domain name (FQDN) or an IP address, you’ll normally look up that initial lead in DNSDB. When you do, you’ll usually make a very broad query, e.g., you WON’T ask for just a single specific record type.

So what record types will you normally see by default in the response to such a query?

• When you look up a FQDN in DNSDB, you’ll usually see one or more “A” records, showing the IPv4 address (or addresses) where the FQDN has been hosted.
• Sometimes, you may also see one or more “AAAA” records (if the site also does IPv6).
• For example, let’s look at our sample FQDN with

dnsdbq

• . When we do so we see:

$ dnsdbq -r ns101.mngsysdns[dot]net -S -k last | more
;; record times: 2019-08-29 02:28:18 .. 2019-11-01 14:42:47
;; count: 1135881; bailiwick: mngsysdns[dot]net.
ns101.mngsysdns[dot]net. A 148[dot]59.57.12

;; record times: 2019-08-29 01:51:02 .. 2019-11-01 14:00:41
;; count: 351573; bailiwick: net.
ns101.mngsysdns[dot]net. A 148[dot]59.57.12
​[etc]


• [Those two results might superficially look as if they’re “duplicates,” but if you look closely at the highlighted text, you’ll see that they’re NOT — the records have different bailiwicks, as discussed previously in this blog post
• Anyhow, we now have an IP address associated with our domain name — it’s

148[dot]59.57.12

• (as highlighted in the above output.)
• Just as a check on the Joe Wein listing, let’s also see what Spamhaus says. When we do, we can see that that IP address is listed by them (which points to this).
• Having gotten an IP address, the “typical” next step would be to look it up in DNSDB to see what, if anything, may also be hosted on that IP address. This is an example of a “pivot”, as discussed in a previous blog article

$ dnsdbq -i 148[dot]59.57.12 -l 1000000 -S -k count | more
;; record times: 2019-08-29 01:51:02 .. 2019-11-01 16:12:46
;; count: 1487843
ns101.mngsysdns[dot]net. A 148[dot]59.57.12

;; record times: 2019-08-29 01:55:34 .. 2019-11-01 16:12:46
;; count: 1485321
ns103.mngsysdns[dot]net. A 148[dot]59.57.12

;; record times: 2019-08-29 01:51:56 .. 2019-11-01 16:12:46
;; count: 1484524
ns102.mngsysdns[dot]net. A 148[dot]59.57.12

;; record times: 2019-09-01 08:14:52 .. 2019-10-28 15:32:53
;; count: 42
mngsysdns[dot]net. A 148[dot]59.57.12

;; record times: 2019-09-22 02:42:40 .. 2019-10-16 04:56:37
;; count: 8
ns01.xwqfcdf6u[dot]okinawa. A 148[dot]59.57.12
​[etc]


• Given the large counts associated with the top names shown there, clearly this IP address plays an important role for the three name servers listed (although there are also hundreds of other domains that use that IP too, including the random-looking dot okinawa domain shown above)
• Other times, when querying a FQDN in DNSDB, you may run into a CNAME. A CNAME is a DNS RRname that points to another RRname instead of to an IP address. In that case, you’ll need to “chase” (“follow”) the CNAME chain before you’ll have a FQDN that you can resolve to an actual IP address.
• A third possibility is that you may simply have a starting IP address (rather than a starting FQDN) as your “clue.” In that case, you’d search DNSDB for that IP address, in the hope of finding one or more domain name you might then proceed to scrutinize.

The point of all this is that an initial user doing a default passive DNS search for a FQDN or IP address will normally end up with answers consisting of “A“, “AAAA“, or “CNAME” record types.

Other record types may also turn up for a FQDN, but the “A“, “AAAA“, and “CNAME” record types are the ones that will most commonly be seen for most initial DNSDB queries. Those record types are the “bread and butter”/”meat and potatoes” of many passive DNS investigations.

3. Broadening Your Search

Once the analyst has conducted an initial DNSDB search for their “starting clue,” the next thing an investigator will usually do is to broaden that search:

• If the starting clue was a FQDN (such as www.example.com), the next step will often be for the wildcarded version of that domain (e.g., *.example.com).
• If the initial clue was an IP address, the investigator will often find the FQDNs known to use that IP as a first step, and then conduct a wildcard search on each of those domains as his or her next step (or perhaps investigate the other IPs in a small range around the initial IP address (e.g., perhaps he’ll scrutinize a /24 netblock (256 addresses))).

For now, since we started with a FQDN, let’s “follow the process” for that, and make a wildcard search for

*.mngsysdns[dot]net

. That sort of search will often be productive because it lets you discover unexpected FQDNs that may be present, and it also gives you a sense of the record types that a site actually uses.

For domains with thousands or tens of thousands of records in DNSDB, you’ll probably want to explicitly tabulate the record types that are in use. One way to do that is with dnsdbq and jq:

$ dnsdbq -r \*.mngsysdns[dot]net -l 1000000 -j -A90d | jq -r '.rrtype' | sort | uniq -c | sort -nr
8733 SOA
1384 A
2 TXT
2 NS


SOA records will be discussed in a future blog article. For now, disregard them. In this case, that leaves us largely with “A” records, a couple of NS records, and a couple of TXT records.

The TXT records in this case were used for SPF:

$ dnsdbq -r \*.mngsysdns[dot]net/TXT
;; record times: 2019-09-15 20:20:12 .. 2019-09-15 20:20:12
;; count: 2; bailiwick: mngsysdns[dot]net.
mngsysdns[dot]net. TXT "v=spf1 +ip4:148[dot]59.57.128 +ip4:148[dot]59.57.10 +ip4:148[dot]59.57.12 +ip4:148[dot]59.57.11 +ip4:210[dot]236.167.180 ~all"

;; record times: 2019-08-20 18:11:50 .. 2019-08-20 18:11:50
;; count: 2; bailiwick: mngsysdns[dot]net.
mngsysdns[dot]net. TXT "v=spf1 +ip4:219[dot]117.249.58 +ip4:219[dot]117.249.59 +ip4:219[dot]117.249.60 +ip4:219[dot]117.249.61 +ip4:210[dot]236.167.180 ~all"


We’ll talk a little about TXT SPF records later in this talk.

So coming back to “A” records, since that’s the “lion’s share” of the resource records once we set aside SOAs, what do the most-commonly-seen “A” records look like in this case? Let’s see what’s there for the last 90 days:

$ dnsdbq -r \*.mngsysdns[dot]net -l 1000000 -j -A90d | grep '"rrtype":"A"' | \
jq -r '"\(.count) \(.rrname)"' | sort -nr
1135881 ns101.mngsysdns[dot]net.
1133392 ns103.mngsysdns[dot]net.
1132563 ns102.mngsysdns[dot]net.
1013009 ns301.mngsysdns[dot]net.
1009570 ns302.mngsysdns[dot]net.
1008764 ns303.mngsysdns[dot]net.
833031 ns403.mngsysdns[dot]net.
832804 ns402.mngsysdns[dot]net.
832571 ns401.mngsysdns[dot]net.
786083 ns401.mngsysdns[dot]net.
785816 ns403.mngsysdns[dot]net.
785805 ns402.mngsysdns[dot]net.
​[etc]


Those name server FQDN counts are obviously quite large! 

4. Drilling Down Further

Most analysts would now like to know, “So what domains USE

ns101.mngsysdns[dot]net

(and/or one of the other name servers mentioned in Section 3) as their name servers?”

This sort of pivot requires us to search the right-hand side of NS records for

ns101.mngsysdns[dot]net

(and/or the other name servers mentioned in Section 3).

That means making “

dash n

” (rather than “

dash r

“) queries with

dnsdbq

.

Even looking at just unique RRnames seen for one of those name servers (

ns101.mngsysdns[dot]net

) and even time fencing that query to the last 90 days, we still find quite a few domains that are using that name server:

$ dnsdbq -n ns101.mngsysdns[dot]net/NS -l 1000000 -j -A90d | jq '.rrname' | sort | uniq | wc -l
10899


Exploring the domain names from that set that have the highest counts, we see:

$ dnsdbq -n ns101.mngsysdns[dot]net/NS -l 1000000 -A90d -S -k count | more
;; record times: 2019-06-03 16:14:53 .. 2019-10-31 02:01:43
;; count: 96097
gogopoint76482[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 15:33:32 .. 2019-11-01 08:23:22
;; count: 95515
0p417-v35zrwjk9[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-12 12:15:02 .. 2019-11-01 14:20:20
;; count: 95243
fl49ng3md0-1s68r[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-12 19:28:04 .. 2019-11-01 14:13:51
;; count: 90716
w38o-sd940c26ug[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 17:03:33 .. 2019-11-01 11:13:07
;; count: 69932
1brv65s09t7o[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 16:48:26 .. 2019-11-01 12:15:10
;; count: 69671
wb25z9ul8s34[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 15:18:39 .. 2019-11-01 14:14:50
;; count: 69500
12qo7vfh5n34j[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 17:18:27 .. 2019-11-01 12:15:12
;; count: 68680
xg1htm5z60f23n9[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 17:33:26 .. 2019-11-01 14:13:54
;; count: 67964
8i06hx9dv-w41[dot]com. NS ns101.mngsysdns[dot]net.

;; record times: 2019-09-10 16:33:30 .. 2019-11-01 13:20:14
;; count: 67267
2j3t8lmox69p47[dot]com. NS ns101.mngsysdns[dot]net.
​[etc]


Most of those discovered names seem “atypical” to us (being rather “random”/”algorithmic” in appearance).

5. “Drilling Horizontally:” Following an Opportunistic Lateral Pivot From One NS to Another

Sometimes an initial set of results like the ones we just saw in section 4 will suggest a natural “lateral” pivot when an “identified-as-interesting” domain moves from an old shared resource to a new shared resource.

For example, in this example,

gogopoint76482[dot]com

changed from using

ns101.mngsysdns[dot]net

to using

ns501.mmmserver[dot]com

on November 1st, 2019. That move provided a link to a new name server that may also be of interest, and a diligent investigator will add new discoveries of that sort to his or her list of names to review.

That new name server obviously also is associated with an IP address (

ns501.mmmserver[dot]com

–>

103.243.211.98

). In this case, because that IP is also a new-to-this-investigation address, it would also be something new to potentially review.

Checking to see what other domains also use

ns501.mmmserver[dot]com

as their name server, we again see heavily random/algorithmic-looking domains:

$ dnsdbq -n ns501.mmmserver[dot]com/NS -l 1000000 -A90d -S -k count | more
;; record times: 2019-10-31 11:20:18 .. 2019-11-01 15:27:38
;; count: 1310
24ro91z-lj7bh80[dot]com. NS ns501.mmmserver[dot]com.

;; record times: 2019-10-31 11:20:17 .. 2019-11-01 16:56:39
;; count: 1086
y9k-3a748dw0b[dot]com. NS ns501.mmmserver[dot]com.

;; record times: 2019-10-31 11:35:38 .. 2019-11-01 15:06:10
;; count: 1018
02-z7x68frwq4o3e[dot]com. NS ns501.mmmserver[dot]com.

;; record times: 2019-10-31 11:20:18 .. 2019-11-01 15:51:26
;; count: 733
63xko5cm9n0-4hd1[dot]com. NS ns501.mmmserver[dot]com.

;; record times: 2019-10-31 11:23:05 .. 2019-11-01 17:27:53
;; count: 686
m04hdc58-x9n2[dot]com. NS ns501.mmmserver[dot]com.

;; record times: 2019-10-31 13:05:30 .. 2019-11-01 15:49:15
;; count: 606
h35y19-lbp0q6c[dot]com. NS ns501.mmmserver[dot]com.

;; record times: 2019-10-31 13:19:50 .. 2019-11-01 17:20:57
;; count: 576
xk0g1-c2e94l68a[dot]com. NS ns501.mmmserver[dot]com.
​[etc]


So now what about that new IP address we saw in use by this new name server?

ns501.mmmserver[dot]com

is on that IP, but let’s check and see what else is ALSO on

103.243.211.98

. Could there be additional name servers there? Yep, turns out that there are:

$ dnsdbq -i 103.243.211.98 -l 1000000 -S -k count | more
;; record times: 2019-10-06 16:11:54 .. 2019-11-01 16:31:17
;; count: 11375
ns501.mmmserver[dot]com. A 103[dot]243.211.98

;; record times: 2019-10-06 16:11:54 .. 2019-11-01 17:20:15
;; count: 11366
ns502.mmmserver[dot]com. A 103[dot]243.211.98

;; record times: 2019-10-06 16:11:54 .. 2019-11-01 16:31:17
;; count: 11296
ns503.mmmserver[dot]com. A 103[dot]243.211.98
​[etc]


6. Bringing It All Together

So this is probably a good point to bring everything we’ve talked about so far together if we can. Specifically, how many unique delegation points (“base domain names”) do we find for all these name servers?

To check, we’ll run the following set of commands:

$ dnsdbq -l 1000000 -n ns101.mngsysdns[dot]net > multiple-nss.txt
$ dnsdbq -l 1000000 -n ns102.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns103.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns201.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns202.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns203.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns301.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns302.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns303.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns401.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns402.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns403.mngsysdns[dot]net >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns501.mmmserver[dot]com >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns502.mmmserver[dot]com >> multiple-nss.txt
$ dnsdbq -l 1000000 -n ns503.mmmserver[dot]com >> multiple-nss.txt


Once those commands have finished running, we’ll process their output. We just want to keep the first column (e.g., the column with the domain names), dropping any comment lines or blank lines, and eliminating all trailing periods:

$ awk '{print $1}' < multiple-nss.txt | grep -v ";;" | grep -v "^$" |
sed 's/\.$//' > multiple-nss-2.txt


We’ll then sort and uniq’ify those results, reversing them “by label” with a tiny script called reverse-domain-names, sorting them in that form, and then re-reversing them back to normal label order for ease of reading:

$ sort multiple-nss-2.txt | uniq | reverse-domain-names | sort |
reverse-domain-names > multiple-nss-3.txt


The reverse domain-names script used in the preceding command pipeline is short, looking like:

#!/usr/bin/perl

my @lines = <>;
chomp @lines;

@lines =
map { join ".", reverse split /\./ }
sort
@lines;

print "$_\n" for @lines;


So all of the above mechanics aside, how many unique base domains do we find for all those name servers? E.g., how big is the output file multiple-nss-3.txt?

$ wc -l multiple-nss-3.txt
299799 multiple-nss-3.txt


That’s a LOT of unique-but-related domains (even if many of those names are from new gTLDs where domains are being sold at “fire sale prices” of a buck or less for the first year).

7. What About Other Record Types?

While the “mainstream” investigation illustrated above uses a relatively small number of record types, other record types may play important roles under different circumstances — it all depends on what common points of overlap exist to tie sets of domains together, and sometimes even how those records are written.

The record type tabulation described in section 3 will often give you a clue as to what record type directions to explore.

A few other points to note:

• Some record types are quite obscure — merely USING a given obscure record type may be enough to end up “standing out” and garnering an analyst’s interest. For example, the use of NULL record types for DNS tunneling is what caught our eye and inspired this earlier blog post
• Other times, a given actor may use a common DNS record type, but do so in a way that “stands out” because it is so contrary to generally-accepted practice.

For example, an analyst may notice TXT records defining SPF records, and that’s perfectly normal, as far as that goes. Those SPF records will normally use small, carefully-tailored IP address ranges in an effort to minimize the potential attack surface for spoofed emails.

Occasionally, however, you may see SPF records with unusually LARGE network blocks, potentially even including:

• IPv4 /8’s (16,777,216 addresses)
• IPv4 /9’s (8,388,608 addresses)
• IPv4 /10’s (4,194,304 addresses)
• IPv4 /11’s (2,097,152 addresses)
• IPv4 /12’s (1,048,576 addresses)

Some examples of this:

v=spf1 ip4:18.139.193.33/12 ip4:35.173.60.89/8 ip4:52.95.223.76/18 ip4:52.95.230.219/18 ip4:3.0.182.56/12 ip4:52.58.30.221/12 ip4:35.149.253.107/10 ip4:18.129.52.255/10 ip4:52.94.248.199/24 ip4:49.156.168.157/19 ~all

v=spf1 ip4:18.137.117.69/8 ip4:49.156.182.239/20 ip4:18.130.49.245/16 ip4:3.19.77.74/11 ip4:52.94.248.246/24 ip4:35.176.178.229/13 ip4:52.95.212.193/18 ip4:52.93.204.191/11 ip4:52.57.253.79/13 ip4:35.27.137.199/8 ~all

v=spf1 ip4:18.135.140.76/9 ip4:185.74.50.199/9 ip4:34.170.32.52/9 ip4:99.82.241.95/13 ip4:54.113.251.188/8 ip4:63.8.176.248/9 ip4:79.96.53.250/9 ip4:52.150.87.53/8 ip4:46.244.63.207/8 ip4:176.34.51.209/15 ~all


Those sort of huge blocks definitely catch an analyst’s eye!

By the way, if you’ve got a computer science or network engineering background, the above “pseudo-CIDR” address ranges may be disconcerting since the “origins” for those blocks aren’t bit-aligned on a legal CIDR block boundary at section 4.

After reviewing the formal SPF specification in RFC7208 section 5.6 (and even discussing the matter with the author of that RFC), I confirmed that while those specifications look odd, in SPF the focus is solely on the high order bits, not the low order bits (As the RFC states, “The is compared to the given network. If CIDR prefix length high-order bits match, the mechanism matches.”).

8. “What About DNSSEC Record Types?”

As you look at data for a domain, a final quick reminder that if you omit specifying a record type (or explicitly ask to see ANY as your record type choice), you’ll see all non-DNSSEC-related record types, but asking for “ANY” (or omitting a record type entirely) will NOT check DNSSEC record types.

If you are interested in exploring DNSSEC record types as part of your reviews, be sure to make a second query, explicitly specify ANY-DNSSEC as the record type for your query.

If DNSSEC is relatively new to you and you’d like a little backfill about it in a passive DNS context, read this blogpost, “The “Forgotten Half” of DNSDB: DNSDB’s DNSSEC Coverage”.

9. Conclusion

We hope this article has helped demystify “how” and “why” investigators come to focus on particular record types as part of their work with DNSDB.

For information on how to obtain access to DNSDB, please contact Farsight Security Sales at [email protected].

Joe St Sauver Ph.D. is a Distinguished Scientist with Farsight Security®, Inc.