DNS Ping Scans via Open Resolvers

April 2, 2019, by

HD Moore

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 A and 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, the resolver will ask the Rumble DNS server for the NS record of the encoded subdomain, get a response that resolves to, and then send a DNS request to 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 can talk to the internet and to the DNS server at, but is not allowed to communicate with the retail point of sale subnet 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              alive via                60ms       code:2              alive via                69ms       code:2             alive via               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                 alive via A.B.C.D:53                    75ms       code:2                 alive via A.B.C.D:53                    79ms       code:2                 alive via A.B.C.D:53                   165ms       code:2                 alive via A.B.C.D:53                    72ms       code:2

Note that the latency of 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                  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                    alive via                   166ms       code:2

The reverse works well too:

$ rumble-dnsrp -quiet                    alive via                    56ms       code:2                    alive via                    47ms       code:2

We can also ask public DNS servers to scan random internet subnets for us:

$ rumble-dnsrp -quiet               alive via                    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. Error code 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 Rumble 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 (v1.nxdomain.us). If you have a Go environment configured and the $GOPATH/bin directory in your path, the following command will install the client (rumble-dnsrp):

$ go get github.com/RumbleDiscovery/rumble-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

Similar Content

October 5, 2021

Rumble 2.7: New dashboard, multi-subscription Azure, AWS ELBs, Splunk add-on improvements, and faster discovery for Rumble Professional

What’s new with Rumble 2.7? User experience improvements Get insights, trends, and visualizations from your dashboard Easily navigate configuration pages for scans, imports, connections, and more Know when your connector credentials are invalid Integration …

Read More

September 30, 2021

Fingerprinting Windows build numbers

Our goal at Rumble is to help customers identify everything on their networks, quickly, and without authentication. This process is driven by research, which often leads to dead ends, but sometimes we learn interesting things along the way. This post explores recent research …

Read More

September 8, 2021

Rumble 2.6: Integrate with Microsoft Azure Cloud, identify EOL assets, self-host in offline mode, and detect more protocols

What’s new with Rumble 2.6? Synchronize your Azure VM inventory with Rumble Identify assets running end-of-life OS versions Support for NFS, PPTP, and “r” services Updates to the CrowdStrike integration Install and update self-hosted Rumble in offline mode See new …

Read More