DNS A Record Explained — What It Is and How to Use It

The A record is the most widely used DNS record type on the internet. Short for "Address record," it performs a single, essential function: mapping a human-readable domain name to an IPv4 address. Every time someone visits a website, sends an email, or connects to an API, there is almost certainly an A record involved in resolving the destination.

This guide covers everything you need to know about A records, from basic syntax to advanced configurations like round-robin load balancing, with practical dig command examples you can run yourself.

What Is an A Record?

An A record is a type of DNS record that stores the IPv4 address associated with a domain name. When a user types example.com into their browser, the DNS resolution process begins. A recursive resolver queries the authoritative nameserver for the domain and receives back the A record, which contains the IPv4 address where the web server is running.

Here is a minimal A record in standard zone file format:

example.com.    3600    IN    A    93.184.216.34

Breaking this down:

Tip: The trailing dot after the domain name indicates a fully qualified domain name (FQDN). DNScale adds this automatically, so you do not need to include it when creating records through the dashboard or API.

How DNS Resolution Uses A Records

Understanding how A records fit into the DNS resolution process helps you troubleshoot issues and configure records correctly.

1. A user types www.example.com into their browser
2. The operating system checks its local DNS cache
3. If no cached result exists, the query goes to the configured recursive resolver
4. The resolver checks its own cache, then queries the root servers, the .com TLD servers, and finally the authoritative nameserver for example.com
5. The authoritative server returns the A record: www.example.com. 3600 IN A 93.184.216.34
6. The resolver caches the result for the TTL duration and returns it to the client
7. The browser connects to 93.184.216.34 over TCP

Each step in this chain relies on the A record being correctly configured. An incorrect IP address, an overly long TTL, or a missing record will cause the connection to fail.

A Record Syntax and Format

Basic A Record

The simplest configuration points your apex domain (also called the root or naked domain) to a server:

example.com.    3600    IN    A    192.0.2.1

Subdomain A Records

You can create A records for any subdomain. Each subdomain can point to a different IP address, allowing you to run different services on different servers:

www.example.com.       3600    IN    A    192.0.2.1
api.example.com.       3600    IN    A    192.0.2.10
mail.example.com.      3600    IN    A    192.0.2.20
staging.example.com.   3600    IN    A    192.0.2.30

Wildcard A Records

A wildcard A record matches any subdomain that does not have its own explicit record:

*.example.com.    3600    IN    A    192.0.2.1

With this in place, anything.example.com resolves to 192.0.2.1 unless a more specific record exists. This is useful for platforms that dynamically generate subdomains, such as SaaS applications providing customer.yourapp.com URLs.

Note: Wildcard records do not match the apex domain itself. You still need a separate A record for example.com.

Multiple A Records and Load Balancing

One of the most practical features of A records is that you can create multiple records with the same name but different IP addresses. DNS resolvers rotate through these addresses using round-robin, distributing traffic across multiple servers:

example.com.    300    IN    A    192.0.2.1
example.com.    300    IN    A    192.0.2.2
example.com.    300    IN    A    192.0.2.3

When a resolver queries for example.com, the authoritative server returns all three addresses. Most resolvers randomize or rotate the order, spreading requests across your servers.

Tip: Use a shorter TTL (300 seconds) for round-robin configurations. This allows resolvers to refresh the record set more frequently, which is important if you need to remove a failed server quickly. For more on TTL strategy, see DNS TTL Best Practices.

This approach works well for basic load distribution, but it does not perform health checking. If one server goes down, DNS will continue returning its address until you remove the record. For production-grade load balancing, consider combining round-robin DNS with health-checked load balancers or DNScale's anycast network.

Querying A Records with dig

The dig command is the standard tool for querying and debugging DNS records. Here are the most useful commands for working with A records.

Basic A Record Query

dig A example.com

Example output:

;; ANSWER SECTION:
example.com.        3600    IN    A    93.184.216.34

Query a Specific Nameserver

To verify that your authoritative nameserver is returning the correct record, query it directly:

dig A example.com @ns1.dnscale.eu

This bypasses any resolver caching and shows you exactly what DNScale is serving.

Query with Short Output

For scripts or quick checks, use the +short flag:

dig +short A example.com

Output:

93.184.216.34

Check Multiple A Records (Round-Robin)

When you have multiple A records, dig returns all of them:

dig A example.com +short

Output:

192.0.2.1
192.0.2.2
192.0.2.3

Trace the Full Resolution Path

To see every step of DNS resolution from root servers down to the authoritative answer:

dig A example.com +trace

This is invaluable for diagnosing DNS propagation issues after making changes.

Check TTL Countdown

Run the same query twice in quick succession to see the TTL counting down, confirming your record is being cached:

dig A example.com | grep -A1 "ANSWER SECTION"

TTL Best Practices for A Records

Choosing the right TTL value for your A records depends on how frequently the IP address might change:

Tip: Before a planned IP change, lower your TTL 24-48 hours in advance. This ensures that by the time you make the change, no resolver is caching the old record for longer than your new, shorter TTL. Once the migration is complete and stable, raise the TTL back to a longer value.

Creating A Records in DNScale

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Set the fields:
   • Name: Enter the subdomain (e.g., www, api) or @ for the apex domain
   • Type: Select A
   • Content: Enter the IPv4 address (e.g., 192.0.2.1)
   • TTL: Set the cache duration in seconds (default: 3600)
4. Click Create Record

Using the DNScale API

Create an A record via the REST API:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "www",
    "type": "A",
    "content": "192.0.2.1",
    "ttl": 3600
  }'

Verify the record was created:

dig A www.example.com @ns1.dnscale.eu

For infrastructure-as-code workflows, you can also manage A records using the DNScale Terraform provider or DNSControl.

Common Mistakes

1. Using a Private IP Address

A records must contain publicly routable IPv4 addresses. Addresses in the 10.x.x.x, 172.16-31.x.x, or 192.168.x.x ranges are private and will not work for public DNS.

2. Forgetting the AAAA Record

An A record only provides IPv4 connectivity. Users on IPv6-only networks (increasingly common on mobile) cannot reach your server unless you also add an AAAA record. Always configure both for a proper dual-stack setup.

3. Setting TTL Too High Before a Migration

If you set a TTL of 86400 (24 hours) and then change the IP, some users may not see the new address for up to a full day. Lower the TTL well in advance of any planned changes.

4. Conflicting with a CNAME Record

You cannot have both a CNAME and an A record at the same name. If www.example.com has a CNAME, you cannot also add an A record there. Choose one approach or use an ALIAS record for apex domains.

5. Missing Reverse DNS (PTR Record)

For mail servers, many receiving servers check that the IP address in your A record has a matching PTR record. Without reverse DNS, your emails may be marked as spam.

A Record vs CNAME: When to Use Each

One of the most common decisions in DNS configuration is whether to use an A record or a CNAME record. Here is a quick decision framework:

Use an A record when:

• You are configuring the apex/root domain (example.com)
• You know the IP address and it is relatively stable
• You need maximum performance (no extra DNS lookup)
• You need other records (MX, TXT) at the same name

Use a CNAME when:

• You are pointing a subdomain to a third-party service (CDN, SaaS, PaaS)
• The target IP may change and is managed by someone else
• You want a single point of configuration that follows the canonical name

For a detailed comparison, see CNAME vs A Record.

How DNScale Handles A Records

DNScale uses PowerDNS authoritative servers deployed across a global anycast network. When you create an A record through the dashboard or API:

1. The record is written to the primary PostgreSQL database
2. It is immediately available on the authoritative nameservers
3. The record replicates to all edge nodes via PostgreSQL logical replication
4. Users worldwide receive the answer from the nearest edge location

This architecture provides sub-second record updates with global availability. DNScale supports all standard A record features including multiple records per name, wildcard records, and per-record TTL values.

Conclusion

The A record is the workhorse of DNS. It is the record type you will use most often, whether you are pointing a single domain to a web server or building a globally distributed infrastructure with round-robin load balancing. Getting A records right means understanding TTL trade-offs, remembering to add companion AAAA records for IPv6 support, and knowing when a CNAME might be a better fit.

For further reading, explore these related guides:

• DNS Record Types -- Overview of all DNS record types
• What Is DNS? -- How the Domain Name System works
• DNS AAAA Record Explained -- The IPv6 companion to A records
• CNAME Records Explained -- When to alias instead of using an IP
• DNS TTL Best Practices -- Choosing the right cache duration