If you only remember one DNS record type, it is the A. It maps a hostname to an IPv4 address. That is the whole spec; the rest is operational convention. But the moment you start hosting on a CDN or fronting your origin with a managed service, you collide with CNAMEs, AAAAs and the vendor-specific ANAME / ALIAS pseudo-records. They look similar. They are not.

A — IPv4 address

example.com.    300    IN    A    93.184.216.34

One name, one IPv4. You can have multiple A records on the same name (round-robin DNS, anycast, simple HA), and recursive resolvers will return them in implementation-defined order. Most clients will try the first; some will shuffle. Do not rely on order for load balancing.

AAAA — IPv6 address

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Identical semantics, IPv6 destination. The naming "AAAA" (quad-A) is a four-byte joke about IPv6 addresses being four times the length of IPv4. A modern client given both an A and an AAAA will perform Happy Eyeballs (RFC 8305): try IPv6 first, fall back to IPv4 if the connection does not complete within ~250ms. Misconfigured AAAAs that point to an unreachable IPv6 host show up as slow page loads, not outright failures, because of this fallback.

CNAME — name alias

www.example.com.    300    IN    CNAME    example.com.

"When you ask for www.example.com, follow the chain and resolve example.com instead." The resolver does the chaining for you; the client never sees the indirection. Two hard rules:

CNAME cannot coexist with any other record on the same name. If you have www.example.com CNAME example.com, you cannot also have www.example.com TXT "hello". The zone validator will reject it (RFC 1034 §3.6.2). This is the single most common DNS gotcha.
You cannot CNAME the apex. The zone apex (example.com.) must hold the SOA and NS records. Per the same rule, it therefore cannot also hold a CNAME. So you cannot do example.com CNAME cdn.cloudflare.net in standards-compliant DNS.

ANAME and ALIAS — vendor inventions that fake apex CNAME

Because the apex-CNAME prohibition is operationally painful (most people want their root domain to point at a CDN), various DNS providers invented synthetic record types:

ALIAS at DNSimple, Route 53 (where it is "alias"), Dreamhost.
ANAME at DNS Made Easy, easyDNS, NS1.
CNAME flattening at Cloudflare.

None of these are returned to the client. The DNS provider's authoritative server resolves the target hostname on the client's behalf and returns the resulting A/AAAA records as if they were directly attached to your apex. From the resolver's perspective, it is a plain A response.

The trade-off: the resolution happens at the authoritative layer, not at the recursive layer. Some providers re-resolve every few minutes; others piggyback off cache. CDN-region-correctness via EDNS Client Subnet can be lost, depending on implementation. If your A response for the apex looks weirdly stale, this is usually why.

Putting it together

A typical modern setup:

example.com.        IN  ANAME   d1abc123.cloudfront.net.  ; synthesised at the apex
www.example.com.    IN  CNAME   d1abc123.cloudfront.net.  ; safe to CNAME a sub
api.example.com.    IN  A       198.51.100.42             ; direct origin IP
api.example.com.    IN  AAAA    2001:db8::42              ; dual-stack

When something looks wrong, the multi-resolver lens helps disambiguate "the record is broken at the authority" vs. "one resolver has a stale cache" vs. "the ANAME resolution at the authority is returning the wrong IP for that resolver's view". Run any of these through dnscheck to see the per-resolver answer — for example letsencrypt.org.

Reference: RFC 1034 §3.6.2 for CNAME exclusivity, RFC 8305 for Happy Eyeballs, and Cloudflare's CNAME flattening explainer.