What is an A record and when should you use it?

An A record (address record) is a DNS record that maps a hostname, such as example.com or www.example.com, to an IPv4 address, such as 192.0.2.10. When someone visits your site, their device looks up the A record to find out which server to connect to. You should use an A record whenever a name needs to point directly at a server's IPv4 address: for your bare domain, for subdomains that run on servers you control, for mail servers named in MX records, and for anything else that needs a fixed address rather than an alias to another name.

The A record is the oldest and most fundamental DNS record type, defined in the original DNS specification, RFC 1035. Almost every lookup on the internet ends with one. This article explains what an A record contains, how resolvers use it, the situations where it's the right choice, how multiple A records behave, how to create them through dashboards, zone files, APIs and Terraform, how to check them, and the mistakes to avoid.

What an A Record Contains

An A record has the same structure as any DNS record, with a 32-bit IPv4 address as its data:

www.example.com.   3600   IN   A   192.0.2.10

• Name: www.example.com., the hostname being described.
• TTL: 3600, how many seconds resolvers may cache the answer.
• Class: IN, for Internet.
• Type: A.
• Value: 192.0.2.10, the IPv4 address.

In most DNS dashboards you'll see three or four fields instead:

Field	What to enter	Example
Type	A	A
Name / Host	@ for the bare domain, or the subdomain label	@, www, api
Value / Points to	The IPv4 address	192.0.2.10
TTL	Cache time in seconds, or "Auto"	3600

The value must be a plain IPv4 address in dotted decimal form. You can't include a port number, a path, or a hostname. If you need to point a name at another hostname, that's a job for a CNAME, and if you need to point at an IPv6 address, you need an AAAA record.

How an A Record Lookup Works

When a browser needs to connect to www.example.com, the lookup goes like this:

1. The browser asks the operating system for the address of www.example.com.
2. The operating system asks its configured recursive resolver.
3. If the resolver has the A record cached, it answers immediately.
4. If not, it finds the authoritative nameservers for example.com and asks them for the A record.
5. The authoritative server returns the record, the resolver caches it for the TTL, and the browser connects to 192.0.2.10.

You can perform the same lookup with dig:

dig www.example.com A

; <<>> DiG 9.18.30 <<>> www.example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41237
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	3600	IN	A	192.0.2.10

;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

The status: NOERROR and the single line in the answer section tell you the name exists and has one A record. For a quicker view, +short prints just the address:

dig www.example.com A +short

192.0.2.10

Other tools give the same information:

host www.example.com
nslookup -type=A www.example.com

On Windows PowerShell:

Resolve-DnsName -Name www.example.com -Type A

When You Should Use an A Record

For Your Bare Domain

The bare domain, also called the apex or root of your zone (example.com with nothing in front), can't have a CNAME because it already has SOA and NS records. An A record is the standard way to make example.com resolve to your web server.

example.com.  3600  IN  A  192.0.2.10

Some DNS providers offer ALIAS or flattened CNAME records as an alternative at the apex, but a plain A record works with every provider and every resolver.

For Servers You Control

If you run a VPS, a dedicated server, or a cloud instance with a static public IPv4 address, A records are the natural choice. You know the address, it doesn't change unless you change it, and pointing a name straight at it avoids any extra lookup.

api.example.com.      3600  IN  A  198.51.100.40
staging.example.com.  3600  IN  A  198.51.100.41

For Mail Servers and Nameservers

The hostnames used in MX and NS records must resolve to addresses directly. The DNS standards say they shouldn't point to CNAMEs, so the hostnames you list there need A (and ideally AAAA) records:

example.com.        3600  IN  MX  10 mail.example.com.
mail.example.com.   3600  IN  A   192.0.2.20

When a Provider Gives You an IP Address

Some hosting platforms give you an IP address to use for your domain, rather than a hostname. Their documentation will say something like "create an A record for @ pointing to 203.0.113.80". In that case, use exactly the value they give you.

When Not to Use an A Record

An A record isn't the best choice when:

• The target's IP address is controlled by someone else and may change, such as a SaaS platform or CDN that gives you a hostname. Use a CNAME on a subdomain so the provider can change addresses freely.
• You need IPv6: Add an AAAA record alongside your A record.
• The address is dynamic, such as a home broadband connection. You'll need a dynamic DNS client to keep the A record up to date.
• You want to redirect to another URL: DNS can't do redirects. An A record only says where a name lives; a redirect from one URL to another has to be done by a web server.

Multiple A Records for One Name

You can publish more than one A record for the same name. This is perfectly valid and is used for basic load distribution and redundancy:

www.example.com.  300  IN  A  192.0.2.10
www.example.com.  300  IN  A  192.0.2.11
www.example.com.  300  IN  A  192.0.2.12

A query returns all three:

dig www.example.com A +short

192.0.2.11
192.0.2.12
192.0.2.10

Many resolvers rotate the order of the addresses between responses, which is known as round-robin DNS. Clients usually try the first address and fall back to the others if it fails, so traffic is spread roughly across the servers.

Keep in mind the limits of this approach:

• No health checks: Plain DNS has no idea whether a server is up. If one of the three servers fails, its address is still handed out until you remove the record and the TTL expires.
• Uneven distribution: Caching and client behaviour mean traffic won't be split exactly evenly.
• Client behaviour varies: Most modern browsers try the next address quickly if the first doesn't respond, but not all software does.

For serious load balancing or failover, use a load balancer or a DNS provider with health-checked records, and keep plain multiple A records for simple redundancy.

Wildcard A Records

A wildcard A record matches any name that doesn't have its own record:

*.example.com.  3600  IN  A  192.0.2.10

With this in place, anything.example.com resolves to 192.0.2.10, unless anything has its own records. Wildcards are handy for multi-tenant applications, but they also make typos resolve successfully, so use them deliberately.

How to Create an A Record

In a DNS Dashboard

The steps are almost identical at every provider:

1. Sign in to the provider that hosts your DNS. Check with dig example.com NS +short if you're not sure which one it is.
2. Open the DNS records page for your domain.
3. Add a new record with type A.
4. Enter @ for the bare domain, or a label such as www for a subdomain.
5. Enter the IPv4 address.
6. Choose a TTL. One hour is a good default; use 300 seconds if you expect to change it soon.
7. Save, then check the result with dig.

In a BIND Zone File

If you run your own authoritative server, add the record to the zone file, increase the SOA serial number, and reload the zone:

$ORIGIN example.com.
$TTL 3600
@     IN  A  192.0.2.10
www   IN  A  192.0.2.10
api   IN  A  198.51.100.40

named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

With the Cloudflare API

Cloudflare's API creates DNS records with a POST to the zone's dns_records endpoint. Setting "proxied": false makes the record return your real IP address; true routes traffic through Cloudflare's network and returns Cloudflare addresses instead.

curl -X POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "A",
    "name": "api.example.com",
    "content": "198.51.100.40",
    "ttl": 3600,
    "proxied": false
  }'

With Terraform on Amazon Route 53

Defining records as code keeps a history of every change and lets you review them before they go live:

resource "aws_route53_record" "apex" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "example.com"
  type    = "A"
  ttl     = 3600
  records = ["192.0.2.10"]
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 300
  records = ["198.51.100.40", "198.51.100.41"]
}

Note that a single Route 53 record set holds all the addresses for a name, so multiple A records go in one records list rather than separate resources.

Checking an A Record

After creating or changing an A record, check it in two places:

# 1. Ask the authoritative nameserver directly (shows what you've published)
dig @ns1.example.net www.example.com A +short

# 2. Ask a public resolver (shows what visitors are likely to see)
dig @1.1.1.1 www.example.com A +short

If the authoritative server shows the new address but a public resolver shows the old one, the change is correct and the resolver is still serving its cached copy until the old TTL runs out.

You can also confirm the server at that address is actually serving your site, independent of DNS, with curl --resolve:

curl -sI --resolve www.example.com:443:192.0.2.10 https://www.example.com/

HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8

This connects to 192.0.2.10 while sending the correct hostname for TLS and HTTP, which is a reliable way to test a new server before you switch the A record to it.

Common A Record Mistakes

1. Using a private IP address on a public domain: Addresses such as 10.x.x.x, 172.16–31.x.x and 192.168.x.x only work inside a local network. Visitors on the internet can't reach them.
2. Forgetting the www record: If you only create an A record for example.com, visitors who type www.example.com get an error. Add a record for both.
3. Leaving old A records in place: A forgotten record pointing to a server you've shut down, or to a cloud IP you've released, can serve the wrong content or be taken over by someone else.
4. Conflicting with a CNAME: You can't have an A record and a CNAME on the same name. Remove one before adding the other.
5. Pointing at an address that changes: Cloud instances without a reserved or elastic IP can get a new address when restarted, which breaks the record.
6. Adding an A record at the wrong provider: If your nameservers point elsewhere, records added in your registrar's DNS panel have no effect.

---

FAQ: A Records

---

Conclusion

An A record is the simplest and most important DNS record: it tells the world which IPv4 address a name lives at. Use it for your bare domain, for servers with stable addresses that you control, and for the hostnames your MX and NS records rely on. Add more than one for simple redundancy, and pair it with an AAAA record if your server supports IPv6.

Before relying on a new or changed A record, test the server directly with curl --resolve, check both the authoritative answer and a public resolver with dig, and choose a TTL that matches how often you expect to change it. Avoid private addresses, conflicting CNAMEs and forgotten records, and your A records will quietly do their job for years.