What Is Reverse DNS

Reverse DNS (rDNS) is the process of discovering a name from an IP address input, whereas “traditional” DNS lookups accomplish the opposite feat by translating a hostname to an IP. 

dig -x 24.117.59.59

Example of reverse DNS lookup on a Mac (using Terminal)

nslookup 24.117.59.59

Example of reverse DNS lookup for Windows and Linux

Specifically, rDNS entails resolving the IP value in reverse with “in-addr.arpa” appended at the end.1 Thus, the command in the example above will actually look up “59.59.117.24.in-addr.arpa”. If the owner of the IP successfully configured rDNS, this query will return a “pointer” (PTR) record, which associates the IP with a domain:

59.59.117.24.in-addr.arpa. 43200 IN PTR 24-117-59-59.cpe.sparklight.net.

While rDNS is not universally adopted for traditional web traffic, PTR records are particularly important for email servers, which often perform rDNS lookups to block or filter out spam. To ensure messages are received without any red flags, legitimate email providers are required to properly implement rDNS for IP addresses and forward DNS for the resulting hostnames. This expectation was established to prevent spammers from sending emails from compromised machines since these IPs often don’t have rDNS records, and when they do, the response is frequently a generic, dynamic output that suggests the client is not a valid email service.

As shown above, the residential IP 24.117.59.59 points to a 24-117-59-59.cpe.sparklight.net PTR record, which is a dynamic output, as it is simply the IP address with the sparklight domain appended. So if a spammer were to hack the machine and send an email from the residential IP, the receiver would likely block or filter the message since dynamic responses are a strong spam signal (for reference, a hypothetical acceptable response would be email.sparklight.net). In short, a spammer would have to own an IP space to arrange the necessary DNS settings for the message to be universally accepted — a prohibitive cost for most threat actors.

Finally, some email servers rely on more nuanced rDNS settings with the help of SMTP (Simple Mail Transfer Protocol), a standardized communications protocol for email transmission. For example, email servers can be configured to reject emails when the rDNS query does not match the HELO command, a message that starts the SMTP session. Thus, if a botnet was able to send thousands of emails from hundreds or thousands of hijacked machines belonging to a variety of networks, it would be difficult for the malicious actor to announce the correct domain in each HELO message, even if rDNS was properly configured for the IP. 

Client: HELO mail.example.com

Server: 250 mail.example.com Hello

For an rDNS lookup to return a valid response, an in-addr.arpa rDNS zone file will need to be created that reflects the fixed network range allocated to the IP owner. Specifically, the zone admin should remove the last dotted quad that contains the values explicitly under their control, reverse the order of the remaining dotted octet, and append .in-add.arpa.

Since Sparklight owns a Class B address, their rDNS zone file name is 117.24.in-addr.arpa. Looking at the full resolution process, ARPA owns the 24.0.0.0/8 Class A addresses2 but delegates 117.24 queries to Sparklight:  

Just like with forward DNS, each “dot” in an rDNS hostname is a potential delegation point. ICANN manages the in-addr.arpa zone and delegates subzones to owners of an IP space.