Mapping Domain Names to IP Addresses: Going From a Name To An IP Address May Not Happen Directly in Just a Single Step
There’s a new feature available in Farsight DNSDB Scout — the ability to automatically “chase” (or iteratively resolve) Canonical Name (CNAME) records in Farsight DNSDB with the goal being to get to an IP address. Identifying CNAMEs can provide another pivot point for investigators. If a threat actor uses infrastructure connected to CNAMEs, it tracks back to other domains or resolve to IP addresses. The ability to do this automatically means fewer steps for investigators.
Some domain names may directly resolve to an IPv4 address via a DNS “A” record. For instance, that’s the case for the University of Michigan’s web site:
www.umich.edu --> 141.211.243.251Other times, CNAME records may be used to indirectly point a domain name at an IP address via one or more intermediate domain names. Think of them as hops along DNS or links in a chain. For example, this is how the Washington Post’s web site is engineered:
www.washingtonpost.com --> 50992.edgekey.net
50992.edgekey.net --> e9631.j.akamaiedge.net
e9631.j.akamaiedge.net --> 23.196.204.38We’d say that the Washington Post’s site “chains” via two intermediate CNAMEs to the eventual IPv4 address shown above. That iterative process gets handled automatically in the regular “live” DNS.
However in DNSDB, CNAMEs do NOT normally get automatically “chased.” Instead, DNSDB API gives you the flexibility and power to handle CNAME records “one step at a time.” Let’s use the dnsdbq command line DNSDB to see what this means in practice. We’ll focus on the www.washingtonpost.com web site over a thirty day period. Resolving that domain takes three steps:
Step One: Starting With www.washington.com, where does that domain name resolve to over a month?
$ dnsdbq -r www.washingtonpost.com -A30d
;; record times: 2017-12-11 19:04:36 .. 2023-12-08 14:16:56 (~5y ~362d)
;; count: 5846770; bailiwick: washingtonpost.com.
www.washingtonpost.com. CNAME 50992.edgekey.net.So at least over that 30 day period, www.washingtonpost.com always resolves to the CNAME 50992.edgekey.net. Fine so far, but we’re not done. Where does 50992.edgekey.net in turn go? We’ll “chase” it in DNSDB by making a 2nd query:
Step Two: Now resolve the CNAME we found in step one…
$ dnsdbq -r 50992.edgekey.net -A30d
;; record times: 2017-10-17 14:25:16 .. 2023-12-08 13:47:01 (~6y ~52d)
;; count: 6932521; bailiwick: edgekey.net.
50992.edgekey.net. CNAME e9631.j.akamaiedge.net.We’re making progress, but we still haven’t gotten to an actual IP address yet. Let’s do a third DNSDB query:
Step Three: Now resolve the CNAME we found in step two…
$ dnsdbq -r e9631.j.akamaiedge.net -A30d -S -k count
;; record times: 2021-02-16 23:38:12 .. 2023-12-08 09:53:49 (~2y ~294d)
;; count: 40487130; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 23.35.168.237
;; record times: 2023-01-11 17:42:20 .. 2023-12-08 13:10:36 (~330d 19h 28m)
;; count: 15090319; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 23.222.170.6
;; record times: 2021-10-22 23:39:12 .. 2023-12-08 03:34:01 (~2y ~46d)
;; count: 12846251; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.119.75.230
;; record times: 2021-10-07 01:37:50 .. 2023-11-21 13:51:41 (~2y ~45d)
;; count: 6002295; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.104.119.210
;; record times: 2022-06-16 04:19:52 .. 2023-12-08 11:58:46 (~1y ~175d)
;; count: 5726604; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 23.4.188.93
;; record times: 2021-05-28 05:31:51 .. 2023-12-08 15:38:19 (~2y ~194d)
;; count: 5432892; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.98.85.192
;; record times: 2022-11-02 22:08:56 .. 2023-12-08 13:56:31 (~1y ~35d)
;; count: 5211633; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.103.182.209
;; record times: 2023-07-21 07:50:51 .. 2023-12-08 11:23:58 (~140d 3h 33m)
;; count: 4789044; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 184.85.159.19
;; record times: 2021-06-08 18:37:21 .. 2023-11-08 17:07:03 (~2y ~152d)
;; count: 4619324; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.79.131.248
;; record times: 2021-04-04 10:53:56 .. 2023-12-02 17:30:53 (~2y ~242d)
;; count: 4425722; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.100.223.158
;; record times: 2023-10-04 20:12:44 .. 2023-12-08 07:37:51 (~64d 11h 25m)
;; count: 3906312; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.81.228.141
;; record times: 2022-12-15 20:43:18 .. 2023-12-08 09:58:02 (~357d 13h 14m)
;; count: 3600229; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 173.222.212.221
;; record times: 2022-10-04 18:18:05 .. 2023-12-08 15:22:56 (~1y ~64d)
;; count: 3002696; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.106.175.75
;; record times: 2023-04-19 19:06:05 .. 2023-12-08 13:24:35 (~232d 18h 18m)
;; count: 2605362; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 23.193.66.18
;; record times: 2023-06-26 03:03:53 .. 2023-12-08 09:02:40 (~165d 5h 58m)
;; count: 2559696; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 2.21.205.161
;; record times: 2020-08-26 01:31:20 .. 2023-12-08 06:34:34 (~3y ~104d)
;; count: 1827531; bailiwick: j.akamaiedge.net.
e9631.j.akamaiedge.net. A 104.86.74.16
[etc]NOW we’ve successfully gone from a starting domain name, through some intervening CNAMEs, to actual IP addresses.
What we see in the above results tells us that the Washington Post uses the Akamai content distribution network (“CDN”) for its site. Akamai replicates customer content across multiple Akamai cache servers to scale and accelerate delivery of content to customers. DNSDB faithfully tracks each of the IPs seen as soon as they’re visible to one or more of our sensors. (To keep this article to reasonable length, we’ve shown you just a subset of all the results for the e9631.j.akamaiedge.net hostname)
So now you know that you can dig the results out of DNSDB, “one step at a time,” as shown above.
Automating The Mechanical Drudgery (So You Don’t Have To Do It Yourself)
The process of chasing CNAMEs manually in DNSDB is straightforward but, admittedly, sometimes a bit tedious. Wouldn’t it be nice if we could let computers do what they do best, and just automate that process? Now you can, at least in Farsight DNSDB Scout, the DomainTools web-based graphical user interface (GUI) for DNSDB.
For example, let’s try chasing the CNAMEs for www.harvard.edu in DNSDB Scout (https://scout.dnsdb.info/):
Note that we selected CNAME as the record type, AND we checked the new “Chase CNAMEs” box in the Standard Search tab.
The result is a relatively straightforward CNAME example — www.harvard.edu points at pantheon-systems.map.fastly.net, and pantheon-systems.map.fastly.net points at an IP address. This sequence gets shown in the gray query summary box:
Notes:
- The gray box summary shows only ONE CNAME-chased sequence (of potentially many that may exist).
Think of CNAME expansion as being a “tree” which potentially “branches” at each CNAME, and which may have many terminal “leaves” when the domain finally resolves to an IP address.
The example shown is meant to illustrate one of those paths, and not exhaustively display the entire CNAME tree.
- The one CNAME expansion that is shown is not guaranteed to necessarily be the “best” or “most representative” case, it’s just one example of a CNAME chain for the given starting point.
- When multiple values are available during evaluating a CNAME chain, DNSDB Scout’s CNAME chasing algorithm needs to choose which branch to follow. It will normally prefer:
- An RRtype=CNAME record, if one’s available (rather than a different RRtype, such as an “A” or “AAAA” record)
- Within the selected RRtype class, the most recently seen value (rather than the value with the largest count, or the value that’s been seen for the longest period of time, or some other hypothetical resource record selection rule)
- When chasing a CNAME, you’ll see the DNSDB Scout refresh (“flash”) as each step in the process gets sequentially performed and the display gets updated. DNSDB Scout may traverse a CNAME chain of max depth 10 for DNSDB API users, and a CNAME chain of max depth 25 for DNSDB Export users (these limits are fixed and not user configurable).
- Just as if you were doing the process manually, each query that runs automatically on your behalf as part of the CNAME chasing process will be subtracted from your account’s available quota of queries.
Coming back to our www.harvard.edu example, if we scroll down, beside the summary shown in the gray box, we can also see all the values DNSDB knows about for the last step (e.g., pantheon-systems.map.fastly.net). We’ve sorted these in descending order by clicking on the “COUNT” header in the table):
CNAME Chains May Ultimately Resolve to MULTIPLE IPs
The www.harvard.edu example in the preceding section resolved to answers that each consisted of a single IP address. That’s not always the case. For example, in resolving www.princeton.edu, that CNAME chain returns multiple IPs returned as a set. This is perfectly fine, it just may be something you may not have expected (if you normally expect to see a single IP address for an answer):
If A CNAME IS Available At Any Stage, Scout Will Prefer The CNAME-Based Path to Any Alternative Result…
Coming back to the Washington Post example we started with, if we check it in DNSDB Scout, it demonstrates an interesting phenomenon. That is, at each stage in the evaluation process, if there are multiple different record types, the CNAME chasing process will prefer to follow any available CNAME, even if the CNAME record is older or less common than other results:
So in this case, e9631.j.akamaiedge.net shows a CNAME going to e9631.j.akamaiedge.net.0.1.cn.akamaiedge.net. This is NOT the same path we reported in the first section (it’s a valid path, just not the one we manually found and reported in the first section).
Why did DNSDB Scout choose this record (rather than some other available result) in this case? The answer: the chosen result was a CNAME record, and remember, we prefer to “keep chasing CNAMEs” whenever we can.
If we “don’t like” the CNAME chain that was chosen, we always have the option of manually chasing alternative result “branches” on the result tree, instead. Conveniently, the queries that were made to chase the CNAME (as shown in the gray query summary box) are available to us via the “RECENTS” tab:
We can investigate any of those by just clicking on a result of interest. Let’s click on the “View” icon for the 2nd query in that list:
We could browse through all 4,628 results seen at that stage, should we desire to do so. Most of those results were “A” records, but we can also see two CNAMEs:
Because DNSDB Scout likes to chase CNAMEs when it has the option to do so, it picked the most recent of those two CNAMEs, but we could choose one of the other results instead.
Incomplete CNAME Chains
If we resolve www.ucsd.edu interactively via the “live” (regular) DNS with dig, we see:
$ dig www.ucsd.edu
[...]
www.ucsd.edu. 86400 IN CNAME cms-web-1573499122.us-west-2.elb.amazonaws.com.
cms-web-1573499122.us-west-2.elb.amazonaws.com. 60 IN A 52.38.163.49
cms-web-1573499122.us-west-2.elb.amazonaws.com. 60 IN A 34.208.69.81Trying to chase that CNAME in DNSDB, we run into an error. Sometimes DNSDB can’t successfully chase a CNAME chain because some results have been filtered out of DNSDB. We refer to these as “incomplete CNAME chains.” For example, if we try chasing the CNAMEs for www.ucsd.edu using DNSDB Scout, we see:
The attempt to chase that CNAME fails because cms-web-1573499122.us-west-2.elb.amazonaws.com is not a domain name DNSDB indexes. We can confirm that by attempting to lookup that specific FQDN with DNSBD Scout or dnsdbq:
$ dnsdbq -r cms-web-1573499122.us-west-2.elb.amazonaws.com
dnsdbq [2023-12-08 20:48:59]: API status: NOERROR (no results found for query.)
In fact, we can even try making a DNSDB wildcard query for *.us-west-2.elb.amazonaws.com — are any of those names resolvable? No:
$ dnsdbq -r \*.us-west-2.elb.amazonaws.com
dnsdbq [2023-12-08 20:59:29]: API status: NOERROR (no results found for query.)So obviously that name exists, but it’s a piece of the domain name system that’s been filtered from DNSDB. If you run into a terminal node of that sort, you can simply resolve it yourself. For example:
$ dig cms-web-1573499122.us-west-2.elb.amazonaws.com
[...]
;; ANSWER SECTION:
cms-web-1573499122.us-west-2.elb.amazonaws.com. 30 IN A 54.148.31.56
cms-web-1573499122.us-west-2.elb.amazonaws.com. 30 IN A 54.148.246.13We’d note that this will normally be an uncommon issue (so you shouldn’t need to manually resolve incomplete CNAME chains for most of the CNAMEs you’ll chase)
“What About CNAME Flattening and Proprietary Implementations of ANAME/ALIAS Records?”
CNAME flattening sounds like it might be something related to CNAME chasing, but it’s not.
CNAME flattening is something that Cloudflare is particularly well known for promoting. They use it both for (a) claimed performance improvement, and (b) because by doing so, a CNAME can effectively be used via their service for an apex domain (something that’s normally problematic, see:
Effectively, if CNAME flattening is being performed, there may be a CNAME “behind the scenes” but as far as the world can see, a name resolves directly to an IP, just as if the user had an “A” record defined.
Some authoritative name server products support CNAME flattening, others do not. Some that do:
CNAME flattening, when done, happens internally (and ANAME/ALIAS entries are not an RRtype defined at iana.org), so they should not pose any issues for the new CNAME chasing feature.
Conclusion
CNAMES are a core part of DNS records. While you can chase CNAMEs manually in Farsight DNSDB, we’ve demonstrated how you can now automate the process with Farsight DNSDB Scout. This includes how to set up the automation yourself, what you can expect to see (such as one IP address vs. multiple IP addresses), DNSDB Scout’s preference for CNAME records, and incomplete CNAME chains. We also discussed CNAME flattening as opposed to CNAME chasing.
It is our goal with this new feature that users can more quickly identify malicious infrastructure, leading to faster mitigations with minimal impact. Happy hunting!
