One of the goals in analyzing the DNS query and response stream is to understand possible issues customers might be experiencing with your infrastructure or unwanted traffic being sent to your servers. The last post covered traffic profiling by request type and response code. Covering this topic brought to mind some observations about reverse-tree DNS queries (often just called “reverse queries” these days). These queries associate an IP with its name in the DNS. They are implemented using the in-addr.arpa (IPv4) and ip6.arpa (IPv6) zones and PTR records.
There are constant debates about the importance of reverse DNS resolution; this may be centered around RFC 1912 section 2.1 stating “Every Internet-reachable host should have a name.” This is followed by explicitly stating “For every IP address, there should be a matching PTR record in the in-addr.arpa domain.” One thing to keep in mind is this RFC was drafted at a time when IP assignments were generally static, so in many cases there was a one to one relationship between the IP address and a physical device. As people adopted NAT (Network Address Translation) and DHCP (Dynamic Host Configuration Protocol), the utility of the reverse tree became less obvious. NAT eroded the one to one mapping creating questions about accuracy cardinality of IP to PTR relationships and DHCP increased the rate of change of IP assignments. The fact that maintenance of the reverse tree need to be mentioned in the RFC shows that the concern was budding even back in 1996.
Misconfiguration of reverse DNS is of special interest as it requires the owner of the IP space to ask their Regional Internet Registry (RIR) to delegate the reverse DNS domains to their DNS provider. The owner makes a conscious decision to change the delegation of the records, but doesn’t always follow through on the maintenance and configuration. As an authoritative DNS provider this is something we see somewhat frequently, mainly in the form of delegated resources without configuration. Do you have your own IP space? Is it delegated to your DNS provider? Is the configuration up to date?
Configuring reverse DNS isn’t always as straightforward as it sounds. For instance, Amazon Web Services requires submitting an electronic form from an account with root access, whereas Digital Ocean configures reverse DNS by default after you provide a hostname for your virtual server. This provisioning behavior is most likely driven by the expected response to the question, “How many users are going to find value in having their details entered in the reverse tree?” From the provider’s perspective it might be a case of minimizing DNS updates the customers aren’t asking for. That being said, RFC 1912 reminds readers, “Many services available on the Internet will not talk to you if you aren’t correctly registered in the DNS.” This still holds true in cases such as email systems (including spam filters / appliances) which perform a reverse DNS lookups on the IP address of the originating SMTP server.
Looking at PTR queries is a great way to answer the question, “Do you know what is trying to talk to your infrastructure?” When an SSH connection is attempted, most modern operating systems will perform a reverse DNS lookup on the host attempting to connect, very similar to the SMTP verification mentioned earlier. So when 192.0.2.1 and 192.0.2.134 are trying to SSH into your cloud instances by brute force, the default resolver configured in /etc/resolv.conf will recieve these requests. How are you identifying these activities in your environment? If you are a large cloud provider are you measuring these query patterns across customers, data centers, and sites? Or on the other side, if the reverse tree is misconfigured you might be increasing attention on traffic from your endpoints by causing additional NXDomain responses to in-addr.arpa queries.
Some argue the exact opposite that properly configured reverse DNS creates a security issues. Reverse DNS can help an attacker enumerate what resources in the environment support what domains. The reverse tree was also leverage in the past to “enhance security” to questionable effect. The basic notion being that a list of trusted hosts could be whitelisted and identification verified via PTR record. Knowledge of past misuse and potential for information leakage help contextualize the risk reward of reverse tree maintenance.
What should the reader do once they finish reading this post?
Review your current DNS settings (internal and external) and establish an understanding of your PTR record configuration. Determine how much of your infrastructure is fixed vs. ephemeral and use this survey to quantify reverse DNS maintenance. Map out the internal and external recursive resolvers your servers are configured to query as this will impact your data collection options. Review your current DNS log collection and storage to understand potential blind spots in intersystem communication.