What Is an A Record

An A (Address) record is the most fundamental DNS record type. It maps a domain name to an IPv4 address, allowing users to access your website using an easy-to-remember name instead of a numeric IP address. When someone asks "What is DNS?", the A record is usually the first example that comes up -- it is the original building block of the Domain Name System.

How A Records Work

When someone types your domain into a browser:

1. The browser asks a DNS resolver for the A record
2. The resolver returns the IPv4 address from the A record
3. The browser connects to that IP address to load your site

example.com.    3600    IN    A    192.0.2.1

This record tells DNS resolvers that example.com points to 192.0.2.1 with a TTL of 3600 seconds (1 hour).

The Wire Format

An A record stores a single 32-bit IPv4 address. In the DNS wire format, the RDATA section is exactly 4 bytes. The human-readable form uses dotted-decimal notation (e.g., 192.0.2.1), where each octet represents a value from 0 to 255. This is in contrast to AAAA records, which store 128-bit IPv6 addresses.

Common Use Cases

Single Server Hosting

Point your domain to a web server:

example.com.       3600    A    192.0.2.1
www.example.com.   3600    A    192.0.2.1

When you configure both the apex domain (example.com) and www.example.com, make sure to also set up a CNAME or redirect so users reach the correct destination regardless of which form they type.

Load Balancing with Multiple A Records

Distribute traffic across multiple servers using round-robin DNS:

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

When multiple A records exist for the same name, DNS resolvers typically rotate through them in round-robin order. Each client receives the list in a different order, distributing load across your servers. This is a simple form of load balancing, though it does not account for server health. For geographic load balancing, consider Global DNS Resolution Balancing.

Round-robin DNS works best with short TTLs (300s or less) so that changes propagate quickly. See DNS TTL Best Practices for more guidance.

Subdomains for Different Services

api.example.com.      3600    A    192.0.2.10
mail.example.com.     3600    A    192.0.2.20
staging.example.com.  3600    A    192.0.2.30

Each subdomain can point to a completely different server. This is useful when your API, mail server, and staging environment all run on separate infrastructure. For mail servers in particular, make sure the A record for your mail host matches what your MX records point to, and set up a corresponding PTR record for reverse DNS.

Wildcard A Records

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

*.example.com.    3600    A    192.0.2.1

With this configuration, anything.example.com, test.example.com, and random.example.com all resolve to 192.0.2.1. This is commonly used for SaaS platforms that give each customer a subdomain, or for catch-all hosting. Explicit records for specific subdomains always take priority over the wildcard.

Wildcards interact carefully with other record types. A wildcard A record won't match if a CNAME, TXT, or any other record already exists at that name.

Record Format

Querying A Records with dig

The dig command is the standard tool for verifying A records. Here are several useful examples:

# Basic A record lookup
dig A example.com
 
# Query a specific nameserver (useful to verify changes before propagation)
dig A example.com @ns1.dnscale.eu
 
# Get just the IP address
dig A example.com +short
 
# See all A records (useful for round-robin setups)
dig A example.com +noall +answer
 
# Check TTL remaining on a cached record
dig A example.com | grep -A1 "ANSWER SECTION"

The output includes an ANSWER SECTION showing the record name, remaining TTL, class (IN), type (A), and the IPv4 address. If you see no answer, the record may not exist, or DNS propagation may still be in progress.

Adding an A Record

Using the Dashboard

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

Using the API

Create an A record:

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
  }'

Create multiple A records for load balancing:

# First server
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": "@",
    "type": "A",
    "content": "192.0.2.1",
    "ttl": 300
  }'
 
# Second server
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": "@",
    "type": "A",
    "content": "192.0.2.2",
    "ttl": 300
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "www.example.com.",
      "type": "A",
      "content": "192.0.2.1",
      "ttl": 3600,
      "disabled": false
    }
  }
}

TTL Strategies for A Records

Choosing the right TTL depends on how often your IP address might change:

Before making IP address changes, lower your TTL 24-48 hours in advance. After the change is complete and verified, restore the original TTL. Read more in DNS TTL Best Practices.

Troubleshooting A Records

Record not resolving? Check these common causes:

1. Propagation delay: Changes can take up to the old TTL to propagate. Use dig @ns1.dnscale.eu to check the authoritative answer directly. See DNS Propagation Explained.
2. Cached stale record: Flush your DNS cache and try again.
3. Wrong zone: Make sure you're editing the correct DNS zone in the dashboard.
4. Firewall blocking: The IP address in the record may be correct, but a firewall could be blocking connections on the target server.

Best Practices

1. Use appropriate TTL values - Short TTL (300-900s) if you expect to change the IP frequently. Longer TTL (3600-86400s) for stable servers to improve caching.

2. Add both A and AAAA records - Support both IPv4 and IPv6 for better connectivity. See AAAA records.

3. Consider redundancy - Use multiple A records for high-availability setups, and explore multi-provider DNS for additional resilience.

4. Apex domain records - Use @ or leave name empty for the root domain. If you need to point the apex to another hostname, consider an ALIAS record since CNAMEs cannot be used at the apex.

5. Secure your domain - Add CAA records to control which certificate authorities can issue SSL/TLS certificates for your domain.

A Record vs CNAME vs ALIAS

Understanding when to use each record type is a common question. See our detailed CNAME vs A Record comparison, but here is a quick summary:

Related Record Types

• AAAA - IPv6 equivalent of A records
• CNAME - Alias to another domain name
• ALIAS - Root domain aliasing
• PTR - Reverse DNS (IP to domain)
• SRV - Service location records

Conclusion

A records are the foundation of DNS, enabling the internet's domain name to IP address translation. Whether you are hosting a single website, building a load-balanced infrastructure with round-robin DNS, or setting up wildcard subdomains for a SaaS platform, A records are where it all begins. With DNScale, managing A records is straightforward through the dashboard or API, and our anycast network ensures your records are served quickly from the nearest point of presence.