A Record

An A record is the DNS record type that maps a hostname to a single 32-bit IPv4 address, such as 192.0.2.53. RFC 1035 lists it as type number 1, meaning 'a host address' (section 3.2.2). RFC 1035 defines the record's data as 'A 32 bit Internet address' (section 3.4.1), and nothing else. An A record carries no port, no path, no protocol and no health information. It is data, not a pointer. A CNAME redirects one name to another, while an A record ends the lookup with an address. It holds IPv4 only. IPv6 uses the separate AAAA record. For a CDN, the A record and its AAAA counterpart are where routing lands in DNS. They decide which address the client dials. Under anycast, the network then decides which edge server answers, not the record.

How it works

An A record binds an owner name to one IPv4 address. On the wire, the data is exactly those 32 bits. In a zone file, it is written as 'four decimal numbers separated by dots without any imbedded spaces', for example www.example.com. 3600 IN A 192.0.2.53 (RFC 1035 section 3.4.1). Addresses like 192.0.2.53 come from the blocks 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24. RFC 5737 provides these for use in documentation. They should not appear on the public internet, so they are safe to copy into examples.

One name may hold several A records: 'Hosts that have multiple Internet addresses will have multiple A records' (RFC 1035 section 3.4.1). Those records form one RRset. A query for them 'will always return all records in the associated RRSet' (RFC 2181 section 5.1). The resolution algorithm copies every RR matching the query type into the answer (RFC 1034 section 4.3.2). Many authoritative servers then vary the order between answers. This is round-robin DNS. In BIND 9, this is the default. With no rrset-order statement in the configuration, 'the implicit default is to return all records in cyclic order'. Cyclic means 'a cyclic round-robin order, offset is based on the query ID' (BIND 9 ARM, RRset Ordering). The client picks one of the returned addresses, and not necessarily the first. A resolver 'SHOULD rank or sort the addresses' for a host with multiple addresses (RFC 1123 section 6.1.3.4). Order is therefore a hint, not a routing decision.

Every A record carries a TTL: 'the time interval that the resource record may be cached before the source of the information should again be consulted'. Zero means the record may be used only for the transaction in progress, and should not be cached (RFC 1035 section 3.2.1). RFC 1035 calls the field signed. The corrected rule is that 'a TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647' (RFC 2181 section 8). Within one RRset, 'the TTLs of all RRs in an RRSet must be the same' (RFC 2181 section 5.2).

A name is either an alias or a holder of data, never both. 'A CNAME RR identifies its owner name as an alias'. Where one is present, 'no other data should be present' (RFC 1034 section 3.6.2). An alias name 'may have no other data' beyond the DNSSEC exceptions (RFC 2181 section 10.1). A CNAME does not avoid A records. It defers them. When a lookup lands on a CNAME, the server copies it into the answer, changes the query name to the canonical name, and starts again (RFC 1034 section 4.3.2). So a chain of CNAMEs still terminates in an A or AAAA record. On a CDN, that happens in the provider's own zone.

Why it matters for a CDN

Getting traffic onto a CDN is a DNS act: 'Routing traffic to Fastly requires that the hostname requested by the end user resolves to a Fastly IP address' (Fastly, Routing traffic to Fastly). Every CDN says some version of this. For IPv4 clients, the answer is an A record. There are two ways that answer steers a client. Both end in one:

• Anycast: one address is advertised from many points of presence at once. If 'an anycast A or AAAA record is configured, then the client will receive the anycast IP, which is advertised by multiple Fastly POPs. Standard internet routing will take the user to a nearby POP'. Nearby means by routing policy, not always the geographically nearest (Fastly).
• Geo DNS and latency-based DNS: the authoritative server chooses the address per query. 'Once the DNS for a site points to an edge hostname, Akamai's mapping algorithms determine the IP address of the most optimal edge server' (Akamai, Key concepts and terms).

The second model has a limit worth knowing before you rely on it. An authoritative server picking an address by location sees the address of the querying resolver, not the user: 'Since most queries come from Intermediate Recursive Resolvers, the source address is that of the Recursive Resolver rather than of the query originator' (RFC 7871 section 1). EDNS Client Subnet exists to pass part of the client address along. But it 'is completely optional and can safely be ignored by servers that choose not to implement or enable it'. So a user on a distant public resolver can be steered to the wrong region. Resolvers keep the answer for its TTL. A wrong or stale A record is therefore a routing failure you cannot fix faster than that TTL.

What CDNs do

Vendors differ in which record you publish and in what their nameservers answer. So follow the provider's own instruction rather than assuming a plain origin A record.

• Cloudflare: an A record stores 'Your origin server address (cannot be a Cloudflare IP)' (Cloudflare, DNS record types). But proxying is on by default when you onboard a domain via the dashboard. Then 'A DNS query to the proxied record blog.example.com will be answered with Cloudflare anycast IP addresses ... instead of 192.0.2.1', hiding the origin. Proxied records get a TTL of Auto, currently 300 seconds, and 'This value cannot be edited' (Cloudflare, Proxy status). If several A records share a name and one is proxied, Cloudflare treats them all as proxied.
• Fastly: each TLS configuration provides 'three types of DNS records: A CNAME, a set of IPv4 A records, and a set of IPv6 A records'. That last set is AAAA records, as the same page's anycast note ('an anycast A or AAAA record') makes clear. The CNAME is 'The preferred method of connecting a domain to Fastly', since one record covers IPv4 and IPv6. But 'Anycast is required for apex domains (e.g., example.com) because they do not support CNAMEs in DNS' (Fastly).
• Akamai: you retire the A record on the public hostname. 'Instead of an A record, you need a CNAME record that redirects the DNS request to the edge hostname', a CNAME target such as www.example.com.edgekey.net. Akamai's own DNS then answers with the edge address (Akamai).
• AWS CloudFront: alternate domain names are CNAMEs to the distribution. But 'you can't create a CNAME record for the top node of a DNS namespace, also known as the zone apex; the DNS protocol doesn't allow it'. With Route 53, you publish an alias record instead. 'If you enable IPv6, you must create two alias resource record sets: one to route IPv4 traffic (an A record) and one to route IPv6 traffic (an AAAA record)' (AWS, Use custom URLs).

Watch out for

• A and CNAME cannot share a name. Adding a CNAME beside an existing A record is a zone error, not a fallback (RFC 2181 section 10.1).
• The zone apex needs an A record or a provider alias. The apex already carries the zone's NS records and 'a single SOA RR that describes zone management parameters' (RFC 1034 section 4.2.1). A CNAME cannot share a name with other records. That is why a CNAME is impossible alongside them at the apex. Use A and AAAA records, a Route 53 alias, or a provider's CNAME flattening.
• A records are IPv4 only. There is no way to put an IPv6 address in one. 'The AAAA resource record type is a record specific to the Internet class that stores a single IPv6 address' (RFC 3596 section 2.1). An A record alone will not reach an IPv6-only client directly.
• A DNS-only A record publishes your origin. It 'exposes your origin IP address to anyone who queries the record, which removes a layer of protection against targeted attacks' (Cloudflare). Moving the hostname behind a CDN does nothing if the old origin address is still resolvable elsewhere in the zone.
• TTL is a ceiling, not a promise. 'The TTL specifies a maximum time to live, not a mandatory time to live' (RFC 2181 section 8). A resolver may drop the answer sooner, and a forwarder or a browser cache may hold it longer than you expect. Plan changes around the TTL you published before, not the one you are publishing now.
• One anycast answer does not identify a server. The same address is served by many POPs. So the returned IP tells you nothing about which POP a user reached. Read the response headers or logs instead.
• Round-robin is distribution, not load balancing. The BIND documentation is blunt: 'While alternating the order of records in a DNS response between subsequent queries is a known load distribution technique, certain caveats apply (mostly stemming from caching) which usually make it a suboptimal choice for load balancing purposes when used on its own' (BIND 9 ARM). It has no weights and no health checks: removing a failed address still waits out the TTL.

Best practice

• Publish A and AAAA records together for every hostname you serve. Dual-stack and IPv6-only clients then get the same routing.
• Keep short TTLs on records you may need to move. Fastly's migration guidance is to 'lower the TTL on the existing record (e.g., to 60), wait for a period equal to the longer TTL, and then update the record'. Cloudflare pins proxied records at 300 seconds for the same reason. Raise the TTL again only once the record is stable.
• Publish exactly the record your provider specifies: A, AAAA, CNAME or apex alias. Then check that no leftover DNS-only A record still points at the origin.
• Verify from several vantage points, not from your own laptop. Query multiple public resolvers with dig, or 'consider using a third-party tool' that checks caches around the internet (Fastly). Confirm the answer falls inside the provider's published address ranges.
• Treat the A record as the first thing to check when routing looks wrong. It is the last step before the connection. A stale answer therefore explains more outages than any cache setting.