I. Introduction
Today’s blog article is going to explore the use of IP addresses, IP address ranges, and CIDR block queries in DNSDB API, including discussing some fine points where there might be opportunities for confusion or error.
II. Per-IP Queries in DNSDB API
Most users of DNSDB have probably queried DNSDB for an IPv4 address. For example, in dnsdbq one might say:
$ dnsdbq -A7d -i 128.150.4.107 ;; record times: 2010-06-24 16:32:54 .. 2018-04-18 16:41:59 ;; count: 5768323 nsf.gov. A 128.150.4.107 ;; record times: 2010-06-24 05:12:53 .. 2018-04-18 15:44:40 ;; count: 16846128 www.nsf.gov. A 128.150.4.107
Decoding that command:
The
-iqualifier says, “Search DNSDB’s rdata (“right hand side of DNS resource records”) for this IP address”The
-A7dqualifier says, “Limit results to just those from the last seven days”
You can also query DNSDB for individual IPv6 addresses:
$ dnsdbq -A7d -i 2620:10f:6001:4::107 ;; record times: 2014-02-01 02:40:18 .. 2018-04-18 15:41:08 ;; count: 776850 nsf.gov. AAAA 2620:10f:6001:4::107 ;; record times: 2014-02-01 02:32:52 .. 2018-04-18 16:53:13 ;; count: 4016690 www.nsf.gov. AAAA 2620:10f:6001:4::107
III. Queries for Multiple IPs
If you have multiple IPs (such as perhaps a dozen scattered IPs), you can repeat the above process for each of those individual IPs.
Often, however, users will want to query a large contiguous range of hundreds or thousands of IP addresses or perhaps a CIDR netblock of IP addresses. You really don’t want to have to make a large number of singleton queries in that case, you’d just like to be able to specify starting and ending IP addresses, or a CIDR netblock in traditional CIDR netblock notation.
Fortunately, DNSDB supports that, too. For example, you might make the query:
$ dnsdbq -A7d -i 128.150.4.0-128.150.4.255
or equivalently
$ dnsdbq -A7d -i 128.150.4.0/24
Or in the IPv6 space:
$ dnsdbq -A7d -i 2620:10f:6001:4:0:0:0:0-2620:10f:6001:4:ffff:ffff:ffff:ffff
or equivalently:
$ dnsdbq -A7d -i 2620:10f:6001:4::/64
IV. Technically Acceptable Proper CIDR Query Construction
While queries for singleton IPs or IP ranges are hard to get wrong, CIDR queries are a little more complex.
CIDR blocks are formed from a starting IP address, a slash, and a CIDR block length.
For example, in the case of 192.0.2.0/24, the starting IP address is 192.0.2.0 and the CIDR block length is a /24 (for a total of 256 addresses).
Technically, however, subnet masks lay “underneath” CIDR block length specifications.
In the case of a /24 (256 addresses) the subnet mask looks like:
Netmask: 255.255.255.0 Binary: 11111111 11111111 11111111 00000000
In the case of a /25 (128 addresses) the subnet mask looks like:
Netmask: 255.255.255.128 Binary 11111111 11111111 11111111 10000000
And in the case of a /26 (64 addresses) the subnet mask looks like:
Netmask: 255.255.255.192 Binary 11111111 11111111 11111111 11000000
As a result of those underlying masks, CIDR netblocks cannot begin at “any or all possible” IP addresses. Only certain starting IP addresses are “are technically OK” or “make sense” when constructing a CIDR netblock.
For example, if we wanted to create two /25’s from 192.0.2.0/24, the only two starting IPs that will work are:
192.0.2.0 (consisting of 192.0.2.0-192.0.2.127), and
192.0.2.128 (consisting of 192.0.2.128-192.0.2.255)
We CANNOT arbitrarily decide to specify that we want a CIDR netblock of 128 addresses beginning at 192.0.2.37 or 192.0.2.56, for instance. Those starting addresses would not align with a binary netmask boundary.
Similarly, if we wanted to create four /26’s from 192.0.2.0/24, those netblocks would have to start at:
192.0.2.0 (consisting of 192.0.2.0-192.0.2.63)
192.0.2.64 (consisting of 192.0.2.64-192.0.2.127)
192.0.2.128 (consisting of 192.0.2.128-192.0.2.191)
192.0.2.192 (consisting of 192.0.2.192-192.0.2.255)
We CANNOT create valid CIDR netblocks of 64 addresses starting at other “random” address in the 192.0.2.0-192.0.2.255 range — we can ONLY use the .0, the .64, the .128 and the .192 addresses mentioned previously.
If we wanted to create eight /27’s from 192.0.2.0/24, those netblocks would have to start at:
192.0.2.0 (consisting of 192.0.2.0-192.0.2.31)
192.0.2.32 (consisting of 192.0.2.32-192.0.2.63)
192.0.2.64 (consisting of 192.0.2.64-192.0.2.95)
192.0.2.96 (consisting of 192.0.2.96-192.0.2.127)
192.0.2.128 (consisting of 192.0.2.128-192.0.2.159)
192.0.2.160 (consisting of 192.0.2.160-192.0.2.191)
192.0.2.192 (consisting of 192.0.2.192-192.0.2.223)
192.0.2.224 (consisting of 192.0.2.224-192.0.2.255)
The same sort of constraints apply to other CIDR netblock lengths. We’re limited to just the select IP addresses that are compatible with possible binary netmask values.
V. Interpretation of “Improper” User-Supplied CIDR Specifications In DNSDB
If you try specifying a CIDR netblock in DNSDB, you’ll quickly notice that Farsight does NOT mandate users only specify “proper” CIDR netblock specifications. For example, you can try making the query:
$ dnsdbq -i 128.223.131.41/24
That’s obviously an “improper” CIDR netmask since /24’s should start on a dot zero address, not on a dot forty-one address. And yet, DNSDB accepts that query and processes it. So how does that “CIDR” specification get interpreted by DNSDB? Multiple possibilities come to mind. Can we empirically determine which one is used?
Interpretation 1 (AKA “It’s Either Right Or We’re Not Running It”): In this potential “hardline” interpretation, trying to incorrectly specify 128.223.131.41/24 would simply result in an error being returned, perhaps a terse “Illegal CIDR specification.” We know that this is NOT what’s happening in DNSDB since improper CIDRs are run.
Interpretation 2 (AKA “This isn’t being done in a routing context, and we don’t really know about or care about bitmasks, so just start where I said to start and DO IT…”): In this interpretation, 128.223.131.41/24 might be interpreted as “Beginning at 128.223.131.41, show me hits for 128.223.131.41 and 255 consecutive IP addresses thereafter.” While this interpretation would represent an attempt to “honor” both the user-specified starting IP and a CIDR-like length, it would be crazy. It is NOT what’s happening in DNSDB.
Interpretation 3 (AKA “I’m sort of busy, could you please just figure out what I SHOULD HAVE specified in order to end up with a proper block of the specified CIDR length that includes the “starting” IP address I mentioned? Thanks!”). This IS how the user-supplied improper CIDR block notation is being handled by DNSDB.
You can watch the smallest and largest addresses for a series of queries “squeeze in” as the specified CIDR length changes:
For the DSNSDB test query 128.223.131.41/24
--The smallest address we see from the test query is 128.223.131.2 --The biggest address we see from the test query is 128.223.131.253
For the DNSDB test query 128.223.131.41/25:
--The smallest address we see from the test query is 128.223.131.2 --The biggest address we see from the test query is 128.223.131.127
For the DNSDB test query 128.223.131.41/26:
-- The smallest address we see from the test query is 128.223.131.2 -- The biggest address we see from the test query is 128.223.131.63
For the DNSDB test query 128.223.131.41/27:
-- The smallest address we see from the test query is 128.223.131.32 -- The biggest address we see from the test query is 128.223.131.63
For the DNSDB test query 128.223.131.41/28:
-- The smallest address we see from the test query is 128.223.131.32 -- The biggest address we see from the test query is 128.223.131.47
For the DNSDB test query 128.223.131.41/29:
-- The smallest address we see from the test query is 128.223.131.40 -- The biggest address we see from the test query is 128.223.131.47
For the DNSDB test query 128.223.131.41/30:
-- The smallest address we see from the test query is 128.223.131.40 -- The biggest address we see from the test query is 128.223.131.43
VI. Summary
— DNSDB can process passive DNS queries for individual IPv4 or IPv6 addresses, or for runs of addresses
— Runs of addresses can be specified as an IP address range (arbitrary starting IP address followed by a dash followed by an arbitrary ending ip address), or as a CIDR netblock (in the form of a starting IP address, a slash, and a CIDR prefix length)
— If the requested CIDR block doesn’t start on an acceptable CIDR starting IP, DNSDB will automatically adjust the query so as to return results for a valid CIDR block of the specified size encompassing that IP address.
— If you DO specify a valid CIDR specification, DNSDB will process that request exactly as specified.
— Confused to death by all this CIDR stuff? Let’s make this easy. You can always get exactly the starting and ending addresses you want by just specifying a simple IP address range.
So if you’re not already using DNSDB for your passive DNS analysis requirements, why don’t you request a free trial account and evaluate it? Please see DNSDB API Free Trial for more information.
FAQ
Q1. Is this behavior client-specific, perhaps unique to just dnsdbq?
A1. No. Because the interpretation of the user-supplied improper CIDR is being done by the DNSDB API server, you should get the same result for improper CIDR queries regardless of what DNSDB client you may be using (e.g., dnsdbq, dnsdb_query.py, etc., etc., should all return the same results for a user-supplied improper CIDR). We simply needed to pick something to illustrate this phenomena, and we picked dnsdbq.
Q2. I’m seeing IP addresses that come BEFORE the starting CIDR value I specified! Something must be wrong.
A2. If you specify an improper/invalid CIDR starting value, you often will see results for IPs that come BEFORE the CIDR starting address you specified, as discussed earlier in this article. That said, the address you specify will always be WITHIN the CIDR that’s looked up, it just won’t necessarily be the “starting” or “lowest” value you see. If you want total control over the exact starting and ending IP addresses that get looked up, we recommend specifying an IP range rather than a CIDR value (for example 128.223.131.41-128.223.131.255).
Q3. Can I use an asterisk to specify an IP wildcard? For example, will 128.148.252.* be treated as the same as 128.148.252.0/24 or 128.148.252.0-128.148.252.255?
A3. No. You can’t use asterisks to try to specify an IP wildcard. Please use an IP range or CIDR netblock instead.
Joe St Sauver Ph.D. is a Distinguished Scientist with Farsight Security, Inc.
