What Are Subdomains?

How DNS Resolves Subdomains

When a browser requests api.shopify.com, the resolver first queries the .com nameservers, then the authoritative nameservers for shopify.com. Those nameservers hold a special resource record — an A record (for IPv4) or CNAME (for an alias) — that maps api.shopify.com to a specific IP address. If no record exists, the DNS query returns NXDOMAIN and the browser shows an error. Crucially, subdomains can point to completely different servers than the main domain, or even to third-party services like CDNs and SaaS platforms.

Common Subdomain Types

• www — The traditional web-facing subdomain. Most sites now redirect www to the apex domain or vice versa, but the record still exists in DNS.
• mail / smtp — Handles incoming and outgoing email. MX records reference mail.example.com for mail delivery routing.
• api — Backend APIs that serve mobile apps, SPAs, or third-party integrations. Usually not user-facing directly.
• cdn / static — Content delivery networks or static asset servers that offload images, CSS, and JS from the origin server.
• staging / dev / test — Pre-production environments where changes are tested before going live. These are often meant to be private.
• admin / dashboard / panel — Administrative interfaces, CMS backends, or control panels for managing the site.

Wildcard Subdomains

A wildcard DNS record (*.example.com) matches any subdomain that doesn't have its own explicit record. This is useful for multi-tenant SaaS apps where every customer gets customer.app.com, or for vanity URL systems. However, wildcards can mask orphaned services — if a developer spins up debug-example.example.com, the wildcard catches it even if the team forgets it exists. Wildcards also make brute-force subdomain enumeration impractical, since every guessed name resolves successfully.

Why Subdomains Matter for Security

Forgotten subdomains are one of the most common — and most dangerous — security blind spots in any organization's infrastructure.

Orphaned and Abandoned Subdomains

Teams create subdomains for projects, experiments, and temporary services. When the project ends, the DNS record often survives. An orphaned subdomain might still point to a decommissioned server, an outdated CMS with known vulnerabilities, or an internal tool that was never meant to be public. Bug bounty hunters and attackers specifically hunt for these because they're soft targets.

Subdomain Takeover

When a subdomain points to a third-party service (via CNAME) and that service is deactivated or the account is closed, the DNS record remains. An attacker registers the abandoned resource on the third-party platform, gaining full control of the subdomain. This is called a subdomain takeover and can lead to cookie theft, phishing pages hosted on a legitimate domain, and complete reputation damage. Famous examples include takeover of Heroku, GitHub Pages, and Shopify-hosted subdomains.

Information Leakage

Subdomain names themselves reveal information: staging-crm.example.com tells an attacker what CRM you use, jenkins-prod.example.com exposes your CI/CD tool, and vpn.example.com pinpoints your remote access gateway. Even without accessing the service, knowing it exists narrows the attack surface.

How Attackers Discover Subdomains

Enumeration is the first step in most reconnaissance workflows. Here are the main techniques:

• Certificate Transparency (CT) logs — Every publicly issued SSL certificate is logged in CT databases. Parsing these logs reveals subdomains that have valid certificates, even if the DNS records are gone. This is passive, extremely effective, and leaves no trace on the target's infrastructure.
• DNS brute force — Automated tools (Subfinder, Amass, Gobuster) iterate through massive wordlists of common subdomain names, querying DNS for each one. With the right wordlist, this uncovers dozens of forgotten services in minutes.
• DNS zone transfer — If an authoritative nameserver is misconfigured to allow zone transfers (AXFR), an attacker can download the entire DNS record set for the domain in a single request. This reveals every subdomain instantly.
• Search engines and web archives — Google dorking with site:example.com -www, Wayback Machine snapshots, and Shodan all index subdomains over time, building a historical record even after records are removed.

How to Audit Your Own Subdomains

1. Run a subdomain discovery scan — Use a tool like our Subdomain Finder to enumerate all known subdomains for your domain via CT logs and DNS resolution.
2. Review every result — For each subdomain, check: Does it resolve? Does it serve a live page? Is the service still needed? Who owns the underlying infrastructure?
3. Delete stale records — Remove DNS records for decommissioned services immediately. There's no reason to keep a dead subdomain active.
4. Avoid CNAMEs to third parties without monitoring — If a subdomain uses a CNAME to an external service, set a calendar reminder to verify the service is still active and the account is in good standing.
5. Restrict nameserver access — Disable zone transfers on your authoritative DNS servers and use role-based access for anyone who can create or modify DNS records.