Episode 4-Enumerating DNS: Public by Intent… Public by Intent!?!

Got another anecdotal one this week! In a short summary, here, I will walk through the role that DNS, and DNS servers play in an enterprise network. Then, I’ll demonstrate how we can glean basic information from a public-facing DNS server during an engagement (in a typical and secure state), and further how we can gather a truly astonishing amount of information from the service if admins haven’t taken basic precautions to secure it.

This is another article in the series of releases I’ve been doing while going through OSCP. This kind of writing greatly helps me review, and I hope that it can provide some insight to others who might be getting started.

We will be interacting with the domains gmail.com and ZoneTransfer.me. The later is a domain operated by Robin at digi.ninja, and allows us to play with a misconfigured DNS server to demonstrate some important effects. It is important to note that these requests touch a target server, and as such the ethics and laws pertaining to active enumeration must be diligently considered.

We got the job!…

Here’s the situation: the fictional domain SuperSecure.com just finished up inking a contract with our sales team, and they’ve handed it off to us to start the engagement. We’ve done all our passive reconnaissance, and are ready to begin our active enumeration methods, meaning methods where we are physically interacting with devices on the target network. One of the first things we are going to do is start interacting with the DNS server.

The Purpose of DNS

Domain Name System (DNS), TCP/53 and UDP/53. By the name, you might be able to guess its purpose, which is taking domain names and translating them into addresses as well as serving additional records. A DNS server exists to serve addresses of nodes on a network when someone requests a server by name, as well as information about that domain–kind of like a phone book. For example, if I need a mail server for SuperSecure.com, I would ask the publicly advertised DNS server, and it should provide me that IPv4 or IPv6 address as well as the fully qualified domain name (FQDN). Then I know what the mail server is, and can send some email to someone on that domain (or maybe other traffic……).

Zone Transfer

A large number of networks run more than one DNS server. Typically you have an authoritative server that is the root of the domain and knows everything, and then others scoped for specific areas on the business. This is kind of like a proxy concept, where, if a user requests records that the server doesn’t have, it will reach out to the other DNS servers it knows about and ask if anyone else has that information. In order for the child servers to keep their databases up to date, they use a process called zone transfer, in which they request all the relevant records from the master server (typically at a set interval). In a secure system, these children will be appropriately segregated and the master will have a whitelist of what clients can legally request the transfer. Think root, intermediary, and leaf, just like certificate chaining.

Deriving Everything We Can in a Secure State

To further expand on these points: email is one of the main reasons DNS services exist. When I send email to r0oTm3@gmail.com, my email provider asks DNS for the addresses of gmail.com’s mail server. Using the $hosts command I can manually identify that google advertises five mail servers. We use the t flag for type, and mx to specify mail servers. For clarification on the pipe to sort, you see numerical order (n) by the 6th column(-k6). Sort will assume a default delimiter of ” ” (space) if you don’t specify otherwise.

Figure 1.1

At this point, my email provider can attempt to request the highest-priority (lowest number: 5 in this case) server’s address and now knows where to send the email traffic. Typically there will be multiple servers and if the highest-priority one fails for any reason, you end up with the next in succession.

The important point here is that especially for the purpose of email, there is an inherent need for DNS servers to answer public queries.

What Kind of Information Should We Get in a Secure-State?

DNS is intentionally public. It exists to serve information so that people can interact with domain services such as email. This is critical for normal operation, so in a namely secure state, we can still derive some information about the domain from it.

I will typically start my DNS enumeration using the $hosts command, with the -t flag to define the type as either a name server (“ns”), or mail server (“mx”). With these flags, we can gather the nameservers and mail servers for the domain, and then resolve them, and we have our first list of potential gateways into a local subnet (which are at least very likely, if not guaranteed, to be alive). That process looks like this:

Figure 1.2

We can even turn it into a reusable one-liner with $read, $cut and $xargs:

Figure 1.3

Other information that we can gather includes text, cname, and many other records simply by using the -t flag for type with the host command. For more information on this please check out the $host man page.

What If There Are Misconfigurations?

Ignorant or otherwise distracted admins may misconfigure a DNS server, and in that case, we might be able to map out a complete picture of what’s sitting on a network. This can even get so bad that we could potentially glean LAN information (from the outside) as well. The most important misconfiguration is that of zone segregation and not setting the proper whitelist for who can request zone-transfer. Let’s demonstrate an enumeration strategy on the intentionally misconfigured domain ZoneTransfer.me, run by Robin from digi.ninja.

We start by identifying the visible name servers… we get two:

Figure 1.4

We then can simply use the ‘l’ flag with $host to request a zone transfer and if there is a misconfigured server, we get a shocking dump of information:

Figure 1.5

As you can see, this kind of misconfiguration leads to the exposure of a everything. Domain controllers, endpoints, critical security infrastructure; you name it–anything with a DNS record is exposed and its IP is even provided. It’s critical that proper whitelisting and record segregation is ensured for this reason specifically.


Obviously DNS serves a very important purpose on a network and just like a web server, it needs to be publicly accessible to serve a majority of its purpose. With that concept of facing the public internet, we need to ensure the security of that server. Not only the DNS config, which obviously needs to be scrupulously managed, but further the server itself. Many admins overlook basic security concepts such as password hygiene and principal of least privilege. If it’s going to be a potential gateway into the network, we must consider just like any other server and lock it down accordingly!