DNS Enumeration and Finding Subdomains — Ethical Hacking: Penetration Testing Methodology

A company rarely has just one web address. Behind the main site there are often test environments, admin panels, old marketing pages and forgotten services, each one a potential door. In this lesson you will learn how DNS enumeration uncovers this hidden map, using only your own lab domains.

After the broad sweep of OSINT, DNS enumeration narrows the focus to the technical structure of a target's domain names. It answers a very practical question: "what addresses actually exist, that I should look at next?"

A short refresher on DNS

You saw the basics of DNS in the second course of this track. As a reminder: the Domain Name System translates names such as example.com into IP addresses, using several record types. The ones most useful for reconnaissance are:

A / AAAA: map a name to an IPv4 or IPv6 address.
CNAME: an alias pointing to another name, often revealing that a subdomain is hosted by a third-party service.
MX: mail servers, which can reveal which email provider an organisation uses.
TXT: free-text records, sometimes used for domain verification of third-party services, which can leak which services an organisation uses.
NS: the name servers authoritative for a domain.

Why subdomains matter so much

A main website is usually well maintained and well tested. A subdomain created two years ago for a marketing campaign, and forgotten, often is not. Testers care about subdomains because:

They expand the attack surface: more applications mean more code that can contain weaknesses.
Forgotten or staging subdomains (such as staging. or old. prefixes) sometimes run outdated software or skip security controls that production has.
A subdomain pointing, via CNAME, to a third-party cloud service that no longer exists can sometimes be claimed by someone else, an issue known as "subdomain takeover". Understanding this risk helps you flag it during analysis, even though exploiting it requires specific conditions you should only reproduce in a lab.

Passive enumeration: without touching the target

Like OSINT, some subdomain discovery is passive: it uses public records rather than sending requests to the target itself.

Certificate transparency logs: public, standardised logs of every certificate issued for a domain by participating certificate authorities. Because a certificate lists the exact names it covers, searching these logs for a domain often reveals many subdomains at once, without ever contacting the organisation's servers. This is a widely used, fully passive technique.
Search engine indexing: search engines sometimes index subdomains that are linked from somewhere else on the web.
Public DNS datasets: some research projects publish aggregated, previously observed DNS records.

Passive techniques are attractive because they generate no traffic towards the target and therefore nothing to detect, but they can only find what has already been observed by someone else.

Active enumeration: asking directly, inside scope

Active enumeration sends DNS queries directly, which is detectable and must only be done against systems in your authorised scope.

Zone transfer attempt: historically, some DNS servers were misconfigured to allow anyone to request a full copy of their zone (all records at once). Well-configured servers refuse this, but checking for it is quick and, when it works, extremely informative. It must only be attempted on domains you are authorised to test.
Dictionary-based brute force: trying common subdomain names (www, mail, vpn, test, dev, and so on) and seeing which ones resolve to an address. This generates many small DNS queries and should be done at a reasonable pace.
Reverse lookups: given an IP address range in scope, asking which names point to each address.

Practising in your lab

Your lab likely uses a local DNS resolver or a hosts file rather than real public DNS, which is exactly right for safe practice: you will learn the commands and reasoning without ever touching a real domain. A standard tool for manual DNS queries is dig, available on Kali Linux.

dig A lab-web01.lighthouse.test
dig MX lighthouse.test
dig NS lighthouse.test
dig AXFR lighthouse.test @192.168.56.22

The last command attempts a zone transfer (AXFR) from a specific name server. In a correctly configured environment it will be refused; in a deliberately vulnerable lab machine built to teach this concept, it may succeed and return the whole zone at once. Never run this kind of query against a domain outside your authorised scope.

From a list of names to a plan

Once you have a list of subdomains, do not treat them equally. Sort them by apparent sensitivity and apparent age:

Anything that sounds administrative (admin, vpn, internal) goes to the top of your list.
Anything that sounds like a test or staging environment (dev, staging, old) is next, since these are statistically more likely to contain weaknesses.
The main production sites come last for deep testing, but first for a quick, careful look, since they are what the business actually depends on.

Write this list into your journal. It becomes the direct input to the next lesson: port scanning.

Your fil rouge: mapping Lighthouse Labs

In your lab, create two or three fictional host names in your /etc/hosts file (on the attacker VM) pointing to your target machine's address, for example www.lighthouse.test, staging.lighthouse.test and mail.lighthouse.test, all pointing at 192.168.56.21. Then use dig to query each of them and record the results in 01-recon/dns-notes.md. This recreates, in miniature, the real-world task of turning a list of names into a target list.

Your turn: sort a subdomain list

Imagine a passive search returned this list of subdomains for a fictional company: www, api, vpn-admin, blog, staging-checkout, status, old-intranet. Sort them from highest to lowest priority for a tester, and explain your top two choices.

See a solution

A reasonable order: vpn-admin and old-intranet first (administrative access and a name suggesting an outdated, possibly unmaintained system), then staging-checkout (a staging version of a sensitive payment flow), then api (a direct interface worth testing), then www and blog (usually more mature, but still worth a pass), and finally status (often a simple public status page with low sensitivity). The exact order can vary, but the reasoning about administrative and staging names being higher risk should appear in any good answer.

Tip

A subdomain with an old-sounding name is not automatically vulnerable, and a modern-sounding name is not automatically safe. Treat your sorted list as a plan for where to look first, not as a conclusion.

Key takeaways

Subdomains expand the attack surface and are often less maintained than the main site.
Passive techniques, such as certificate transparency logs, find subdomains without contacting the target.
Active techniques, such as zone transfer attempts and dictionary brute force, must stay strictly inside the authorised scope.
Sort discovered subdomains by apparent sensitivity and age to plan the next steps.
Tools such as dig let you query DNS records directly in your lab.

With a prioritised list of hosts, the next lesson shows you how to find out which doors are actually open on each one: port scanning.