DNS Records & Concepts
What is an A record?
An A record, short for Address record, is a DNS record that maps a domain name or subdomain to an IPv4 address. It is the most fundamental record in the DNS system: the direct connection between a human-readable domain name and the numerical IP address of the server that hosts it.
When a browser resolves example.com to find the web server it needs to connect to, it ultimately retrieves an A record. That record contains a single value: an IPv4 address in the familiar four-number format like 93.184.216.34. The browser connects to that IP address, the server receives the request, and the page is delivered.
The “A” in A record stands for Address, specifically IPv4 address. The AAAA record is the equivalent for IPv6 addresses. Together A and AAAA records form the most critical layer of DNS; without them a domain name cannot be resolved to a server and no web requests can be fulfilled.
How an A record works
When a visitor types example.com into their browser the DNS resolution process begins. After checking local caches the DNS resolver queries the authoritative nameserver for example.com and retrieves its DNS records. Among those records is the A record: a mapping that says example.com points to the IP address 93.184.216.34.
The resolver returns this IP address to the browser. The browser opens a TCP connection to 93.184.216.34 on port 80 for HTTP or port 443 for HTTPS. The server at that IP address receives the connection and responds with the web page or, if a redirect is configured, with a 3xx redirect response pointing to the appropriate destination.
A records can be set at multiple levels within a domain:
Root domain: example.com → 93.184.216.34. The A record for the root domain, also called the apex domain, maps the base domain without any subdomain prefix to the server IP.
Subdomain: www.example.com → 93.184.216.34. A separate A record for the www subdomain pointing to the same or a different IP address than the root domain.
Other subdomains: blog.example.com → 185.40.5.42. Any subdomain can have its own A record pointing to a completely different server, allowing different parts of a domain to be hosted on different servers.
Wildcard: *.example.com → 93.184.216.34. A wildcard A record matches any subdomain that does not have a more specific record defined. A request for anything.example.com would resolve to 93.184.216.34 if no specific record exists for anything.
A record values and format
An A record’s value is always an IPv4 address, four groups of numbers between 0 and 255 separated by dots. 93.184.216.34, 172.217.0.46, 104.21.30.120 are all valid A record values. Nothing else is a valid A record value: a domain name, a URL, or any other format is not valid and will be rejected by DNS management interfaces.
Multiple A records can exist for the same domain name, each pointing to a different IP address. This is used for load balancing; DNS returns different IP addresses for the same domain name in round-robin rotation, distributing incoming connections across multiple servers. If one server becomes unavailable, DNS can stop returning its IP address and route all traffic to the remaining servers.
A records vs CNAME records
The distinction between A records and CNAME records is one of the most important practical DNS concepts for anyone managing domains and redirects.
An A record maps a domain directly to an IP address. A CNAME record maps a domain to another domain name, an alias. The resolver follows the CNAME to the target domain and looks up its IP address there.
When to use an A record: when you know the specific IP address the domain should point to and that IP address is stable. Pointing a domain to a dedicated server with a fixed IP. Pointing to redirect management infrastructure that provides specific IP addresses.
When to use a CNAME: when the destination is another domain name rather than a fixed IP address. Connecting www.example.com to a CDN, hosting platform, or redirect management service that provides a hostname like proxy.redirect.supply rather than an IP address. The CNAME allows the target service to update its IP addresses without requiring DNS changes on the connected domain.
The apex domain restriction: the most important practical distinction between A records and CNAMEs is that CNAME records are prohibited at the zone apex, the root domain without any subdomain prefix. www.example.com can have a CNAME. example.com cannot.
This restriction exists because of technical requirements in the DNS specification. A zone’s apex must have NS records and SOA records, and having a CNAME at the apex would conflict with these requirements. Since A records point directly to IP addresses rather than aliasing another domain they are compatible with apex requirements.
This restriction creates a practical challenge when connecting root domains to services that only provide a hostname rather than a fixed IP address. Several solutions exist depending on the DNS provider.
ALIAS / ANAME records: some DNS providers offer non-standard record types that provide CNAME-like behaviour at the apex. These records resolve the target hostname to its current IP address at the DNS level and return an A-record response to resolvers. Cloudflare’s CNAME flattening provides this automatically; a CNAME configured at the apex is resolved to an IP address before the response leaves Cloudflare’s nameservers.
Changing nameservers: moving DNS to a provider that supports apex CNAME-like functionality through ALIAS or ANAME records or CNAME flattening.
Using A records with the service’s IP addresses: if the redirect management service or CDN provides stable IP addresses, as Cloudflare and some others do, an A record can point directly to those IP addresses. This requires knowing the IP addresses and updating the A record if the infrastructure changes.
A records and redirect management
A records play a specific role in redirect management: they are one of the two primary methods for connecting a domain to redirect infrastructure, alongside CNAME records.
Connecting subdomains via CNAME: for subdomains like www.example.com, a CNAME record pointing to the redirect management infrastructure is the standard approach. www.example.com CNAME proxy.redirect.supply routes all requests for the www subdomain to the redirect service’s servers where HTTP redirect rules are applied.
Connecting root domains via A record: for the root domain example.com, an A record pointing to the redirect infrastructure’s IP addresses is required when the DNS provider does not support ALIAS or ANAME records. The redirect management service provides the IP addresses to use, and A records are configured for each one.
A records for verification: some redirect management services and CDNs require A records as part of their domain verification process, checking that the domain’s A record points to their infrastructure before activating redirect rules.
Impact on HTTP redirects: the A record itself does not perform any HTTP redirect. It only determines which server receives the request. Once the request reaches the redirect management server HTTP redirect rules: 301, 302, and others, determine where the visitor is sent. DNS and HTTP operate at different layers. The A record handles the network routing. The HTTP redirect handles the URL routing.
A records and SSL certificates
SSL certificates and A records are connected in how HTTPS connections are established for a domain.
When a browser connects to https://example.com it needs to establish a TLS connection to the server. The browser uses the IP address from the A record to find the server, then performs a TLS handshake. During the handshake the server presents its SSL certificate. The browser verifies the certificate is valid for example.com.
For this to work correctly the SSL certificate must be issued for the domain, and the server at the IP address in the A record must have the certificate installed. If the A record points to a server that does not have a valid certificate for the domain, visitors see a certificate error.
In redirect management setups where A records point to redirect infrastructure, the redirect management service must have a valid SSL certificate for the connected domain. This is why dedicated redirect management platforms provision SSL certificates automatically for connected domains, ensuring the TLS handshake succeeds before the HTTP redirect response is sent to the visitor.
Checking A records
A records can be verified using several tools that query the DNS system and return the current values.
dig command: the most authoritative tool for DNS lookup on Linux and macOS:
Returns the A record values for example.com along with the TTL and the authoritative nameserver that answered the query. Adding +short to the command returns just the IP address:
nslookup: available on Windows, macOS, and Linux:
Returns the A record IP address for the domain.
Online DNS lookup tools: web-based tools that perform DNS lookups from multiple geographic locations simultaneously, useful for checking whether A record changes have propagated globally and whether different resolvers around the world are returning the same values.
Checking specific nameservers: to check the A record as stored on the authoritative nameserver rather than what a resolver has cached, query the nameserver directly:
This bypasses resolver caches and shows the current value on the authoritative nameserver, useful when a record has been updated but has not yet propagated to resolvers due to TTL caching.
Common A record issues in redirect management
Wrong IP address: the most straightforward A record error. The record points to an IP address that is not the redirect management infrastructure; either an old server IP that was not updated during setup, or a typo in the IP address. The fix is updating the A record to the correct IP address.
Missing A record for root domain: the www subdomain is connected via CNAME but the root domain has no A record pointing to redirect infrastructure. Visitors typing example.com without www reach the old server or get an error while visitors typing www.example.com reach the redirect service correctly. Both the root domain and www subdomain need to be connected.
A record pointing to old server after migration: after a domain migration the A record was updated for the primary domain but old A records remain for subdomains or the reverse. Auditing all A records after a migration confirms every record points to the current infrastructure.
TTL too high before changes: attempting to update an A record with a high TTL means the old IP address is cached for a long period after the change. Lowering TTL well before planned changes minimises the propagation window.
Conflicting A record and CNAME: attempting to create a CNAME record for a name that already has an A record, or vice versa, creates a DNS conflict. Most DNS management interfaces prevent this but it is worth checking for when diagnosing unexpected DNS behaviour.