What each record tells DNS
An A record connects a hostname to an IPv4 address. An AAAA record connects a hostname to an IPv6 address. A CNAME record takes a different approach: it says that one hostname is an alias of another hostname. For example, www.example.com could be a CNAME for site.example.net. A resolver looking up www.example.com can then follow the alias to find the address records for site.example.net.
A CNAME does not contain an IP address, send a visitor to a new URL, or change what appears in the browser’s address bar. It only affects DNS resolution. The web server must still be configured to serve the hostname visitors use, and an HTTPS site needs a certificate that covers that hostname. Think of the CNAME as a way to locate the destination, not as a complete website setup.
Use a CNAME when the destination is managed by name
A CNAME is often useful when a service provider gives you a hostname to use, rather than a stable IP address. Suppose a hosting service asks you to point www.example.com to customer.host.example.net. If the service changes the IP addresses behind its hostname, your alias can continue to follow that name without you editing an A or AAAA record each time. The provider still needs to maintain its destination records correctly.
Aliases can also simplify names you manage yourself. If app.example.com and portal.example.com should both reach the same named destination, you may be able to point them at one canonical hostname and maintain its address records in one place. This is most helpful when the names genuinely share a destination. If they need different infrastructure or independent change schedules, separate records may be clearer.
Use the exact hostname supplied for a service. A CNAME target is a DNS name, not a URL: enter a name such as customer.host.example.net, not https://customer.host.example.net/login. DNS control panels differ in how they handle a final dot or automatically append your domain, so check the resulting full name after saving.
Choose A or AAAA when you need direct address records
If a host should point directly to an IP address you control, use an A record for IPv4, an AAAA record for IPv6, or both when the service supports both. For instance, a test host could use the documentation-only addresses 192.0.2.10 and 2001:db8::10 in an example configuration. In a real setup, use the addresses assigned to your service. Direct records are also appropriate when a provider explicitly asks for particular IP addresses rather than a hostname.
The domain’s root name, often written as example.com without a prefix, needs special attention. In ordinary DNS, it cannot be a CNAME because that name already has required zone records, including SOA and NS records. Some DNS providers offer features called ALIAS, ANAME, or CNAME flattening that let you enter a hostname and publish address answers at the root. Those are provider-specific features, not ordinary CNAME records; check how your provider implements them.
Check for conflicts before adding an alias
A CNAME normally cannot share its exact hostname with other record types. If www.example.com has an A record, remove or replace it before creating a CNAME at www.example.com. The same issue applies if you need a TXT record at that exact name. Records at different names do not conflict merely because they are in the same domain: a TXT record at example.com is separate from a CNAME at www.example.com.
Be particularly careful with email DNS. An MX record should direct mail to a hostname that has address records rather than relying on a CNAME as the mail server name. Email services may also ask for TXT or CNAME records at specific subdomains. Follow the requested record type and hostname exactly, and check for an existing record at that hostname before making changes.
Verify the result, not just the saved setting
After a change, look up the alias and its destination. Confirm that the CNAME points to the intended full hostname and that the destination returns the address records your service needs. Then test the actual website or application using the original hostname. A correct DNS answer alone cannot confirm that the service accepts requests for that name.
Avoid pointing aliases in circles or building long chains of aliases. Each additional step makes the setup harder to inspect and can introduce more opportunities for a lookup to fail. Cached DNS answers can also make an old setting appear to persist for a while after an edit. If results differ, check the records at each hostname in the chain before changing unrelated settings.
