DNS A Record vs CNAME

This guide is for teams deciding whether a new public hostname should point directly at an origin IP or alias to a provider-managed hostname.

During manual request review on and.guide, one of the easiest ways to spot a fuzzy deployment plan is simple: the team wants a clean public name, but they still cannot say whether the destination should be an A record or a CNAME. That confusion usually creates a fake DNS problem later when the real issue is just the wrong contract.

Pre-check list

Before choosing the record type, confirm these four facts:

• whether the destination was given to you as an IP address or a hostname
• whether the provider expects you to keep following its hostname as infrastructure changes
• whether HTTPS and host binding are already prepared for the final public name
• whether the public hostname is a regular subdomain or a special root-level record with provider-specific rules

If those answers are not clear yet, the safest next step is usually documentation review, not another DNS edit.

Who this is for

Use this guide if you are setting up:

• app.example.com for a platform-hosted frontend
• docs.example.com for documentation on a hosted service
• api.example.com for a self-managed origin
• preview.example.com for a release preview

The short version

• An A record maps a hostname to an IPv4 address.
• A CNAME record maps a hostname to another hostname.

That sounds like a tiny distinction, but it changes how the record survives infrastructure updates and how you verify the public destination.

When an A record is the right choice

Use an A record when the destination contract is a stable public IP that you control or knowingly depend on.

api.example.com.    300    IN    A    203.0.113.42

Typical cases:

• a VPS or dedicated origin with a fixed IP
• a load balancer or appliance that is meant to be addressed directly
• infrastructure you operate and plan to move deliberately

The upside is that the answer is direct and easy to reason about. The downside is that any IP change becomes your DNS problem immediately.

When a CNAME is the right choice

Use a CNAME when the provider gives you a hostname and expects you to follow it instead of hard-coding the current IP behind it.

docs.example.com.    300    IN    CNAME    my-docs.pages.dev.

Typical cases:

• managed hosting platforms
• edge providers that publish a canonical target
• vendors that move infrastructure behind the scenes

The upside is that the provider keeps the final IP mapping stable on its side. The downside is that you now need to understand one more lookup layer when debugging.

Decision rule that holds up in practice

Use this rule when you are under time pressure:

• if the destination is an IP, use an A record
• if the destination is a provider hostname, use a CNAME

This is not every DNS rule in the world, but it is the one that prevents the majority of subdomain setup mistakes for teams shipping public apps and docs.

Field capture

The fastest way to sanity-check the choice is to compare what dig returns for an A-based host versus a CNAME-based host.

Command checks that expose the difference

For an A record, verify that the short answer is the exact origin IP you expected:

dig +short api.example.com

203.0.113.42

For a CNAME-based host, check the alias explicitly:

dig docs.example.com CNAME +short
dig docs.example.com +short

my-docs.pages.dev.
198.51.100.24

The first command tells you whether the alias is correct. The second tells you what the next public answer currently resolves to.

Failure cases that waste the most time

A provider hostname was flattened into an A record

The team reverse-engineered the current IP behind a managed platform and published that as an A record. The site worked briefly, then drifted when the provider moved traffic.

The record type is correct, but the app still rejects the host

DNS can be fully right while the origin or platform still lacks a host binding for the new public name. At that point the DNS work is done and the application layer still needs configuration.

Both DNS and origin were changed at the same time

This creates the classic “DNS is broken” story when no one can tell whether the wrong thing is the record, the certificate, or the app routing.

Recommended rollout order

1. identify the destination contract
2. publish the matching record type
3. verify with dig
4. test the final HTTPS response

If you keep those four steps separated, A-record and CNAME decisions stay boring in the best possible way.