A and AAAA records

An A record maps a name to an IPv4 address. An AAAA record maps a name to an IPv6 address. These are the two records that get a browser to a server.

Here’s what they look like in zone-file form:

www.example.com.  300  IN  A     192.0.2.40
www.example.com.  300  IN  AAAA  2001:db8::40

Read each line left to right. www.example.com. is the owner name. 300 is the TTL in seconds. IN is the class (always IN for internet). Then the type and the value.

Only an address goes in there

The value is an IP address and nothing else. No https://, no port, no path. I see people paste a full URL into an A record field, and the dashboard rejects it, or worse, accepts something broken.

DNS gets the client to a host. Everything after that, the port, the protocol, the path, belongs to the application.

Several addresses for one name

A name can have more than one A record, and more than one AAAA record. The resolver returns all of them and clients pick one.

Don’t mistake this for a health check. If one of those servers is down, DNS keeps handing out its address anyway. Unless something monitors the servers and removes dead addresses from the zone, some visitors will land on the broken one.

Should you publish AAAA?

Modern clients ask for both A and AAAA and pick whichever path works better for them. That’s good, when IPv6 really works.

Publish an AAAA record only when the whole path is ready: the service listens on IPv6, the firewall allows it, TLS is configured for it, and traffic can come back. A half-working IPv6 setup makes a perfectly fine IPv4 site look flaky. Some visitors will wait for a timeout before falling back.

Check both families separately

Let’s test the two address families on their own:

dig A www.example.com +short
dig AAAA www.example.com +short
curl -4 https://www.example.com/
curl -6 https://www.example.com/

The two dig commands show what DNS publishes. The two curl commands test the actual connection over IPv4 and over IPv6.

Notice that curl tests much more than DNS. It needs routing, a listening service, and a valid certificate. If dig returns an address and curl fails, DNS did its job. The problem is somewhere else.

Try this with a hostname you use. Query both types. If both exist, connect over both families and check whether the DNS evidence and the HTTP evidence agree.