is it dns? / wiki ← back to the live monitor

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.

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 wraps DNS queries in HTTPS, same answers as plain DNS, but over port 443 so they can't be tampered with on the wire and are much harder to block selectively than plain port-53 traffic. 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#