Going From A Domain Name to IP Address in DNSDB: Some "Pro Tips" To Keep In Mind
I. Introduction
Virtually every DNSDB user makes domain name to IP address queries. Often that will be quite straight forward, but today we’re going to talk about some of the times when you may run into surprises — and how you can easily deal with them.
Let’s start with a straightforward example. Let’s use Farsight’s DNSDB Scout web interface (https://scout.dnsdb.info/) to lookup the IP addresses we’ve seen www.whitman.edu use over time.
To do that, we’ll make a “Standard Search” of “RRsets” for that domain name:
Figure 1. Using DNSDB Scout to see the IP addresses that www.whitman.edu has used over time.
Similarly, if you’re a “Un*x command line” sort of person, you can use our open-source command line client, dnsdbq (https://github.com/dnsdb/dnsdbq) to find those same IPs from a Linux or Mac OS Terminal window:
$ dnsdbq -r www.whitman.edu ;; record times: 2014-03-26 21:27:00 .. 2021-09-02 09:44:01 (~7y ~161d) ;; count: 1496319; bailiwick: whitman.edu. www.whitman.edu. A 199.89.174.11 ;; record times: 2010-06-24 13:49:41 .. 2014-03-27 16:40:25 (~3y ~277d) ;; count: 940920; bailiwick: whitman.edu. www.whitman.edu. A 199.89.174.13
Very straight-forward (except perhaps for the DNS “lingo”), nothing surprising, nothing exotic.
But now let’s consider another (perhaps slightly surprising) example.
II. More Than Just “A” Records May Be Returned By Default
This time, let’s continue our “tour of college websites” by looking at www.utah.edu in DNSDB Scout:
Figure 2. Using DNSDB Scout to look at www.utah.edu
We might have been expecting to only see IPv4 addresses for that site, but we actually saw other record types by default, too:
"MX"records (defining the SMTP server that would be used if someone were to try sending mail to that host), and"AAAA"records (showing thatwww.utah.eduhas had IPv6 connectivity alongside its IPv4 connectivity).
In retrospect, while we might have been surprised to see those other record types, we probably shouldn’t have been — after all, we’d left the “Record Type” selector set to "ANY":
When the Record Type selector is set to "ANY", DNSDB will return matching hits for ALL record types (except for DNSSEC record types, which are intentionally omitted by default even from "ANY" since most DNSDB users normally aren’t interested in them).
If we DO just want a particular record type (such as JUST IPv4 "A" records), we can use the Record Type selector in DNSDB Scout to select the Record Type we want.
We can also select specific record types in dnsdbq. For example, to select just "A" records in dnsdbq, we’d say:
$ dnsdbq -r www.utah.edu/A ;; record times: 2010-06-24 17:39:02 .. 2011-08-04 01:54:53 (~1y ~40d) ;; count: 288644; bailiwick: utah.edu. www.utah.edu. A 155.97.137.29 ;; record times: 2011-08-04 01:55:37 .. 2020-08-10 22:00:01 (~9y ~9d) ;; count: 4011829; bailiwick: utah.edu. www.utah.edu. A 155.97.137.55 ;; record times: 2020-08-10 22:09:38 .. 2021-09-02 17:04:27 (~1y ~22d) ;; count: 144816; bailiwick: utah.edu. www.utah.edu. A 155.98.186.21 ;; record times: 2015-04-29 20:32:07 .. 2015-04-30 21:13:30 (~1d 41m) ;; count: 2426; bailiwick: utah.edu. www.utah.edu. A 155.101.6.35
Or if we wanted to just see “AAAA” (IPv6) addresses, we could ask for them, instead:
$ dnsdbq -r www.utah.edu/AAAA ;; record times: 2012-05-31 17:43:31 .. 2018-12-19 12:59:55 (~6y ~202d) ;; count: 678399; bailiwick: utah.edu. www.utah.edu. AAAA 2001:1948:414:6::2 ;; record times: 2018-12-17 13:40:20 .. 2020-08-11 13:42:54 (~1y ~238d) ;; count: 110389; bailiwick: utah.edu. www.utah.edu. AAAA 2604:c340:0:1::5
III. Beware of Stumbling Over “Wooly Mammoths” and Other Historical DNS Artifacts
Readers with a sharp eye may note that the latest “AAAA” record returned for www.utah.edu example in Part II is from August 11th, 2020. That’s over a year ago as of the time this article was written! Did DNSDB suddenly lose coverage of what’s happening in Utah?
No. We believe that the University of Utah may have simplified provisioning for their main web site by removing IPv6 access to it.
We can confirm that this is the case by checking regular DNS with the dig command line DNS lookup tool (dig may be pre-installed on your operating system, available via a dnsutils bundle in some package managers, or it can be obtained as part of BIND (https://www.isc.org/bind/)).
To attempt to find an IPv6 address for www.utah.edu we’d enter:
$ dig www.utah.edu aaaa +short [nothing returned here]
If there were to be a current "AAAA" record available for www.utah.edu, we’d expect to see an IPv6 address, as we do when we try a known-IPv6-accessible host such as www.internet2.edu:
$ dig www.internet2.edu aaaa +short 2600:1f18:89f:f033:ae41:5fb3:2db7:764e
The key takeaways from this section are “Just because a site once had a DNS record for something, doesn’t mean it will ALWAYS continue to have that record,” and “If you only care about what’s happening NOW, be sure you don’t rely on purely historical results accidentally.”
One easy way to avoid those issues is by leveraging time fencing.
For example, if we only care about what’s been going on during the last quarter, we might ask just for results from the 90 days:
$ dnsdbq -r www.utah.edu/AAAA -A90d Query status: NOERROR (no results found for query.)
If you’re using DNSDB Scout and want to time fence, click on the "+ Time Fencing" option to expand that section, then click on the “clock face” icon and select 90d (or whatever time fencing you prefer) for “Time After.”
IV. Chasing CNAME Records
We’ve seen a couple of pretty straight forward examples so far. Let’s now move onto a slightly more complex topic, namely sites that use CNAME (“Canonical Name”) records. CNAME records allow one domain name to “point at” or “be defined as a nickname” for another domain name.
For example, perhaps we’d like to look up www.utdallas.edu to see what IP addresses it has used during the last 90 days:
$ dnsdbq -r www.utdallas.edu -A90d ;; record times: 2021-03-16 13:49:31 .. 2021-09-03 13:05:55 (~170d 23h 16m) ;; count: 243078; bailiwick: utdallas.edu. www.utdallas.edu. CNAME www.utdallas.edu.c14751.campuspress.com.
If we were expecting to see an IP address in response to your query, we might have been surprised to “just” get another domain name (as highlighted in green). If we want to find out the IP address that domain is “really using”, we’ll need to “chase” (or “iteratively resolve”) the CNAME we were given. This may actually end up being a multistep process, “daisy chaining” from one CNAME to another (as shown by the highlighted elements below):
$ dnsdbq -r www.utdallas.edu.c14751.campuspress.com -A90d ;; record times: 2021-03-16 13:50:23 .. 2021-09-03 14:38:10 (~171d 47m) ;; count: 215473; bailiwick: campuspress.com. www.utdallas.edu.c14751.campuspress.com. CNAME cloudflare-resolve-to.c14751.campuspress.com. $ dnsdbq -r cloudflare-resolve-to.c14751.campuspress.com -A90d ;; record times: 2020-05-28 16:37:00 .. 2021-09-03 14:41:35 (~1y ~97d) ;; count: 727810; bailiwick: campuspress.com. cloudflare-resolve-to.c14751.campuspress.com. CNAME utdallas.us-east-2.lb.campuspress.com. $ dnsdbq -r utdallas.us-east-2.lb.campuspress.com -A90d ;; record times: 2020-04-03 07:09:30 .. 2021-09-03 06:17:10 (~1y ~152d) ;; count: 1037100; bailiwick: campuspress.com. utdallas.us-east-2.lb.campuspress.com. CNAME produ-loadb-on7bcbui3qss-86d92ccd5e16e1be.elb.us-east-2.amazonaws.com. $ dnsdbq -r produ-loadb-on7bcbui3qss-86d92ccd5e16e1be.elb.us-east-2.amazonaws.com. -A90d ;; record times: 2020-04-03 07:09:30 .. 2021-09-03 08:06:03 (~1y ~153d) ;; count: 274181; bailiwick: elb.us-east-2.amazonaws.com. produ-loadb-on7bcbui3qss-86d92ccd5e16e1be.elb.us-east-2.amazonaws.com. A 3.21.250.42 produ-loadb-on7bcbui3qss-86d92ccd5e16e1be.elb.us-east-2.amazonaws.com. A 3.133.32.155
There was nothing particularly magical about doing this process, we just needed to know to “be persistent” and “keep going” until we finally actually got the IP address(es) we were after.
V. Individual Results Potentially Returning Multiple IPs As Part of A Single Result
The UT Dallas CNAME example illustrates another important point: that single result included multiple IP addresses. The UT Dallas example returned two IPs, but you might see cases with three, four, or even more IPs returned in a single answer:
$ dnsdbq -r ad.ucla.edu/A -A90d ;; record times: 2019-05-30 20:18:09 .. 2021-09-03 17:51:12 (~2y ~96d) ;; count: 235565; bailiwick: ad.ucla.edu. ad.ucla.edu. A 128.32.80.232 ad.ucla.edu. A 164.67.132.28 ad.ucla.edu. A 164.67.134.68 ad.ucla.edu. A 169.232.40.36 ad.ucla.edu. A 169.232.40.37 ad.ucla.edu. A 169.232.40.82 ad.ucla.edu. A 169.232.40.85 ad.ucla.edu. A 169.232.40.86 ad.ucla.edu. A 169.232.40.88 ad.ucla.edu. A 169.232.40.89 ad.ucla.edu. A 169.232.45.137
If you think this “crazy result” MUST somehow be wrong, you can confirm that DNSDB is actually “telling the truth” by checking what the “live DNS” reports via dig:
$ dig ad.ucla.edu +short 169.232.40.36 128.32.80.232 169.232.45.137 169.232.40.82 164.67.134.68 169.232.40.86 169.232.40.37 169.232.40.89 164.67.132.28 169.232.40.85 169.232.40.88
ALL those IPs WERE returned as a SINGLE answer to a SINGLE query (a resource may be configured this way when it is mission critical infrastructure and the DNS is being used to provide redundancy and load balancing).
So if you thought that you could “just look up a domain name” and always “just get a single IP address as an answer”, you might NOT be prepared to deal with the reality that a single result might contain MULTIPLE records that MUST be handled as a SET.
Sometimes people will attempt to “improvise” a solution to this “challenge.” No matter what anyone may tell you,
No, you MUST NOT just “take a chance” and randomly pick one or another of those records (ignoring the others)
NOR can you pretend that one answer consisting of <N> records is really <N> independent answers (each with one record)
Neither of those misconceived “creative solutions” to the “getting multiple IP addresses back for a single answer” would be faithful to what’s actually happening in the Domain Name System.
VI. There May Be MANY Results, Sometimes of the “<r> IPs Drawn From A Pool Of <n> IPs” Format
During the last quarter, uber.com, the popular ride sharing service, looked like this to Farsight:
$ dnsdbq -r uber.com/A -A90d ;; record times: 2019-10-30 20:14:42 .. 2021-09-03 13:11:54 (~1y ~308d) ;; count: 33112770; bailiwick: uber.com. uber.com. A 34.98.127.226 ;; record times: 2020-09-11 02:17:06 .. 2021-09-03 13:04:26 (~357d 10h 47m) ;; count: 2015839; bailiwick: uber.com. uber.com. A 104.36.195.150 ;; record times: 2019-12-09 22:55:15 .. 2021-09-03 13:19:34 (~1y ~268d) ;; count: 5449193; bailiwick: uber.com. uber.com. A 104.36.197.214
The above look like very normal results, nothing unexpected.
But now let’s look back a little earlier, such as during the first six months of 2019:
$ dnsdbq -r uber.com/A -A2019-01-01 -B2019-06-31 -l1000000 | more ;; record times: 2018-03-24 06:50:29 .. 2019-02-01 07:45:37 (~314d 55m) ;; count: 159; bailiwick: uber.com. uber.com. A 104.36.192.145 uber.com. A 104.36.192.172 uber.com. A 104.36.192.173 uber.com. A 104.36.192.174 uber.com. A 104.36.192.176 ;; record times: 2018-03-26 03:39:33 .. 2019-02-03 07:14:08 (~314d 3h 34m) ;; count: 188; bailiwick: uber.com. uber.com. A 104.36.192.145 uber.com. A 104.36.192.172 uber.com. A 104.36.192.173 uber.com. A 104.36.192.174 uber.com. A 104.36.192.178 ;; record times: 2018-03-27 04:47:27 .. 2019-01-11 17:42:24 (~290d 12h 54m) ;; count: 164; bailiwick: uber.com. uber.com. A 104.36.192.145 uber.com. A 104.36.192.172 uber.com. A 104.36.192.173 uber.com. A 104.36.192.174 uber.com. A 104.36.192.180 ;; record times: 2018-03-24 01:43:29 .. 2019-02-03 20:35:58 (~316d 18h 52m) ;; count: 201; bailiwick: uber.com. uber.com. A 104.36.192.145 uber.com. A 104.36.192.172 uber.com. A 104.36.192.173 uber.com. A 104.36.192.174 uber.com. A 104.36.192.182 ;; record times: 2018-03-25 15:44:21 .. 2019-01-19 20:17:20 (~300d 4h 33m) ;; count: 203; bailiwick: uber.com. uber.com. A 104.36.192.145 uber.com. A 104.36.192.172 uber.com. A 104.36.192.173 uber.com. A 104.36.192.174 uber.com. A 104.36.192.202 ;; record times: 2018-04-03 20:14:49 .. 2019-01-31 17:36:56 (~302d 21h 22m) ;; count: 172; bailiwick: uber.com. uber.com. A 104.36.192.145 uber.com. A 104.36.192.172 uber.com. A 104.36.192.173 uber.com. A 104.36.192.174 uber.com. A 104.36.193.169 [etc, etc, etc]
There were 160,701 unique responses of that sort seen during just that six-month period:
$ dnsdbq -r uber.com/A -A2019-01-01 -B2019-06-31 -l1000000 -V summarize ;; record times: 2018-02-03 00:23:46 .. 2020-04-02 03:43:49 ;; count: 27704360; num_results: 160701
That’s a fairly large number of results. Where this gets interesting is when we recognize that those responses were created from a surprisingly small pool of IP addresses, just 93 of them, in fact. We’ve identified them by extracting just the IP addresses from the responses with jq (see https://stedolan.github.io/jq/), and then sorting and uniquifying them:
$ dnsdbq -r uber.com/A -A2019-01-01 -B2019-06-31 -l1000000 -j | jq -r '.rdata[]' | sort -u | wc -l 93
To understand what’s going on here, let’s compute the number of possible combinations of r=5 items drawn from a pool of n=93:
C(93,5) = 93!/(5!(93−5)!) = 51,971,283 potential unique combinations
where
! stands for "factorial" (e.g., 5! = 5 * 4 * 3 * 2)
Challenging as those 160,701 unique answers might be to “grok,” we were actually “lucky” — those 160,701 unique answers were less than 1/3rd of 1% of all the results we could POTENTIALLY have seen if Uber was just randomly grabbing 5 IPs from a pool of 93 (e.g., 160,701/51,971,283*100=0.309%).
The take away from this section? Don’t just blindly take DNSDB results at face value — spend a little time “analyzing what you’ve gotten,” at least if you get something unusual!
VII. Conclusion
We hope you found this discussion of mapping domain names to IP addresses interesting. We haven’t exhausted all the possible “corner cases” you may potentially run into, but we hope that this quick tour will at least help you interpret some of what you may run into.
If you have questions about what you’re seeing in DNSDB, we’re always interested in hearing from customers. Feel free to contact [email protected].
Read the next part in this series: Going From An IP Address to A Fully Qualified Domain Name (FQDN) In DNSDB
