A: IPv4 address record

One record → one IPv4 address (RFC 1035 §3.4.1). The default record type. Returned for every name-to-address lookup unless the client specifically asked for something else.

In one line:

example.isitdns.net.    A    192.0.2.1
└── this name ──────┘  └type┘ └── lives at this IPv4 address

What it holds#

A 32-bit IPv4 address, serialized as a 4-byte network-order field on the wire and rendered as dotted-quad (192.0.2.1) in tools (RFC 1035 §3.4.1).

When to use it#

• Always, for any name that needs to be reachable over IPv4.
• Round-robin: multiple A records under one name split connections across backends, no health checks.
• At the zone apex, use A (with AAAA), not a CNAME; a CNAME cannot coexist with other data at the same name (RFC 2181 §10.1). See CNAME.

When not to use it#

• For aliasing: use CNAME.
• When you only have an IPv6 address: use AAAA.
• To let clients discover the endpoint and protocol up front: publish https-svcb hints and keep A for fallback.

dig example#

$ dig @1.1.1.1 example.isitdns.net A

See it live: isitdns.net/#dig?name=example.isitdns.net&qtype=A

Gotchas#

• TTL implications. A short TTL on an A record makes failover fast but increases query load. See TTL trade-offs in fundamentals.
• No load balancing semantics. Round-robin A returns all addresses; the client decides. If you need health-checked failover, that's an L4 load balancer's job, not DNS.
• Proxied records at managed DNS providers. When a provider proxies a record (CDN edge proxy mode), the A record returns the provider's anycast IPs rather than your origin IP. Querying with dig reveals the proxy address, not what you configured in your zone. See nslookup-and-dig for how to compare authoritative vs. resolver answers.

See also#

• PTR: the reverse lookup
• All record types: cheat sheet