DNS Reference

Registrar vs. DNS host

These are two separate roles, sometimes handled by the same company and sometimes not. The registrar (Route 53 domain registration, Namecheap, GoDaddy, etc.) is who you bought the domain from and who's on record with ICANN as the owner. The DNS host (Route 53 hosted zones, Cloudflare, the registrar's own DNS) is whoever actually answers DNS queries for the domain, based on which nameservers the registrar has set. It's entirely normal to buy a domain at one registrar and point its nameservers at a different provider's DNS.

Common record types

Type	Points to	Typical use
A	An IPv4 address	Pointing a domain directly at a server's IP — e.g. a Lightsail static IP.
AAAA	An IPv6 address	The IPv6 equivalent of an A record.
CNAME	Another hostname	Aliasing a subdomain to another domain name — can't be used on a zone apex (bare domain).
ALIAS (Route 53 only)	An AWS resource (S3, CloudFront, an ELB) or another record	A Route 53-specific extension that behaves like a CNAME but is allowed at the zone apex — the standard way to point a bare domain at a load balancer or CloudFront distribution.
MX	A mail server hostname, with a priority	Routing email for the domain to a mail provider (Google Workspace, etc.). Lower priority number wins.
TXT	Arbitrary text	Domain ownership verification, SPF/DKIM/DMARC email authentication records.
NS	Nameserver hostnames	Delegates a (sub)domain to a specific set of nameservers.

Pointing a domain at a Lightsail/EC2 instance

Type: A
Name: @ (or blank, for the bare domain)
Value: STATIC_IP
TTL: 300

Type: A
Name: www
Value: STATIC_IP
TTL: 300

Using the instance's static/Elastic IP here matters — pointing an A record at a non-static IP works until the instance is next stopped and started, at which point the IP changes and the A record silently starts resolving to nothing.

TTL

TTL (time to live, in seconds) controls how long resolvers are allowed to cache a record before re-querying. A low TTL (60–300s) means changes propagate fast but generates more DNS query traffic; a high TTL (3600s+) is cheaper to serve but means a change takes longer to be seen everywhere. The common pattern: drop the TTL to something low (e.g. 60s) a day or two before a planned change, let that propagate, make the change, then raise the TTL back up once it's confirmed working.

Propagation and checking a change

"Propagation" is really just every resolver's cache expiring and re-querying on its own schedule — there's no single moment a change "goes live" everywhere at once. Bypass your local machine's cached/ISP resolver and query an authoritative or public resolver directly to check a change immediately:

dig example.com A +short
dig example.com A @8.8.8.8 +short   # query Google's resolver directly
dig example.com NS +short           # confirm which nameservers are authoritative

Route 53 specifics

A Route 53 hosted zone is the container for a domain's records, and creating one assigns four AWS nameservers — those need to be set at the registrar (even if the registrar is Route 53 itself) before Route 53's records take effect. Health checks and routing policies (weighted, latency-based, failover) go beyond simple A records for anything needing multi-region failover or traffic splitting, but for a single instance behind a single domain, a plain A or ALIAS record is all that's needed.