A CNAME record is a DNS entry creating an alias from one name to another canonical name. For example, if shop.example.it is configured as a CNAME pointing to services.provider.example, the resolver follows the indicated name to retrieve destination data. The value is a hostname, not an IP address, distinguishing it from A records mapping to IPv4 addresses and AAAA records used for IPv6. CNAMEs are useful when external services provide endpoints that may change address, allowing users to continue using their domain name while technical management remains delegated to the provider.
Aliases and Resolution
When a resolver encounters a CNAME, it continues lookup to the target name. If that name has an A or AAAA record, the resolver returns the corresponding address per DNS rules. Responses commonly include both alias and final IP address. Caches store information based on record TTLs; changes may take time to reflect across all resolvers. A CNAME is not a redirect: it does not alter the URL bar or send HTTP responses but participates in name resolution before service connection begins.
A common use case is linking a subdomain to a hosting platform, a SaaS service, or a CDN. The owner maintains a readable and stable name, while the provider can update their endpoint. Before applying it, one should consult the service instructions: some require a specific target, domain verification, or additional records for certificates and email. If the target is misspelled, non-existent, or not authorized for that service, resolution may fail to yield a usable endpoint, or the platform might reject the request.
Constraints and Conflicts
In standard DNS, a CNAME name should not have other records simultaneously, as the alias means data comes from another hostname. Some providers offer proprietary flattening features, but these aren't transferable or universally supported. The zone's primary name must publish SOA and NS records. Before modifying, verify existing data: replacing A or TXT records could break site, email, or ownership verification.
A CNAME cannot point to an IP address. If the provider only offers IPv4 or IPv6, the appropriate A or AAAA record is required; if both are offered, instructions should be followed carefully. It is not advisable to chain many aliases, as each step increases complexity and may introduce dependencies. A target that points back to the original name creates a DNS loop. One must also check for differences between names with and without a trailing dot in the panel: some systems auto-complete the zone domain, while others expect a full FQDN.
Configuration and Troubleshooting
Changes are made at the authoritative nameserver provider, not necessarily at the registrar where the domain was purchased. After saving, one can query the authority directly to verify name, type, target, and TTL; then check a few recursive resolvers, accounting for caching. Application-level testing must confirm that the service recognizes the requested hostname and has the correct HTTPS certificate. A correctly resolved CNAME does not alone guarantee site functionality: the remote server must be configured for that name, and the provider may require separate steps.
In case of error, first verify delegation and active nameservers, then check the target and records on the alias name. An old cached record might make a change appear ineffective; querying the authority distinguishes the published value from the stored one. Initial data should be noted and retained for possible restoration. In summary, a CNAME links one hostname to another and simplifies integration with external services, but must be used respecting coexistence constraints and accompanied by DNS and application checks.
← Full glossary