DNS Parlor Tricks for Network Discovery

|
Updated

DNS is an amazing protocol. After starting life as a simple mechanism for name resolution, it is now used to enforce TLS rules, prevent email impersonation, authorize users, protect endpoints, enable service discovery, and much more. DNS services run across a range of devices and provide quite a bit of information about the environment, given the right queries. This post describes the techniques used by the Beta 2 version of Rumble Network Discovery to identify DNS services.

Version via TXT VERSION.BIND #

The version.bind TXT response is supported by a handful of common DNS implementations, including ISC BIND, and returns the name and version number of the service. This can be correlated against public fingerprints to determine the operating system and version. Querying this by hand is easy with dig:

$ dig version.bind txt chaos @target-dns
version.bind.           0       CH      TXT     "9.11.3-1ubuntu1.5-Ubuntu"

Hostname via TXT HOSTNAME.BIND #

The hostname.bind TXT response is less common, but supported by newer versions of ISC BIND and a few other DNS server implementations. This query returns the hostname of the DNS server itself. This is also simple to query by hand using dig:

$ dig hostname.bind txt chaos @target-dns
hostname.bind.          0       CH      TXT     "ns01"

Internet A Query #

Rumble will send an A record lookup for a common internet domain name.This lookup returns the resolved address for the name, indicating whether a DNS-based captive portal is in place, and whether DNS queries are being modified. This lookup is equivalent the following command:

$ dig www.google.com A @target-dns
www.google.com.         30      IN      A       172.217.8.164

Destination PTR Lookup #

In addition to queries above, Rumble will ask the server for a PTR record for it's own IPv4 address. This can return the internally-configured hostname of the server, making identification more accurate, especially when normal reverse DNS and the hostname.bind result is not available. An example of doing this query using the dig command:

$ dig 254.0.168.192.in-addr.arpa PTR @target-dns
254.0.168.192.in-addr.arpa.   20384   IN      PTR     firewall.lab.

Trace Request to rumble.network #

Rumble will send a DNS query for a randomized subdomain of rumble.network with the destination server address and timestamp encoded into the request. A custom DNS server handles these requests, echoes the timestamp, and returns the IP addresses of the requesting DNS resolvers back to the server, which forwards it on to the Rumble scan engine. This process acts as a DNS traceroute and can identify problems with the destination server's performance and configuration. The DNS service details within the Rumble console will show the upstream resolvers:

DNS Upstream Resolver Detection

EDNS0 Request to rumble.network #

Rumble will send a second DNS query for a randomized subdomain of rumble.network, identical to the first, except using a different prefix (e0 vs t0) and with the EDNS0 flag set. If the destination server supports the Client Subnet extension, this will be sent to the rumble.network DNS server, which will encode the received subnet information back into the response. This can identify the egress network used by the DNS server, which can be helpful when diagnosing configuration issues. An example

DNS Client Subnet Detection

Continuing Work #

The five queries described above are designed to be safe and informative, but are just the beginning of Rumble's support for DNS. We are continuing to look into service discovery and specific product fingerprinting that would help with asset identication and inventory. If you haven't had a chance to try runZero yet, please give it a shot and share your thoughts.

Written by HD Moore

HD Moore is the founder and CEO of runZero. Previously, he founded the Metasploit Project and served as the main developer of the Metasploit Framework, which is the world's most widely used penetration testing framework.

More about HD Moore
Subscribe Now

Get the latest news and expert insights delivered in your inbox.

Welcome to the club! Your subscription to our newsletter is successful.


Related Articles

runZero Insights
Taming the Typhoons: How runZero Keeps You Ahead of State-Sponsored Cyber Threats
China's Typhoon cyber attacks are evolving, but runZero helps you stay one step ahead with unmatched visibility and proactive defense.
runZero Insights
Ensure compliance with DORA’s ICT risk framework using runZero
Learn how to uncover unmanaged and unknown assets— including IT, OT, and IoT— to meet DORA's hidden risk requirements using runZero.
Life at runZero
Employee Spotlight: Doug Markiewicz
Doug Markiewicz is a strategic Customer Success Engineer with a passion for solving complex cybersecurity problems. Learn more about his journey as...
runZero Insights
Evolving from IT to IoT: Flax Typhoon preyed on the lesser knowns
A look at Flax Typhoon's latest operations, and how runZero’s unknown and IoT asset visibility can help calm the storm for security teams.

See Results in Minutes

Get complete visibility into IT, OT, & IoT — without agents, credentials, or hardware.

© Copyright 2024 runZero, Inc. All Rights Reserved