A CNAME follows a hostname to another hostname. A chain that returns to an earlier name, or ends at a nonexistent target, cannot provide a usable destination. Diagnose the entire chain before replacing the final website address.
IN THIS ARTICLE
What you need before you begin
Record the original name, each intended alias target and the authoritative provider for every zone involved. Distinguish a DNS CNAME loop from an HTTP redirect loop: they occur at different stages and require different fixes.
01 Find a CNAME loop or an alias chain that points to an absent target
- Query the original hostname for CNAME, then query each returned target. Keep a list of visited names so a repeated name is immediately visible.
- For each owner, inspect the authoritative configuration. Check for a target accidentally equal to itself or a pair such as www pointing to app while app points back to www.
- Check whether the DNS editor appended the zone suffix to a target that was intended to be fully qualified. Confirm the exact published name rather than only the input field.
- Replace the incorrect target with the service provider's supported canonical hostname. If the terminal name is absent, confirm the service still exists before recreating or claiming any resource.
- Remove only conflicting records after recording them. A normal CNAME cannot coexist with ordinary A, AAAA or MX data at the same owner name.
02 Example: follow a broken CNAME chain one step at a time
From a workstation, inspect the alias and then query the exact target returned. This sample illustrates a customer hostname pointing to a service alias. Replace both names with the values observed in your own zone instead of assuming the target.
dig www.example.com CNAME +noall +answer
dig edge.provider.example CNAME +noall +answer
dig edge.provider.example A +noall +answer
dig edge.provider.example AAAA +noall +answer
Read the result: A target that points back to www.example.com creates a loop. A target with neither a usable address nor a working further alias can leave the original name unresolved. An empty CNAME answer alone is not an error when the target is correctly represented by A or AAAA records.
Confirm the hosted platform still recognises the custom hostname before changing the alias. DNS correctness does not configure its tenant mapping or certificate. Keep the provider's current target from its verified control panel and retire unused aliases deliberately.
Confirm the expected result
Resolve the full chain through an ordinary resolver and confirm it terminates in usable address data for the application. Open the HTTPS site and check the certificate and intended account.
Troubleshoot unexpected results
If the chain is correct but the browser still reports too many redirects, inspect the application or CDN redirect configuration. DNS has already completed at that point, so more CNAME edits can create a second problem.
A common question
Can a CNAME include https:// or a page path?
No. Its target is a DNS name, not a full URL. Use the provider's hostname value only. Web redirects, including path changes, belong in the website, application or supported CDN redirect service.