Introduction
Subdomain takeover is a security vulnerability that occurs when a DNS CNAME record points to a service that no longer exists, allowing an attacker to register that service and effectively take control of your subdomain. A 2023 study found that over 40% of the Alexa top 10,000 domains had at least one vulnerable subdomain takeover. The consequences range from embarrassing (attackers hosting inappropriate content on your subdomain) to severe (phishing pages that damage your brand reputation and potentially defraud your users). This checklist covers everything you need to do to prevent, detect, and remediate subdomain takeover risks on your is-pro.dev subdomains.
Understanding the Vulnerability
A subdomain takeover works like this: you create a CNAME record pointing blog.is-pro.dev to myblog.netlify.app. Later, you delete your Netlify site (or your free Netlify plan expires). The CNAME record still exists in your DNS, but it now points to a service that is available for registration. An attacker discovers this dangling record, creates a Netlify site with the same name, and instantly controls what appears at blog.is-pro.dev. They can host phishing pages, malware, or any content they choose — and visitors will see your subdomain in the browser's address bar, lending credibility to the attacker's content. The same vulnerability applies to GitHub Pages, Vercel, AWS, Azure, Google Cloud, and any other platform where DNS records can outlive the services they point to.
Checklist Item 1: Audit Your DNS Records Regularly
The most effective prevention is knowing exactly what DNS records you have and verifying they all point to active services. Create a monthly calendar reminder to audit your is-pro.dev DNS dashboard. For each CNAME record, visit the target URL and confirm the service is still live and owned by you. For each A record, verify the IP address still hosts your service. Remove any records pointing to decommissioned services. Pay special attention to staging, testing, and temporary project subdomains — these are the most likely to be forgotten and left dangling. Use the DNS Checker tool on is-pro.dev to verify each record resolves to the expected target.
Checklist Item 2: Remove DNS Records Before Decommissioning Services
Make it a standard operating procedure: before you delete a service on any platform (Netlify, Vercel, GitHub Pages, AWS, etc.), delete the corresponding DNS CNAME or A record in the is-pro.dev dashboard first. The time between deleting the service and deleting the DNS record is your window of vulnerability. By deleting the DNS record first, you eliminate the window entirely. If you manage multiple subdomains, maintain a spreadsheet or document mapping each subdomain to its target service so you never accidentally leave a dangling record. Include this step in your project shutdown checklist.
Checklist Item 3: Use CNAME Flattening for Root Domains
CNAME records at the zone apex (the bare domain like is-pro.dev without a subdomain) are not standard DNS — the CNAME record type conflicts with other mandatory records at the apex. Cloudflare solves this with CNAME Flattening (also called ANAME or ALIAS records). When using CNAME Flattening, Cloudflare resolves the CNAME target at the DNS edge and returns A/AAAA records to clients, maintaining DNS standards compliance. This feature also provides some takeover protection because Cloudflare validates that the target resolves before serving it. If the target stops resolving, Cloudflare can detect the issue and alert you.
Checklist Item 4: Monitor Certificate Transparency Logs
Certificate Transparency (CT) logs record every SSL certificate issued by a trusted certificate authority. If an attacker takes over your subdomain and provisions a free SSL certificate for it, that certificate issuance will appear in CT logs within 24 hours. Monitoring CT logs for certificates issued for your subdomains is an early warning system for takeover attempts. Services like Facebook's CT Monitor, Google's Certificate Transparency, or commercial alternatives can alert you when a certificate is issued for any of your subdomains. If you see a certificate for a subdomain you did not configure, investigate immediately — it may indicate a takeover in progress.
Checklist Item 5: Set Up Automated CNAME Validation
The is-pro.dev platform includes a CNAME Validator tool that checks whether your CNAME records resolve to active, expected targets. Run this tool weekly to identify potential dangling records before attackers find them. For automated monitoring, use a script that queries each of your DNS records at a regular interval and compares the resolution result against a known-good configuration file. If the result changes unexpectedly, send an alert. This level of automation is especially important if you manage many subdomains or frequently change hosting providers. A simple cron job running dig commands and comparing output against a baseline configuration can catch most takeover situations before they cause harm.
Checklist Item 6: Implement a Subdomain Registration Policy
If your organization or team uses multiple is-pro.dev subdomains, establish a clear policy: every subdomain must have an owner, a documented purpose, and a review date. Subdomains without a documented owner or purpose are candidates for deletion. Set a maximum TTL for any subdomain (e.g., 1 year) — after which it must be explicitly renewed or retired. For team projects, use a shared tracking document where each subdomain's purpose, DNS records, and target services are documented. When a team member leaves, review their subdomains and reassign or delete them. Subdomain sprawl is the enemy of security — every unused subdomain is a potential liability.
Checklist Item 7: Test Your Subdomains for Takeover Vulnerability
Use security tools to proactively test your subdomains for takeover vulnerability. Open-source tools like subjack, subover, and nuclei can scan your DNS records and identify CNAME targets pointing to services that are available for registration. Run these tools quarterly to catch takeover risks you might have missed. Remember that these tools produce false positives — verify each finding manually before taking action. The is-pro.dev CNAME Validator tool provides similar functionality for the most common hosting platforms and should be your first line of defense.
Conclusion
Subdomain takeover is a serious but entirely preventable vulnerability. The combination of regular DNS audits, proper decommissioning procedures, CT log monitoring, automated CNAME validation, and proactive security testing eliminates nearly all takeover risk. By following this checklist for your is-pro.dev subdomains, you ensure that every DNS record points to a service you control — and stays that way.
Key Takeaways
- Subdomain takeover happens when CNAME records outlive their target services
- Always delete DNS records before decommissioning the services they point to
- Regular DNS audits catch dangling records before attackers find them
- Certificate Transparency logs provide early warnings of unauthorized certificate issuance
- Automated CNAME validation and security scanning tools catch takeover risks proactively
- Every subdomain should have a documented owner and purpose to prevent sprawl
Frequently Asked Questions
Is is-pro.dev really free to use?
Yes, is-pro.dev provides free subdomains for developers with no hidden fees.
What can I host on an is-pro.dev subdomain?
Any legitimate project — portfolios, SaaS apps, game servers, APIs, and more.