is it DNS? wiki/Records/A: IPv4 address record ← live monitor
Records

A: IPv4 address record

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

In one line:

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

192.0.2.7 is the IPv4 address the name neal.example.isitdns.net points to, and any resolver that looks it up may remember the answer for 300 seconds before asking again.

Read it left to right: the name someone types, the record type (A = address), and the value (the IPv4 it points to). Every record on these pages has this same three-part shape.

Type number1
RFC1035
RDATAA single IPv4 address (32 bits, dotted-quad)
Reverse counterpartPTR in .in-addr.arpa

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.

A single name can have multiple A records: that's the simplest form of DNS load distribution. Resolvers often rotate the order of the returned set; the client typically tries whichever address arrives first.

When to use it#

  • Always, for any name that needs to be reachable over IPv4.
  • Round-robin: multiple A records under the same name distribute connections across backends. Cheap, no health checks.
  • At the zone apex (the bare example.com with nothing in front): A is one of two valid choices. The other is AAAA. A CNAME at the apex is forbidden by RFC 1034 §3.6.2 (no other data can coexist with a CNAME at the same name) and RFC 2181 §10.3 (MX and NS targets can't be CNAMEs either), see CNAME for the workarounds.

When not to use it#

  • For aliasing: use CNAME.
  • When you only have an IPv6 address: use AAAA.
  • When you want clients to discover the right endpoint and protocol up front: publish HTTPS/SVCB hints (https-svcb) and keep A for fallback.

dig example#

dig @1.1.1.1 example.isitdns.net A +short
192.0.2.1

192.0.2.1 sits in 192.0.2.0/24 (TEST-NET-1), a range RFC 5737 reserves for documentation. The teaching zone uses it on purpose: the name resolves, but nothing answers at that address, so it is safe to query all day.

nslookup -type=A example.isitdns.net 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	example.isitdns.net
Address: 192.0.2.1

Watch the flags line in dig's full output to see what kind of answer you got:

dig @1.1.1.1 example.isitdns.net A
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

qr = this is a response, rd = recursion was desired, ra = recursion is available. ad (DNSSEC authenticated data) = the resolver validated the DNSSEC chain for this answer. Modern dig sets the AD bit in its queries by default, so a validating resolver like 1.1.1.1 returns it for signed zones even without +dnssec. aa (authoritative answer) appears only when you query an authoritative server directly.

nslookup's normal output does not show the DNS flags. Use dig if you need to inspect aa, ad, or ra.

DoH query (HTTPS)#

DoH carries DNS inside a TLS session on port 443 (RFC 8484), so a middlebox between you and the resolver cannot read or alter the query or the answer, and blocking it selectively is harder than blocking port 53, though networks still do it by resolver IP or SNI. That protection covers the client-to-resolver hop only; it says nothing about what the resolver itself does with the query. The JSON API reports each header flag as an explicit field, including AD (DNSSEC authenticated data), which is handy for scripting: no dig output to parse.

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.isitdns.net&type=A' | jq .
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [{ "name": "example.isitdns.net", "type": 1 }],
  "Answer": [{ "name": "example.isitdns.net", "type": 1, "TTL": 300, "data": "192.0.2.1" }]
}

"Status": 0 is NOERROR. "AD": true means a validating resolver confirmed the DNSSEC chain for this name. isitdns.net is fully signed and anchored, so a validating resolver returns AD: true here. The TTL counts down as the resolver's cache ages: 300 is the configured value you see on a fresh lookup; a repeat query may show any smaller number.

nslookup cannot send DoH/DoT/DoQ queries. Use curl or dig (9.18+, +https) for DoH. On Windows, Resolve-DnsName has no DoH parameter either; DoH there is an OS-level setting applied per configured resolver, not something you can pick per query.

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#