A record

The most fundamental thing the DNS does: look up a name, return an address. example.com goes in, 93.184.216.34 comes out. That is an A record.

Type code 1, defined in RFC 1035 §3.4.1. The value field is a single 32-bit IPv4 address, exactly the format defined by RFC 791. Everything the modern web does on top (HTTP, TLS, CDN, load balancers) depends on this one record resolving to a machine that is actually listening.

What it is

An A record is a name-to-address mapping. Nothing more.

example.com.  3600  IN  A  93.184.216.34
|              |    |   |  |
|              |    |   |  └─ the IPv4 address, four octets
|              |    |   └─ the record type (A = type 1)
|              |    └─ DNS class (IN = Internet; always this)
|              └─ TTL in seconds
└─ the owner name

Everything else about the record, including its meaning and lifecycle, is in those five fields.

The lookup

Your browser does not know where example.com lives. It asks a recursive resolver. The resolver walks the DNS tree from the root, step by step, until it finds the authoritative server for your zone and asks it for the A record.

Every hop is cached by the resolver for the TTL of the answer. In practice, most of these steps are served from cache and the whole lookup takes a few milliseconds. A cold cache can take 50-100 ms.

Multiple records

A name can have more than one A record. A resolver returns all of them, in randomised order. Clients pick the first one, which distributes load and gives basic redundancy.

example.com.  300  IN  A  198.51.100.10
example.com.  300  IN  A  198.51.100.11
example.com.  300  IN  A  198.51.100.12

This is the oldest load-balancing trick in the DNS playbook. Modern systems use anycast or dedicated load balancers, but round-robin A still works for simple cases. The weakness is that DNS has no health awareness: an A pointing at a dead host keeps getting served until the TTL expires or you remove it.

What the IP reveals

A single A record is enough to infer where a site is hosted. Every IP sits in a netblock announced by an autonomous system (AS), and BGP data tells you who owns that AS.

This is the first thing Sudory looks at when scanning a domain. A vendor behind Cloudflare, AWS, or Vercel signals very different operational posture from a vendor on a single static IP in a small ISP.

TTL and propagation

Every A record has a TTL: how long a resolver may cache the answer before asking again. Long TTLs (an hour, a day) reduce query volume and are fine for stable records. Short TTLs (60-300 seconds) let you change quickly, at the cost of more lookups.

Before a planned change, lower the TTL a few days ahead so resolvers hold the old value only briefly. After the change, raise it back. "DNS propagation" is really just waiting for cached TTLs to expire; DNS changes propagate worldwide in seconds, but stale caches keep the old answer alive until their TTL counts down.

Apex vs CNAME

You can put an A record at the zone apex (example.com) and at any subdomain (www.example.com). A CNAME works only at subdomains: the DNS spec forbids a CNAME at the apex because it would conflict with the zone's SOA and NS records.

This is the source of the "CNAME flattening" feature in Cloudflare, Route 53, and similar services. Behind the scenes the provider resolves the CNAME target and returns an A record at the apex on your behalf. It looks like a CNAME in the dashboard; it is an A record on the wire.

Common mistakes

Check what your A records resolve to, who the provider is, and whether anything points at a dead host: scan your domain.