Over time every company's DNS zone collects subdomains: last year's promo page, a test server, a temporary survey, an external help centre. When those services are shut down, the records pointing to them often stay behind. Those forgotten records are what make subdomain takeover possible.
How the risk appears
Say promo.example.uz has a CNAME to example-promo.builder.example.net on an external landing page builder. The campaign ends, the project is deleted, but the record remains. Many cloud services hand a project name or custom domain to whoever claims it first. If an attacker creates a project with that name or connects promo.example.uz to their own account, they control what your subdomain shows. The same happens with an A record pointing to a released cloud IP that is later reassigned, or a subdomain delegated by NS to a zone that was deleted.
Why it is serious
A subdomain under a trusted domain is ideal for phishing, and the attacker can usually get a valid SSL certificate because the certificate authority checks DNS control, which they now have. If your main site sets cookie values for the whole .example.uz domain, the hijacked subdomain may read or change them. Spam or malware served from it also damages the reputation of your whole domain.
Example: a university admissions campaign
A private university opened qabul.example.uz every admissions season on an external builder via CNAME. After one season, marketing cancelled the subscription, but nobody removed the record. Months later an applicant reported a form asking for card details to "pay the application fee". Someone had opened an account on the same builder and attached the university's subdomain. Deleting the record fixed it in minutes; warning students and parents took far longer, and the incident could have been avoided with a single line removed from the zone at the end of the season.
Finding vulnerable records
Export the full zone from your DNS panel, then check every CNAME target:
#!/bin/sh
for sub in www shop qabul promo blog test help; do
host="$sub.example.uz"
target=$(dig +short CNAME "$host")
[ -z "$target" ] && continue
status=$(dig "$target" A | grep -o 'status: [A-Z]*')
echo "$host -> $target ($status)"
donestatus: NXDOMAIN means the target no longer exists. Even when it resolves, open the page; messages like "project not found" or "domain not configured" are also red flags:
curl -s https://promo.example.uz/ | grep -iE "not found|no such|not configured"For A records, confirm in your hosting or cloud panel that each IP still belongs to one of your servers. This is harder to automate, so keep a short list of addresses and check it by hand whenever a server is retired. Do not forget subdomains delegated with NS records to other DNS services: if the zone at the other end was deleted, anyone who can create that zone on the same service may take control of the whole delegated branch.
Prevention rules
The key rule is order: remove the DNS record first, then the external resource. The reverse order leaves a window attackers exploit. Make sure marketing and design teams know this, since they often connect external tools.
- Record an owner and a purpose for every subdomain.
- Use TXT-based domain ownership verification whenever a service offers it.
- Review the zone quarterly and delete unused records.
- Scope cookies to a specific host rather than the whole domain.
- Remove
AandAAAArecords before deleting cloud servers.
In the sayt.uz cabinet all DNS records of a domain are on one page, so a quarterly review takes little time. When every record in the zone has a clear owner and purpose, the risk of a takeover practically disappears.