DNS Ping Scans via Open Resolvers
Our last post covered some of the ways that Rumble gathers information from DNS services.
While working on the tracer implementation, we identified a trick that other folks might find it useful. It turns out that most DNS resolvers do not filter the address ranges they will contact when handling a request, allowing for remote subnet “ping scans” with a little work. This technique isn’t foolproof, and is probably not new, but it may have interesting security implications.
The Rumble DNS Server #
To support the DNS trace requests used by Rumble, we built a reflective DNS server in Go, based on the Miek Gieben’s reflect.go sample. This DNS service
will return the resolver address in the response for
AAAA queries, along with the port number for
TXT queries. In addition to the trace request,
this service will read EDNS0 Client Subnet information and return the subnet data as an encoded
CNAME response. Finally, and most relevant to this post,
this service will return a
NS response for certain queries as a decoded value of the question. This allows clients to ask the resolving DNS server to
contact arbitrary nameservers by address.
DNS Remote Ping Scan #
On the client side, we send a DNS request with a name formatted like the following:
If we send this request to an open resolver with the encoded address of
192.168.0.1, the resolver will ask the Rumble DNS server for the
record of the encoded subdomain, get a response that resolves to
192.168.0.1, and then send a DNS request to
192.168.0.1 asking for the
entire name. This is nothing new and one of the basic features of DNS, but can lead to some surprising results.
Segmented Discovery #
VLAN segmentation is often used to prevent wireless guest users from reaching corporate assets directly, while still allowing these users
to query the internal DNS server. This configuration can be abused by our DNS technique to perform a remote ping scan of the corporate network
from the guest VLAN. In the example below, the client at
192.168.0.150 can talk to the internet and to the DNS server at
but is not allowed to communicate with the retail point of sale subnet
192.168.30.0/24. The client will use the technique outlined
in this post to perform a ping scan of the retail subnet through the shared DNS resolver:
$ rumble-dnsrp -quiet 192.168.0.1 192.168.30.0/24
192.168.30.29 alive via 192.168.0.1:53 60ms code:2
192.168.30.34 alive via 192.168.0.1:53 69ms code:2
192.168.30.143 alive via 192.168.0.1:53 267ms code:2
Private Cloud Subnets #
If the DNS server is hosted in a cloud environment, there is a good chance that this technique can be used to scan the private subnets. The example below demonstrates scanning a remote Amazon VPC using an internet-exposed open resolver:
$ rumble-dnsrp -quiet My.Cloud.DNS.Server 172.31.0.0/24
172.31.0.1 alive via A.B.C.D:53 75ms code:2
172.31.0.2 alive via A.B.C.D:53 79ms code:2
172.31.0.3 alive via A.B.C.D:53 165ms code:2
172.31.0.4 alive via A.B.C.D:53 72ms code:2
Note that the latency of
172.31.0.3 is a bit more than double that of the other hosts; we can infer that this is
not only a live system, but one also running an open resolver. This behavior can also be tested by sending a query
for the loopback address, which can also result in a double lookup with the expected latency:
$ rumble-dnsrp -quiet My.Cloud.DNS.Server 127.0.0.1
127.0.0.1 alive via A.B.C.D:53 160ms code:2
Testing Connectivity #
This technique also allows us to check the latency between two sites. For example, we can ask the Google DNS servers to scan the Cloudflare subnet:
$ rumble-dnsrp -quiet 188.8.131.52 184.108.40.206/24
220.127.116.11 alive via 18.104.22.168:53 166ms code:2
The reverse works well too:
$ rumble-dnsrp -quiet 22.214.171.124 126.96.36.199/24
188.8.131.52 alive via 184.108.40.206:53 56ms code:2
220.127.116.11 alive via 18.104.22.168:53 47ms code:2
We can also ask public DNS servers to scan random internet subnets for us:
$ rumble-dnsrp -quiet 22.214.171.124 126.96.36.199/24
188.8.131.52 alive via 184.108.40.206:53 75ms code:2
Response Criteria #
The previous examples all result in DNS queries being sent from the nameserver to addresses we choose. The tool assumes the target is “alive” if one of the following is true:
- The target runs a DNS server and replied with an error
- The target sent back an ICMP unreachable (no DNS service)
If the received error code is not
2 or the request timed out, one of these conditions wasn’t met.
5 generally means the nameserver refused to perform our query (its authoritative only, not an open resolver).
Open Source Tools #
If you would like to try this technique, you can grab both the Rumble DNS Server
and the DNS Remote Ping utility from the runZero Tools repository.
Unless you would like to run your own nameserver, the DNS Remote Ping utility may be all you need, which will use a subdomain hosted by us by default (
If you have a Go environment configured and the
$GOPATH/bin directory in your path, the following command will install the client (
$ go get github.com/runZeroInc/runzero-tools/cmd/rumble-dnsrp
Moving Forward #
Our goal is to build the best products for IT and security professionals through applied research. We hope that you found this detour into DNS behavior interesting and that you will check out our product, Rumble Network Discovery
August 8, 2022
runZero 3.0: Check out our new name, and sync assets, software, and vulnerability data from Qualys
What’s new in runZero 3.0? Meet our new brand: runZero!
July 12, 2022
Rumble 2.15: Sync assets, software, and vulnerability data from Rapid7, scan external domains from our cloud, and report on external assets and services
What’s new with Rumble 2.15? # Sync assets, software, and vulnerability data from Rapid7 InsightVM and Nexpose Quickly identify and report externally exposed assets and services Navigate your inventory faster with an updated Rumble Console Gathering vulnerability data …Read More
June 14, 2022
One ping to find them: lean network discovery
Our engineering team focuses on getting the maximum amount of information from the network while sending as little traffic as possible. This lean approach to network discovery is driven by our goal of being fast and safe for all networks. The more we can learn about a system …Read More
Subscribe and stay in the loop!
We won't share your email.
Unsubscribe at any time.