A subdomain points to a service that no longer exists
sec_dangling_cnameShort answer
One of your subdomains still has a CNAME record pointing to an external service (for example a storage bucket or hosted blog) that no longer has anything behind it. Delete that DNS record, or re-create the resource on the service under your own account. Until then, anyone who claims the same name on that service controls the subdomain.
Why it matters
Many hosting services serve whichever customer has claimed a given name. When the resource is deleted but your CNAME stays, an attacker can register the same name and serve their own pages on your subdomain: phishing and malware on an address your users trust, pages that can set cookies for your parent domain, and requests that pass security rules trusting *.example.com. Lists of vulnerable services are public, and takeovers are found by automated scanning.
Spam or phishing pages on your subdomain can be indexed under your domain and can get it flagged by Google Safe Browsing, which shows a warning to visitors.
How Glimana detects it
Glimana checks the site's host, www. plus your domain, and other subdomains of your domain that your pages link to (up to 12 names). For each name with a CNAME record: if the CNAME target does not exist (NXDOMAIN), the name is reported as medium; if the target belongs to a service listed as claimable in can-i-take-over-xyz (CC BY 4.0), such as AWS S3, Bitbucket, Ghost, Surge.sh or WordPress.com, and the subdomain shows that service's "nothing here" message (e.g. The specified bucket does not exist), it is high. At most five such pages are fetched per scan. If none of the DNS queries could be answered, the result is Could not be measured rather than Passed. Subdomains your site does not link to, and A records pointing to released cloud IPs, are not checked.
How to fix it
Watch out
If the subdomain already serves content you do not recognise, it has been taken over: delete the DNS record at once, then review what it could reach (cookies, OAuth redirect URLs, CSP or CORS allow-lists). When you retire a service in future, delete the DNS record before deleting the resource, not after.
- Find the finding in Glimana. Open Security; this check is in the E-mail and DNS group, with the evidence from the last scan under its title. The same problem is listed under Issues › A subdomain points to a service that no longer exists.
-
Apply the fix on your platform.
Go to DNS › Records, search for the subdomain named in the issue's evidence, and delete its CNAME record (or edit it to point to a service you still use). If you still need the subdomain on that service, re-create the resource first and add any ownership-verification record the service asks for.
Open the zone of your domain, find the CNAME for the listed subdomain and delete it. To keep the service instead, re-create the resource with exactly the name the CNAME expects (for an S3 website bucket, the bucket must be named after the full subdomain) in your own account. Check with
dig +short CNAME sub.example.com. - Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.
How the fix is verified
After changing DNS, wait until the old record's TTL has passed, then press Re-scan on the Security page (or wait for the weekly Sunday 04:00 scan); the problem closes when the check passes.