Domain CNAME and A Records Explained: Practical DNS for Investors

DNS records are the wiring behind every domain name. When someone types your domain into a browser, DNS records determine where that request goes — which server responds, which email system handles messages, and which services are authorized to act on your domain’s behalf. A records and CNAME records are the two most fundamental record types, and understanding how they work is essential for any domain investor who develops properties, configures landing pages, or troubleshoots DNS issues during transfers.

A Records: Direct Address Mapping

An A record (Address record) creates a direct mapping between a domain name and an IPv4 address. When you set an A record for example.com pointing to 192.0.2.1, any browser requesting example.com gets directed to the server at that IP address. The mapping is straightforward: one name to one IP.

You can set multiple A records for the same domain pointing to different IP addresses. DNS resolvers will rotate between them (round-robin), providing basic load distribution. This is common for high-traffic sites but less relevant for most domain investor use cases.

The key characteristic of A records is directness. There is no intermediary lookup — the DNS resolver gets the IP address in a single step. This makes A records slightly faster than CNAME records in resolution time, though the difference (typically a few milliseconds) is negligible for most applications.

For IPv6 addresses, the equivalent is an AAAA record (pronounced “quad-A”). As IPv6 adoption continues, setting both A and AAAA records ensures your domain works for visitors on both IPv4 and IPv6 networks.

CNAME Records: Aliasing One Name to Another

A CNAME record (Canonical Name record) maps one domain name to another domain name rather than to an IP address. When you set a CNAME for blog.example.com pointing to example.netlify.app, DNS resolvers first look up the CNAME to find the target hostname, then look up the A record for that target to find the actual IP address.

This indirection is the CNAME’s core advantage: if the IP address of the target changes, you do not need to update your DNS records. The hosting provider updates their A record, and your CNAME follows automatically. This is why cloud platforms like Netlify, Vercel, GitHub Pages, and Cloudflare Pages instruct users to create CNAME records rather than A records — it lets them change server infrastructure without requiring every customer to update their DNS.

The Root Domain Restriction

The most important technical limitation of CNAME records is that you cannot set a CNAME on your root domain (also called the zone apex) if you have other DNS records there. According to the DNS specification (RFC 1034), a CNAME record cannot coexist with other record types for the same name. Since root domains almost always need MX records (for email), TXT records (for SPF, DKIM, and domain verification), and often NS records, setting a CNAME at the root creates a conflict.

This is why hosting platforms tell you to use an A record for example.com (the root) and a CNAME for www.example.com (a subdomain). The root domain uses a direct IP address, while the www subdomain can alias to the hosting platform’s hostname.

Some DNS providers work around this limitation with proprietary record types. Cloudflare offers CNAME flattening, which resolves a CNAME at the root level and returns the resulting A record to the querying resolver. Route 53 from Amazon has ALIAS records that work similarly. These are not standard DNS record types but practical solutions offered by specific providers.

Practical DNS Configurations for Domain Investors

Different domain investing activities call for different DNS setups.

Parked domains with a marketplace. If you list a domain on Dan.com, Afternic, or Sedo, the platform will provide specific DNS instructions. Dan.com typically asks you to point nameservers to their system (ns1.dan.com, ns2.dan.com) or set an A record to their server IP. Follow the platform’s exact instructions, as incorrect configuration can prevent the landing page from displaying.

Landing pages on your own hosting. If you build custom landing pages, set an A record for the root domain pointing to your server IP and a CNAME for the www subdomain pointing to your root domain. If using a platform like Netlify or Vercel, follow their domain configuration guide — typically a CNAME for the www subdomain and either an A record or ALIAS for the root.

Email-only domains. Some investors maintain domains specifically for email use (customer inquiries, business correspondence). These domains need MX records pointing to your email provider (Google Workspace, Zoho, Fastmail) plus the appropriate SPF, DKIM, and DMARC TXT records. You may not need A or CNAME records at all unless you want the domain to load a web page.

Domain forwarding. To redirect one domain to another, some registrars offer built-in forwarding that handles the DNS configuration automatically. Namecheap, Dynadot, and Porkbun all offer URL forwarding. Behind the scenes, the registrar sets up an A record pointing to their redirect server, which issues HTTP 301 or 302 redirects to your target URL.

TTL Settings and Propagation

Every DNS record includes a TTL (Time to Live) value in seconds that tells DNS resolvers how long to cache the record before checking for updates. Lower TTL values mean changes propagate faster but generate more DNS queries. Higher TTL values reduce query volume but delay propagation.

For domains in active use with stable configurations, set TTL to 3600 (one hour) or 14400 (four hours). Before making DNS changes like switching hosting providers or transferring to a new registrar, reduce the TTL to 300 (five minutes) at least 24 hours before the change. This ensures cached records expire quickly and the new configuration takes effect promptly.

During domain transfers, keep your existing DNS records active until the transfer completes and you have confirmed the new registrar’s DNS is properly configured. A gap in DNS service means your domain resolves to nothing — costing you traffic and potentially making your email temporarily unreachable.

Troubleshooting Common Issues

When a domain does not resolve correctly, DNS records are the first place to check. Use dig (on Mac and Linux) or nslookup (on Windows) to query your domain’s DNS records directly. Online tools like dig.toolbox.googleapps.com and dnschecker.org let you verify DNS resolution from multiple locations worldwide.

Common issues include pointing a CNAME at an IP address instead of a hostname (CNAME records must point to domain names, never IP addresses), setting a CNAME at the root domain alongside MX records (causing email delivery failures), and forgetting to remove old DNS records after migrating to a new host (creating conflicting records that cause intermittent resolution failures).

For a broader overview of DNS concepts, see DNS explained for domain investors. To understand how DNS records relate to domain security, check out domain security best practices.