Discover subdomains, enumerate DNS records, and analyze subdomain security
Subdomains are prefixes added to your main domain name that allow you to organize different sections of your website or separate services. They're an essential part of domain structure and DNS configuration.
A subdomain is a subdivision of your main domain. Structure breakdown:
Examples: blog.example.com, shop.example.com, mail.example.com, admin.example.com
www: Most common subdomain, traditionally used for main website.
blog: Separate blog or news section (blog.example.com).
shop/store: E-commerce section (shop.example.com).
mail/webmail: Email access interface (mail.example.com).
ftp: File transfer server (ftp.example.com).
admin/cpanel: Administrative interfaces (admin.example.com).
api: API endpoints for developers (api.example.com).
m/mobile: Mobile-optimized version (m.example.com).
dev/staging/test: Development and testing environments.
Security Auditing: Discover all publicly accessible entry points to your infrastructure.
Asset Discovery: Find forgotten or unknown subdomains that may pose security risks.
Attack Surface Analysis: Understand your complete exposure to potential attacks.
Compliance: Maintain inventory of all web assets for regulatory requirements.
Troubleshooting: Identify DNS configuration issues or conflicts.
Competitor Analysis: Research competitor infrastructure (for legitimate business intelligence).
1. Dictionary/Brute Force: Check common subdomain names against domain (what our tool does).
2. Certificate Transparency Logs: Search SSL certificate logs for subdomains.
3. Search Engines: Use Google/Bing operators to find indexed subdomains.
4. DNS Zone Transfer: Request zone transfer from DNS servers (rarely works).
5. Reverse DNS: Query IP ranges for associated domains.
6. Web Archives: Search historical records like Wayback Machine.
Forgotten Subdomains: Old dev/test subdomains left running can expose vulnerabilities.
Subdomain Takeover: If subdomain points to expired service (AWS S3, Heroku), attackers can claim it.
Administrative Access: Admin/cpanel subdomains should never be public.
Information Disclosure: Dev/staging subdomains may reveal sensitive information or have weaker security.
Attack Surface: Each subdomain is potential entry point for attacks.
admin, cpanel, whm: Administrative interfaces - should require VPN or IP whitelisting.
dev, test, staging, demo: Development environments - often have weaker security, may expose sensitive code or data.
backup, old: Legacy systems - may be unpatched and vulnerable.
vpn, remote: Access gateways - should have strong authentication.
db, mysql, sql: Database interfaces - should never be public.
Subdomain takeover occurs when:
Prevention: Always remove DNS records when decommissioning external services.
Our subdomain finder checks 100 common subdomain names against your domain:
To create a subdomain, add DNS records at your domain registrar or DNS provider:
A Record: Points subdomain to IPv4 address
blog.example.com A 192.0.2.1
CNAME Record: Creates alias to another domain
www.example.com CNAME example.com
Changes typically propagate within minutes but can take up to 48 hours globally.
Find active subdomains by checking 100 common names
Get IP addresses and CNAME records for each subdomain
Identify potentially risky or exposed subdomains
A subdomain is a prefix added before your main domain name. For example, in blog.example.com, "blog" is the subdomain and "example.com" is the main domain. Subdomains allow you to organize different sections of your website or separate services. Common examples: www.example.com (main site), mail.example.com (email), shop.example.com (store), blog.example.com (blog). Each subdomain can point to different servers or IPs, have different content, and function independently while remaining part of your main domain. They're useful for organization, separate applications, testing environments, and accessing different services.
Subdomain enumeration discovers which subdomains exist for a domain. Our tool uses dictionary-based enumeration - checking a list of 100 common subdomain names (www, mail, ftp, admin, blog, etc.) against your domain. For each name, we query DNS servers to see if records exist. If DNS responds with IP address or CNAME, the subdomain exists. Process: (1) Take common subdomain prefix, (2) Add to domain (e.g., www + example.com = www.example.com), (3) Query DNS for A/AAAA/CNAME records, (4) If records found, subdomain is active. This method is fast but only finds subdomains using common names, not randomly-named ones.
Security reasons: (1) Asset discovery: Know all your public entry points, (2) Forgotten subdomains: Old dev/test subdomains may be unpatched and vulnerable, (3) Subdomain takeover: Prevent attackers claiming your unused subdomains pointing to deleted services, (4) Attack surface: Each subdomain increases exposure to potential attacks. Management reasons: (5) Inventory: Maintain list of all web assets, (6) Compliance: Some regulations require asset inventory, (7) Cleanup: Remove unnecessary subdomains. Troubleshooting: (8) Identify DNS configuration issues. Regular subdomain enumeration is essential security practice.
Subdomain takeover is a serious vulnerability where attacker gains control of your subdomain. How it happens: (1) You create subdomain pointing to external service (e.g., blog.example.com → AWS S3 bucket "example-blog"), (2) You stop using that service and delete S3 bucket, (3) You forget to remove DNS record - blog.example.com still points to deleted bucket, (4) Attacker creates new S3 bucket with same name "example-blog", (5) Now blog.example.com serves attacker's content on your domain! Impact: Phishing, malware distribution, reputation damage, cookie theft. Prevention: Remove DNS records before deleting external services. Platforms vulnerable: AWS S3, GitHub Pages, Heroku, Azure, and many others.
Administrative subdomains (highest risk): admin.example.com, cpanel.example.com, whm.example.com - should NEVER be public, require VPN access. Development subdomains: dev.example.com, test.example.com, staging.example.com, demo.example.com - often have weak security, may expose sensitive info, credentials. Database subdomains: db.example.com, mysql.example.com, sql.example.com - should never be publicly accessible. Legacy subdomains: old.example.com, backup.example.com - may be unpatched, forgotten. Best practice: These should be: (1) Removed from public DNS entirely, (2) Behind VPN/IP whitelist, (3) Properly secured with authentication, (4) Regularly audited and maintained.
No, subdomain enumeration itself cannot harm your website. It's simply DNS queries - asking "does www.example.com exist?" repeatedly. Why it's safe: (1) Just DNS lookups, not connections to servers, (2) No exploitation attempts, (3) Publicly available information, (4) Same queries anyone can make manually. However: Aggressive enumeration might: (1) Temporarily increase DNS query load, (2) Trigger rate limiting on DNS servers, (3) Appear in DNS logs. Our tool: Performs respectful enumeration at reasonable pace. Note: What IS discovered (exposed admin panels, dev servers) might reveal security issues, but the enumeration process itself is harmless. This is why regular self-enumeration is important security practice.
Create subdomains through DNS records at your domain registrar or DNS provider: Method 1 - A Record (point to IP): Log into DNS control panel → Add new A record → Subdomain: "blog" → IP: 192.0.2.1 → Result: blog.example.com points to that IP. Method 2 - CNAME (alias to another domain): Add CNAME record → Subdomain: "www" → Target: example.com → Result: www.example.com points to same place as example.com. Steps vary by provider: Cloudflare, GoDaddy, Namecheap, etc. have different interfaces but same concept. Propagation: Changes take 5 minutes to 48 hours to propagate globally. Configure web server: Also configure server to respond to subdomain.
Technically, there's no hard limit on number of subdomains you can create. Practical considerations: (1) DNS provider limits: Some providers limit total DNS records (e.g., 500-10,000 records), (2) Performance: Too many can complicate DNS management, (3) SSL certificates: Wildcard certs cover unlimited subdomains, individual certs become impractical with many subdomains, (4) Security: More subdomains = larger attack surface requiring monitoring. Common practice: Most websites use 5-20 subdomains. Large enterprises may have hundreds. Recommendation: Only create subdomains you actually need and actively maintain. Remove unused ones regularly.
Subdomain: blog.example.com - Separate DNS entry, can point to different server/IP, functions independently, requires separate SSL certificate (unless using wildcard). Subdirectory: example.com/blog - Part of main domain, same server and IP, part of main site's structure, uses same SSL certificate. SEO perspective: Google treats subdomains as separate sites (blog.example.com separate from example.com), subdirectories stay part of main site authority. Use subdomain when: Completely different service, different server, separate application, want total isolation. Use subdirectory when: Content is part of main site, want to keep SEO authority together, simpler setup.