Depending on your interest in certain subjects, feel free to jump ahead:
Quantifying the Existence of Private Addresses in DNSDB
“Digging-In” On Some of the Publicly Announced Private Address Space Results We Discovered
Private IPv4 Addresses Used as Coded Values In DNS-based “Distributed Databases”
TL;DR
While many Internet servers are meant to be generally publicly accessible, you may run into fully qualified domain names (FQDNs) that are only meant to be resolvable for a more limited audience. What is less typical is when DNS information for those presumably-meant-to-be-internal-only servers show up in the global DNS.
Introduction
The Domain Name System (“DNS”) can be used to map fully qualified domain names (FQDNs) to IP addresses. For example, the Un*x dig command lets us find the IPv4 address the webserver www.domaintools.com uses:
$ dig www.domaintools.com +short 199.30.228.112
That web server, like many web servers, is meant to be generally publicly accessible, sharing information about the company and its products. That web server uses an IPv4 address that’s part of a netblock whose assignment is documented in IP Whois/Rwhois and RDAP (), as being controlled by DomainTools, LLC:
$ whois 199.30.228.112 [...] NetRange: 199.30.228.0 - 199.30.231.255 CIDR: 199.30.228.0/22 NetName: DOMAINTOOLS [...] OrgName: DomainTools, LLC Address: 2101 4th Ave, Suite 1150 City: Seattle StateProv: WA PostalCode: 98121 [etc]
From time to time, however, you may run into FQDNs that are only meant to be resolvable for a more limited audience (as in the case of an internal-only server with confidential information that’s running on an “intranet”). Such sites often rely on RFC1918 private IP addresses that are NOT globally routable. Nothing unusual so far.
What is less typical is when DNS information for those presumably-meant-to-be-internal-only servers show up in the global DNS. For example, note the following output from the DNSDB Scout web interface (Scout’s available to DNSDB API subscribers at https://scout.dnsdb.info/):
The Rdata shown in the red boxed area of the lower right corner of that screenshot shows that
entaa-test.internal.iowa.gov resolves to 192.168.20.74
192.168.20.74 is part of the 192.168.0.0/16 prefix, one of three network address blocks reserved for “private use” by :
10.0.0.0 -- 10.255.255.255 (aka the 10.0.0.0/8 prefix) 172.16.0.0 -- 172.31.255.255 (aka the 172.16.0.0/12 prefix) 192.168.0.0 -- 192.168.255.255 (aka the 192.168.0.0/16 prefix)
If you have an FQDN that resolves to an RFC1918 address, you normally won’t be able to reach that host unless you’re on the relevant local intranet (or you’ve VPN’d into that local intranet).
A simple way to understand why: MANY sites will all be SIMULTANEOUSLY using the IPv4 RFC1918 address space (as they’re meant to be able to). So, WHICH of all those many-possible networks — all sharing that same set of IPs — would be the “right one” for you to talk with, eh? The problem is obvious: unlike regular IP addresses, RFC1918 addresses are NOT globally unique and NOT globally reachable.
Similarly, other FQDNs may point at other private/special purpose IPs, see . Those address blocks include 127.0.0.0/8 and 0.0.0.0/8
This article will look at the extent to which all these sorts of private IPs show up in DNSDB, and what this all means.
Quantifying the Existence of Private Addresses in DNSDB
Because there are more than 50,000 results for most of these queries, we need to change from DNSDB Scout, our GUI client, to dnsdbq, our command line client (see https://github.com/dnsdb/dnsdbq), since browser table handling performs poorly for more than 50,000 rows.
We can search for entries that point to some of these specially-reserved address blocks by making queries such as:
$ dnsdbq -i 10.0.0.0/8 -A1d -l0 -j | jq -r '"(.count) (.rrname)"' | sort -nr > ten-dot.txt $ wc -l ten-dot.txt 635954 ten-dot.txt
That dnsdbq command asks for any DNSDB hits from 10.0.0.0/8, where those hits had been seen during the last day (-A1d), returning up to a million results/query (-l0) in JSON Lines output format (-j). We then pipe that JSON Lines format output through jq (https://stedolan.github.io/jq/), extracting just the count and the associated RRname for each entry. Those get sorted in numerical order, and put into the specified file in descending (“largest to smallest”) order.
We can sum up the cache miss counts seen for one day’s worth of 10/8 traffic by saying:
$ awk '{print $1}' < ten-dot.txt | paste -sd+ - | bc | numfmt --g
72,298,580,431
That’s a LOT of cache miss traffic! We then repeat that process for the other netblocks of interest:
$ dnsdbq -i 172.16.0.0/12 -A1d -l0 -j | jq -r '"(.count) (.rrname)"' | sort -nr > 172-dot-16.txt
$ wc -l 172-dot-16.txt
151824 172-dot-16.txt
$ awk '{print $1}' < 172-dot-16.txt | paste -sd+ - | bc | numfmt --g
4,691,199,722
$ dnsdbq -i 192.168.0.0/16 -A1d -l0 -j | jq -r '"(.count) (.rrname)"' | sort -nr > 192-dot-168.txt
$ wc -l 192-dot-168.txt
351544 192-dot-168.txt
$ awk '{print $1}' < 192-dot-168.txt | paste -sd+ - | bc | numfmt --g
4,524,886,867
$ dnsdbq -i 0.0.0.0/8 -A1d -l0 -j | jq -r '"(.count) (.rrname)"' | sort -nr > quad-zero.txt
$ wc -l quad-zero.txt
11996 quad-zero.txt
$ awk '{print $1}' < quad-zero.txt | paste -sd+ - | bc | numfmt --g
386,935,496
$ dnsdbq -i 127.0.0.0/8 -A1d -l0 -j | jq -r '"(.count) (.rrname)"' > temp.output
Query response missing: Data transfer failed -- No SAF terminator at end of stream
$ sort -nr temp.output > 127-dot-0.txt
$ wc -l 127-dot-0.txt
189983 127-dot-0.txt
$ awk '{print $1}' < 127-dot-0.txt | paste -sd+ - | bc | numfmt --g
11,008,698,658
This last query suffered a time out, which explains the “No SAF terminator at end of stream” caution (and why we split the processing pipeline into two explicit stages). If you’d like to know more about SAF, check out
In any event, it seems as if we’re finding an awfully lot of domains with addresses from private address space, but it’s easy to “misinterpret” the magnitude of those results.
Some effective 2nd-level domains are particularly-frequently-seen with FQDNs pointing at private address space addresses.
We can see this if we strip the “hostname part” of the FQDN and ignore the counts for each FQDN, and just count the number of variants we see for each effective 2nd-level domain (as defined in the Public Suffix List).
When we do that, our initial 635,954 “hits” for ten-dot.txt immediately drops to just 38,821 entries. We arrive at that figure with the following commands (note that each output domain has had a “real dot” replaced with [dot] in the following for this report as [.] for defanging runs the risk of being a valid regex and actually “working” for folks as a hostname):
$ awk '{print $2}' < ten-dot.txt | 2nd-level-dom | sort | uniq -c | sort -nr > 2nd-level-10-dot-only.txt
$ wc -l 2nd-level-10-dot-only.txt
38821 2nd-level-10-dot-only.txt
$ more 2nd-level-10-dot-only.txt
57457 amazonaws[dot]com
36368 rackspace[dot]net
18689 nba[dot]com
17124 handy[dot]com
16980 indeed[dot]tech
16333 fullcontact[dot]com
16285 ibops[dot]net
15751 compass[dot]com
13857 just-eat[dot]no
12986 aeg[dot]cloud
12927 just-eat[dot]fr
12788 zg-int[dot]net
11416 unity3d[dot]com
9541 spotify[dot]net
9137 datasw[dot]com
8239 upstart[dot]com
7329 grammarlyaws[dot]com
7003 atl-paas[dot]net
6449 dell[dot]com
6147 semrush[dot]net
5811 mobilevikings[dot]be
5579 linecorp[dot]com
5453 rambler[dot]ru
5324 ohthree[dot]com
5291 roblox[dot]com
5153 ovotech[dot]org.uk
5029 stg-myteksi[dot]com
[remainder of the 38,821 effective 2nd-level domains all have fewer
than 5,000 variants per effective 2nd-level domain]
Even talking about “38,821 effective 2nd-level domains” may still be somewhat misleading. For example, myfritz[dot]net is defined as an effective 2nd-level domain in the Public Suffix List (see https://publicsuffix.org/list/public_suffix_list.dat). If we check our ten-dot.txt results, we find that there are nearly 10,000 unique myfritz[dot]net “2nd-level domains” (those names actually look like three-part names with seemingly random hostname parts). For background on that service, see https://en.avm.de/service/myfritz/faqs/.
$ awk '{print $2}' < 2nd-level-10-dot-only.txt | reverse-domain-names | awk -F. '{print $1 "." $2}' | reverse-domain-names | sort | uniq -c | sort -nr > top-real-2nd-level-names.txt
$ more top-real-2nd-level-names.txt
9788 myfritz[dot]net
4193 remotewd[dot]com
1915 dattolocal[dot]net
604 quickconnect[dot]to
277 elasticbeanstalk[dot]com
239 herokuapp[dot]com
[etc]
Eliding the second eight bytes of each hostname with asterisks, those names look like:
$ grep myfritz[dot]net 2nd-level-10-dot-only.txt
602 0juuk2m7********.myfritz[dot]net
373 hxsm8mar********.myfritz[dot]net
264 wilg9cj6********.myfritz[dot]net
227 puom0trt********.myfritz[dot]net
226 tt9ykih8********.myfritz[dot]net
212 g5fad6r9********.myfritz[dot]net
209 xl74hi7f********.myfritz[dot]net
130 pu9qnk8t********.myfritz[dot]net
129 cs526jvi********.myfritz[dot]net
[etc, for a total of 9,788 lines]
“Digging-In” On Some of the Publicly Announced Private Address Space Results We Discovered
What do we see if we scrutinize a few of the results we found just a bit more closely?
Example A:
Picking one of the results at random and checking DNSDB for that specific name, we see:
$ dnsdbq -r comparison-production-internal.herokuapp[dot]com -A7d ;; record times: 2021-08-01 21:48:23 .. 2022-01-12 21:32:06 (~163d 23h 43m) ;; count: 21; bailiwick: herokuapp.com. comparison-production-internal.herokuapp[dot]com. A 10.0.4.56 comparison-production-internal.herokuapp[dot]com. A 10.0.22.80
Those IPs agree with what we see from the “live” or “real” DNS, too:
$ dig comparison-production-internal.herokuapp[dot]com +short 10.0.22.80 10.0.4.56
So DNSDB is “telling the truth” when it reports that it has seen some FQDNs with RFC1918 private address space (even though those RFC1918 addresses won’t “work” for those who aren’t connected directly to the “right” intranet or VPN).
Example B:
Interesting as that may be, let’s look at the very top (highest cache miss count) results for our 10-dot.txt file:
$ head ten-dot.txt 849544008 dc02-las.corp.shutterfly.com. 849542174 dc03-las.corp.shutterfly.com. 849542165 dc01-las.corp.shutterfly.com. 720679881 fwpaxd-dc01.fincoad.com. 651089519 fwpaxd-dc02.fincoad.com. 581760335 fwpaxc-dcec01.fincoec.com. 580849045 fwpldc-dcec01.fincoec.com. 580750639 fwpldc-dcec02.fincoec.com. 580262877 fwpaxd-dcec02.fincoec.com. 579554983 fwpaxd-dcecb01.fincoec.com.
The 849 million hits associated with that top result didn’t all happen during just the single day we asked to see from DNSDB if we check DNSDB we can see that those hundreds of millions of results spanned nearly four and a half years, so this is a configuration has been in place for a while:
$ dnsdbq -r dc02-las.corp.shutterfly.com/A ;; record times: 2017-09-25 18:31:09 .. 2022-01-13 23:03:21 (~4y ~111d) ;; count: 849547210; bailiwick: shutterfly.com. dc02-las.corp.shutterfly.com. A 10.83.57.20
We can use dig to query the “live” or “real” DNS to try to see how we end up “getting to” that value:
$ dig dc02-las.corp.shutterfly.com +short ; <<>> DiG 9.17.21 <<>> dc02-las.corp.shutterfly.com +short ;; global options: +cmd ;; connection timed out; no servers could be reached
Well! THAT didn’t work!
Let’s see what we get if we use the dig +trace option (we’ll suppress dnssec output to keep this to a reasonable length):
$ dig +trace +nodnssec dc02-las.corp.shutterfly.com [...] shutterfly.com. 172800 IN NS a18-66.akam.net. shutterfly.com. 172800 IN NS a6-64.akam.net. shutterfly.com. 172800 IN NS a11-64.akam.net. shutterfly.com. 172800 IN NS a1-203.akam.net. shutterfly.com. 172800 IN NS a26-67.akam.net. shutterfly.com. 172800 IN NS a13-65.akam.net. ;; Received 190 bytes from 2001:500:d937::30#53(l.gtld-servers.net) in 48 ms corp.shutterfly.com. 172800 IN NS dc03-las.corp.shutterfly.com. corp.shutterfly.com. 172800 IN NS dc01-las.corp.shutterfly.com. corp.shutterfly.com. 172800 IN NS dc02-las.corp.shutterfly.com. couldn't get address for 'dc03-las.corp.shutterfly.com': not found couldn't get address for 'dc01-las.corp.shutterfly.com': not found couldn't get address for 'dc02-las.corp.shutterfly.com': not found dig: couldn't get address for 'dc03-las.corp.shutterfly.com': no more
Hmm.
What if we explicitly query one of the name servers (as defined at the parent zone) to resolve the quoted names? Ah! Now we see the RFC1918 values, apparently supplied as glue records, presumably for an intranet-focused audience connected to an appropriate LAN or VPN:
$ dig dc03-las.corp.shutterfly.com @a18-66.akam.net [...] ;; AUTHORITY SECTION: corp.shutterfly.com. 172800 IN NS dc02-las.corp.shutterfly.com. corp.shutterfly.com. 172800 IN NS dc01-las.corp.shutterfly.com. corp.shutterfly.com. 172800 IN NS dc03-las.corp.shutterfly.com. ;; ADDITIONAL SECTION: dc02-las.corp.shutterfly.com. 1800 IN A 10.83.57.20 dc01-las.corp.shutterfly.com. 1800 IN A 10.83.56.20 dc03-las.corp.shutterfly.com. 1800 IN A 10.83.56.19
Example C:
Let’s consider a more “exuberant” example, this time associated with the 2nd highest effective 2nd-level domain name seen in our ten-dot.txt results file:
$ dnsdbq -r fwpaxd-dc01.fincoad.com/A -A7d ;; record times: 2019-01-11 19:07:40 .. 2022-01-13 22:32:19 (~3y ~3d) ;; count: 722663762; bailiwick: fincoad.com. fwpaxd-dc01.fincoad.com. A 10.79.66.11
What do we see if we check the “live” DNS? Thirty-four name servers for the child zone:
$ dig +trace +nodnssec fwpaxd-dc01.fincoad.com [...] fincoad.com. 172800 IN NS name1.dfsco.com. fincoad.com. 172800 IN NS name2.dfsco.com. fincoad.com. 172800 IN NS name3.dfsco.com. ;; Received 166 bytes from 2001:500:d937::30#53(l.gtld-servers.net) in 48 ms fincoad.com. 3600 IN NS fwphou-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcec02.fincoec.com. fincoad.com. 3600 IN NS fwpaxc-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpldc-dc02.fincoad.com. fincoad.com. 3600 IN NS fwpaxe-dc02.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcecb02.fincoec.com. fincoad.com. 3600 IN NS fwprhk-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwprhk-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxc-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpaxd-dns02.fincoad.com. fincoad.com. 3600 IN NS fwplan-dc01.fincoad.com. fincoad.com. 3600 IN NS fwphkg-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcecb01.fincoec.com. fincoad.com. 3600 IN NS fwpldc-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwprhk-dc02.fincoad.com. fincoad.com. 3600 IN NS fwpglm-dc01.fincoad.com. fincoad.com. 3600 IN NS fwphkg-dc02.fincoad.com. fincoad.com. 3600 IN NS fwpchw-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcb01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dc03.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpchm-dc01.fincoad.com. fincoad.com. 3600 IN NS fwppal-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpldc-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxe-dc01.fincoad.com. fincoad.com. 3600 IN NS fwplws-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dc02.fincoad.com. fincoad.com. 3600 IN NS fwradc-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpaxd-dcb02.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dns01.fincoad.com. fincoad.com. 3600 IN NS fwpsec-dc01.fincoad.com. fincoad.com. 3600 IN NS fwradc-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpldc-dcec02.fincoec.com. ;; BAD (HORIZONTAL) REFERRAL couldn't get address for 'fwphou-dc01.fincoad.com': not found couldn't get address for 'fwpaxd-dcec02.fincoec.com': not found couldn't get address for 'fwpaxc-dcec01.fincoec.com': not found couldn't get address for 'fwpldc-dc02.fincoad.com': not found couldn't get address for 'fwpaxe-dc02.fincoad.com': not found couldn't get address for 'fwpaxd-dcecb02.fincoec.com': not found couldn't get address for 'fwprhk-dcec01.fincoec.com': not found couldn't get address for 'fwprhk-dc01.fincoad.com': not found couldn't get address for 'fwpaxc-dc01.fincoad.com': not found couldn't get address for 'fwpaxd-dcec01.fincoec.com': not found couldn't get address for 'fwpaxd-dns02.fincoad.com': not found couldn't get address for 'fwplan-dc01.fincoad.com': not found couldn't get address for 'fwphkg-dc01.fincoad.com': not found couldn't get address for 'fwpaxd-dcecb01.fincoec.com': not found couldn't get address for 'fwpldc-dcec01.fincoec.com': not found couldn't get address for 'fwprhk-dc02.fincoad.com': not found couldn't get address for 'fwpglm-dc01.fincoad.com': not found couldn't get address for 'fwphkg-dc02.fincoad.com': not found couldn't get address for 'fwpchw-dc01.fincoad.com': not found couldn't get address for 'fwpaxd-dcb01.fincoad.com': not found couldn't get address for 'fwpaxd-dc03.fincoad.com': not found couldn't get address for 'fwpaxd-dc01.fincoad.com': not found couldn't get address for 'fwpchm-dc01.fincoad.com': not found couldn't get address for 'fwppal-dc01.fincoad.com': not found couldn't get address for 'fwpldc-dc01.fincoad.com': not found couldn't get address for 'fwpaxe-dc01.fincoad.com': not found couldn't get address for 'fwplws-dc01.fincoad.com': not found couldn't get address for 'fwpaxd-dc02.fincoad.com': not found couldn't get address for 'fwradc-dcec01.fincoec.com': not found couldn't get address for 'fwpaxd-dcb02.fincoad.com': not found couldn't get address for 'fwpaxd-dns01.fincoad.com': not found couldn't get address for 'fwpsec-dc01.fincoad.com': not found couldn't get address for 'fwradc-dc01.fincoad.com': not found couldn't get address for 'fwpldc-dcec02.fincoec.com': not found dig: couldn't get address for 'fwphou-dc01.fincoad.com': no more
So again, where do those 10/8 values come from, then? Well, let’s see if one of the name servers from the parent, such as name1.dfsco.com, knows about some of these name servers? Yep, looks like it:
$ dig fwphou-dc01.fincoad.com @name1.dfsco.com [...] ;; AUTHORITY SECTION: fincoad.com. 3600 IN NS fwpldc-dcec02.fincoec.com. fincoad.com. 3600 IN NS fwpaxe-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpldc-dc02.fincoad.com. fincoad.com. 3600 IN NS fwphkg-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpldc-dc01.fincoad.com. fincoad.com. 3600 IN NS fwradc-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpaxc-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpaxd-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dc03.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcecb01.fincoec.com. fincoad.com. 3600 IN NS fwpaxc-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dns02.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dns01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpaxd-dcb01.fincoad.com. fincoad.com. 3600 IN NS fwpldc-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwpaxd-dc02.fincoad.com. fincoad.com. 3600 IN NS fwphou-dc01.fincoad.com. fincoad.com. 3600 IN NS fwprhk-dcec01.fincoec.com. fincoad.com. 3600 IN NS fwplan-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcb02.fincoad.com. fincoad.com. 3600 IN NS fwradc-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcecb02.fincoec.com. fincoad.com. 3600 IN NS fwphkg-dc02.fincoad.com. fincoad.com. 3600 IN NS fwppal-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpchw-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpchm-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpsec-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpaxd-dcec02.fincoec.com. fincoad.com. 3600 IN NS fwprhk-dc01.fincoad.com. fincoad.com. 3600 IN NS fwpglm-dc01.fincoad.com. fincoad.com. 3600 IN NS fwprhk-dc02.fincoad.com. fincoad.com. 3600 IN NS fwpaxe-dc02.fincoad.com. fincoad.com. 3600 IN NS fwplws-dc01.fincoad.com. ;; ADDITIONAL SECTION: fwpldc-dc02.fincoad.com. 1200 IN A 10.166.60.12 fwphkg-dc01.fincoad.com. 1200 IN A 172.21.84.150 fwpldc-dc01.fincoad.com. 3600 IN A 10.166.60.11 fwradc-dcec01.fincoec.com. 3600 IN A 10.167.63.50 fwpaxd-dc03.fincoad.com. 3600 IN A 10.79.65.57 fwpaxd-dcecb01.fincoec.com. 3600 IN A 10.79.80.23 fwpaxd-dns02.fincoad.com. 1200 IN A 10.79.90.38 fwpaxd-dns01.fincoad.com. 1200 IN A 10.79.90.37 fwpaxd-dcec01.fincoec.com. 3600 IN A 10.79.80.11 fwpldc-dcec01.fincoec.com. 3600 IN A 10.166.63.50 fwphou-dc01.fincoad.com. 3600 IN A 10.139.116.87 fwprhk-dcec01.fincoec.com. 3600 IN A 10.242.56.21 fwpaxd-dcb02.fincoad.com. 1200 IN A 10.79.67.31 fwradc-dc01.fincoad.com. 1200 IN A 10.167.60.11 fwppal-dc01.fincoad.com. 3600 IN A 10.181.203.50
Private IPv4 Addresses Used as Coded Values In DNS-based “Distributed Databases”
While DNS was originally meant as a way of enabling easy-to-enter symbolic names for hosts, some have creatively repurposed DNS for their own purposes, often treating it as a sort of “distributed database.” This was discussed by one of this article’s co-authors (PV) as early as June 2004 (see http://dotat.at/tmp/bind-dnsind-perf.pdf). It is easy to find examples of this today:
Example A:
For example, the Oregon Routeviews project makes available a very helpful IPv4-address-to-ASN zone via the DNS. You can query it with commands such as:
$ dig 112.228.30.199.asn.routeviews.org txt +short "17318" "199.30.228.0" "22"
That means that the IP address 199.30.228.112 is announced by AS 17318, and the encompassing network prefix is 199.30.22.0/22.
This information is shared as a single TXT record, and DOESN’T entail the use of private address space, it merely illustrates the “DNS as a distributed database” concept.
Example B:
Many anti-spam block lists “signal” or “convey the block status” of an IP address or domain name via coded values in the 127.0.0.0/8 private address space netblock.
Farsight endeavors to avoid indexing proprietary block list data it may see in sensor traffic, but there are a lot of different block lists out there, and sometimes block list entries may end up included, best efforts notwithstanding.
Example C:
Malware-related FQDNs (such as some domain generation algorithm (DGA)) may also be sinkholed to localhost (or another private address space “destination”).
You may be able to identify those domains based on their domain Whois or their name servers (which may even explicitly mention “sinkhole”).
Is Private Address Space Leakage Actually a Problem?
We can, in summary, identify three primary risks associated with private address space leaking publicly:
- Private address space that leaks publicly may be disclosing details of internal network DNS assignments and architectures that don’t need to be disclosed, and which (from a network security perspective) probably shouldn’t be disclosed.
- Domain names with private IP addresses won’t work, except for the rare user who coincidentally happens to be on the right local network (or who’s VPN’d into that network). This may be an unintentional “saving grace” for publicly-leaked private address space.
- Domain names leaking private IP addresses may end up inadvertently “working,” but in unsafe or unexpected ways. For example, a local attacker on a shared network could intentionally advertise private address space so as to locally capture traffic from an itinerant user that was meant for a completely different remote host.
Bottom line, it’s encouraged that anyone who has names that currently resolve to private address space to not continue to publish those for the global Internet, unless they’re intentionally doing so for logically sound reasons.
Acknowledgements
The authors would like to thank David Waitzman and Daniel Schwalbe for their contributions in reviewing this article.
