Today I had to programmatically verify a few DNS records instead of just setting them through a dashboard, which ended up making me revisit all the small nits and bits of DNS settings that are usually easy to overlook.
Core DNS records
DNS (Domain Name System) is basically the internet’s lookup layer that maps human-readable domains to the underlying services they point to. DNS records are the different instructions that tell the system where to route traffic, how to handle email, and how to verify ownership or security settings.
The main ones you typically deal with in practice are listed below.
| Record | What it does | Example |
|---|---|---|
| A | Maps a domain to an IPv4 address | example.com → 93.184.216.34 |
| AAAA | Maps a domain to an IPv6 address | example.com → 2606:2800:... |
| CNAME | Alias to another domain | www.example.com → example.com |
| MX | Routes email to mail servers | example.com → aspmx.l.google.com |
| TXT | Stores arbitrary text (often policies like SPF/DKIM) | v=spf1 include:_spf.google.com ~all |
| NS | Defines authoritative DNS servers | example.com → ns1.cloudflare.com |
Quick notes
One thing that becomes obvious when checking DNS programmatically is that resolution is rarely a single step. A CNAME is not a final result but an alias that may point to another hostname, which itself may also be a CNAME. This creates a resolution chain that needs to be followed until you eventually land on a concrete A or AAAA record. In practice, validation logic has to follow the full chain rather than stopping at the first response.
Another thing that stands out is how inconsistent "propagation" really is. DNS changes are not pushed globally in real time. Instead, every resolver caches results independently based on TTL values and its own behavior. That means different clients can temporarily see different results for the same domain after a change, depending on what they have cached and for how long.
