DNS enumeration

Objective 2.2 in this course covers enumeration techniques — CompTIA describes it as performing DNS enumeration, service discovery and directory enumeration. This lesson takes DNS; lessons 10 and 11 take the other two.

Why this matters

DNS is the map. Before you can test an estate you have to know what is in it, and in most organisations the authoritative statement of what exists is the DNS zone — not the asset inventory, which is out of date, and not the client's memory, which is selective.

It is also where the highest-value early findings come from. The host nobody remembered is nearly always found here or in certificate logs, and "you have an administrative interface published to the internet that your own inventory does not list" is a finding that writes itself.

The lesson

Records that describe infrastructure to anyone who asks

Each record type answers a different question, and knowing which to ask for is most of the skill:

• A and AAAA — the addresses a name resolves to. The starting point for mapping names onto ranges. Check both; IPv6 is frequently forgotten by the people writing firewall rules.
• CNAME — aliases. Valuable because they expose third-party dependencies: a name pointing at a cloud provider or SaaS vendor tells you who really hosts it, and therefore who you are not authorised to test.
• MX — mail infrastructure, which tells you whether mail is self-hosted or delegated, and to whom.
• NS and SOA — who is authoritative, and the administrative contact. Also reveals whether DNS is run in-house or outsourced.
• TXT — the most talkative record type in practice. Sender policies name the services permitted to send mail as the organisation, which is an inventory of their SaaS estate. Domain-verification strings name every platform they have ever signed up to.
• SRV — service locations, which in directory environments point directly at the infrastructure worth knowing about.
• PTR — reverse records, which are how you go from an address range back to names.

Zone transfer, and why it still sometimes works

A zone transfer asks a name server for the entire zone at once. It exists for replication between authoritative servers, and it should only ever be permitted to those servers.

When it is left open, it hands over the whole map in a single query — every name, every address, including everything internal that was never meant to be public. It is the single highest-yield DNS misconfiguration, which is why it remains a staple of both the exam and real engagements.

It persists because it is a default on some software, because a secondary was added years ago and the restriction was never tightened, and because nobody tests for it. Try it against every authoritative server for the domain, not just the first — the restriction is per-server, and an estate is only as closed as its most forgotten secondary.

When it fails, that is the normal and correct result, and you move to the techniques below.

Subdomain discovery by brute force and by certificate logs

Where a zone transfer is refused, names have to be discovered one at a time. There are two complementary routes, and using only one is how testers miss half the estate.

Brute force resolves candidate names from a wordlist. It finds names that resolve now, including internal-only ones if you are querying from inside. It is limited entirely by the wordlist — a generic list finds generic names, and names built from the organisation's own vocabulary (product names, office locations, project codenames gathered in lesson 7) find the interesting ones.

Certificate transparency, from lesson 7, finds names that have ever had a publicly-trusted certificate issued — including ones that no longer resolve, and ones that were never meant to be public. It is passive and it costs nothing.

They find different sets. Brute force finds live names with no certificate; certificate logs find names that are firewalled, retired or not yet launched. Do both, then resolve the union.

A third route worth knowing: if the zone uses DNSSEC with NSEC, the proof that a name does not exist can name the next record that does, allowing the zone to be walked. NSEC3 exists to mitigate this.

Internal names that leak through split-horizon mistakes

Many organisations run split-horizon DNS: the same zone answers differently inside and outside. Internal clients get internal addresses; the world gets the public ones.

The mistakes are common and productive:

• Internal names in the public zone, so a name intended only for staff resolves for everybody — often to a private address, which tells you the internal addressing scheme without touching the network.
• A resolver that answers recursively from the internet, which both leaks internal answers and is an abuse risk in its own right.
• Stale public records pointing at addresses the organisation no longer controls. This is worth flagging loudly: if a record points at a cloud address that has been released, anyone who claims that address inherits the name. That is a dangling-record takeover, and it is a finding in its own right.

A private address in a public DNS answer is not itself a vulnerability. It is information disclosure, and it is reported as such — with the internal scheme it revealed as the impact.

Mapping what you found back to owned address space

Names are not targets. The output of this lesson is a set of names and the addresses they resolve to; the next question is which of those addresses the client actually controls.

Resolve every name, collect the addresses, and group them into ranges. For each range, establish who it is registered to. Three outcomes:

• Registered to the client — in scope if the scope says so.
• Registered to a hosting or cloud provider — the client may own the workload, but the provider owns the infrastructure, and lesson 4's rules apply.
• Registered to someone else entirely — either a third-party dependency or a name that no longer belongs to the client. Report, do not test.

This is the step that stops a test straying. A hostname in the scope document is an instruction to test a name, and names move: verify the address before you attack it, and re-verify if the engagement runs across days.

What to take into the exam

• Know what each record type discloses; TXT records are an inventory of the organisation's SaaS estate.
• Try zone transfer against every authoritative server, not just the first.
• Brute force and certificate transparency find different sets — do both.
• A private address in a public zone is information disclosure; a record pointing at a released cloud address is a takeover risk.
• Resolve names to addresses and confirm ownership before testing; a name is not a target.