There are several directions an organization can take when naming critical digital properties. A classic tactic is using a common theme, such as pet names, planets, or colors. A CTO suggested naming database nodes after “Game of Thrones (GoT)” characters. Taking this route makes for an obscure naming system that would be difficult for third parties to guess.

However, we don’t always see enterprises implement this tactic today, at least not when it comes to filling in DNS records. One can argue that with hundreds of domain and DNS records and other digital properties an organization can own or manage, there can only be so many pet names, dog breeds, and GoT characters. Plus, what if the employee who named the systems leaves the company without going through a proper turnover process? It would take a while to figure out what those names refer to.

The Shift to More Descriptive Naming

Many administrators use web server names, locations, vendor names, and other descriptive naming systems. These names may be more challenging to remember and type, but there’s no need to guess what they are for. This naming mechanism is convenient and scalable—two top qualities to look for in a system.

While this strategy could be ideal for properties that are only accessible internally, applying the same tactic can be harmful for publicly accessible data, such as DNS record contents.

Putting “Citrix” or “Linux” on your TXT record, for example, may tell threat actors to look for vulnerabilities in these systems. Because of the DNS record values, attackers’ reconnaissance efforts are made shorter, and their initial attack can be deployed earlier.

We saw the same overly descriptive naming trend across subdomains. More than 96,000 subdomains were named after their cloud service providers, revealing part of targets’ infrastructure to competitors and threat actors.

Examples of Descriptive DNS Record Contents

We found several domains and subdomains with highly descriptive TXT values, such as “XenApp server 03 Citrix” and “Xen Citrix Test platform.” While this naming system is convenient for administrators, it could expose the organizations to known and unknown vulnerabilities (zero-days) related to those systems. Here is a screenshot of the Reverse DNS Lookup result:

We found a similar scenario for several organizations using Linux, which also has some exploitable vulnerabilities:

To further analyze how often software and vendor names appeared in DNS records, we looked at DNS data feeds dated 25—31 October 2021, which contained a total of 1,048,576 records.

Three of these names point to commonly exploited systems (Linux, Sharepoint, and Fortinet). The other three are communication platforms that are usually part of shadow IT—Skype, Discord, and Slack.

Implementing a naming system requires planning, regardless of the machines it will apply to (database nodes, servers, or DNS records). Though selecting non-descriptive names can be lead to more operational complexities than naming properties as they are, here is a non-exhaustive list of term categories that probably reveal a little too much about your digital infrastructure:

• Server names
• Software/IT infrastructure vendor names
• Marketing software vendor names
• Names of communication tools, such as chat applications
• Content management system (CMS) names

Do not hesitate to contact us if you’d like to learn more about how WhoisXML API’s DNS intelligence can help uncover overly descriptive DNS record contents to support attack surface management efforts.