DNS

Overview

DNS (the Domain Name System) is the internet's phone book: it translates human-friendly names like web.ctf.local into the IP addresses machines actually route to. In CTFs, DNS is both a tool and a target — you use it to resolve names, and you enumerate it to discover hidden hosts (subdomains and virtual hosts) that a challenge deliberately hides behind a name. Understanding DNS turns a single known host into a map of a whole environment.

This lesson explains how name resolution works and how DNS enumeration fits into safe, authorized recon.

Learning objectives

• Explain the purpose of DNS and the resolution process.
• Identify common DNS record types and what each does.
• Describe subdomain and virtual-host enumeration at a conceptual level.
• Explain why editing your local hosts file is often needed in CTF labs.
• Relate DNS enumeration to expanding a known, authorized attack surface.

Core concept

Computers route on IP addresses, but humans use names. DNS bridges the two by mapping names to addresses (and other data) through a distributed, hierarchical system of servers. When you type a hostname, your machine performs name resolution to find the corresponding IP before any connection can be made.

DNS stores different kinds of information in records. The ones you meet most in CTFs:

• A — maps a name to an IPv4 address.
• AAAA — maps a name to an IPv6 address.
• CNAME — an alias pointing one name at another name.
• MX — mail exchange servers for a domain.
• NS — the authoritative name servers for a domain.
• TXT — arbitrary text; in CTFs, flags or hints are sometimes hidden here.
• PTR — reverse lookup, mapping an IP back to a name.

How it works

A typical resolution of web.ctf.local proceeds roughly like this:

1. Your machine checks its local cache and its hosts file for a direct mapping.
2. If not found, it asks a resolver (a recursive DNS server).
3. The resolver walks the hierarchy: it asks a root server, which points to the top-level domain server, which points to the authoritative name server for the domain.
4. The authoritative server returns the record (e.g. an A record with the IP).
5. The resolver caches the answer and returns it to your machine, which can now connect.

Two enumeration ideas are central in CTFs:

• Subdomain enumeration — a domain may have many names (admin.ctf.local, dev.ctf.local) that are not linked anywhere obvious. Discovering them via wordlist-based DNS queries reveals additional hosts and services in scope.
• Virtual hosts (vhosts) — one web server at one IP can serve different sites depending on the Host header the client sends. So the same IP can hide multiple websites, each keyed to a hostname. Brute-forcing the Host header against a known IP can uncover a hidden site that only appears when you request the right name.

Practical example

A CTF gives you a target IP 10.10.10.5 and tells you it serves a site at ctf.local. Because this is an isolated lab with no public DNS entry, your machine cannot resolve ctf.local on its own. You add a local mapping so your tools can use the name:

# Illustrative: map the authorized lab hostname to its IP locally
# (edit /etc/hosts)
10.10.10.5   ctf.local

# Now name resolution for the lab works locally
$ ping -c 1 ctf.local
64 bytes from ctf.local (10.10.10.5): icmp_seq=1 ttl=63 time=39.7 ms

Browsing to http://ctf.local shows a landing page, but a challenge hint mentions an "internal admin portal." You suspect a hidden virtual host, so you conceptually brute-force the Host header against the same IP with a wordlist. A guess of admin.ctf.local returns a different, larger page than the default — a strong sign a distinct vhost exists. You add admin.ctf.local to your hosts file too and continue enumerating that site.

Every request here targets the single authorized IP; DNS/vhost enumeration simply reveals the names that unlock different content on it.

Cybersecurity relevance

• Attack-surface expansion: DNS and vhost enumeration frequently turn one known host into several. The hidden admin, dev, or staging name is a classic place for the vulnerable service or the flag to live.
• Information disclosure: TXT records, misconfigured records, or (in rare, misconfigured cases) a zone transfer can leak internal structure. Defenders lock these down; testers check for them.
• Understanding real infrastructure: knowing resolution flow, caching, and record types is essential for reading web, mail, and network behavior — and for diagnosing why a name does or does not resolve.
• Defense: organizations minimize exposed records, disable unauthorized zone transfers, and monitor for enumeration. Recognizing the technique helps both attack and defense.

Common mistakes

• Forgetting the hosts-file step in a lab, then concluding a site is down when really the name just does not resolve locally.
• Confusing DNS subdomains with virtual hosts. Subdomain enumeration asks DNS "what names exist?"; vhost enumeration changes the Host header against a known IP. They can reveal different things.
• Ignoring less-common record types like TXT, where hints or flags sometimes hide.
• Assuming a name maps to exactly one site. One IP can serve many vhosts.
• Enumerating names/domains outside the authorized scope.

Key takeaways

• DNS translates names into IP addresses (and stores other records) through a hierarchical resolution process.
• Key record types include A, AAAA, CNAME, MX, NS, TXT, and PTR.
• Subdomain enumeration finds hidden names; virtual-host enumeration finds different sites served by one IP based on the Host header.
• In isolated labs you often must add the target name to your hosts file so name resolution works locally.

Check your understanding

• Trace the steps your machine takes to resolve web.ctf.local into an IP address.
• What is the difference between subdomain enumeration and virtual-host enumeration, and why can each reveal different content?
• Why might you need to edit /etc/hosts in a CTF lab, and what problem does skipping that step cause?