Most days I do not think about DNS at all. Then a server migrates, mail starts bouncing, or a certificate renewal fails, and the next two hours are spent staring at zone files trying to remember which record does what. The fix is not memorizing all 30-plus DNS record types. It is knowing the 8 or 9 that show up in real work and what each one actually does.
The Domain Name System (DNS) is the distributed database that turns names like example.com into the answers clients need to connect, deliver mail, verify ownership, or issue certificates. Every service asks DNS a slightly different question, and the answer comes back as a typed record. A website can load fine while mail delivery, certificate issuance, or domain verification quietly fails, because each of those checks a different record type on the same name.
The shape of a DNS record
A resource record carries a name, a time to live (TTL, how long a resolver may cache the answer), a class (almost always IN for Internet), a type, and a value. In a zone file that looks like this:
example.com. 3600 IN A 203.0.113.10
www 3600 IN CNAME example.com.
example.com. 3600 IN MX 10 mail.example.com.
Two details matter in this notation. The trailing dot makes the name fully qualified, so the DNS server does not append the zone name to it. Many control panels hide that dot and let you type @ for the apex (the bare zone name, with no subdomain prefix) or just the subdomain label. The TTL controls how long a resolver may cache the answer before asking again. A shorter TTL lets changes propagate faster, but it does not shorten the lifetime of records already cached with the old value, so a planned migration needs the TTL dropped at least one old-TTL interval before the move.
The records you actually use
Most day-to-day DNS work touches the same handful of record types. The list below covers what I have actually needed across hosting, mail, certificates, and CDN work, plus a few that matter for specific protocols.
- A record. Maps a hostname to an IPv4 address. The value must be an IPv4 address, not a hostname or a URL. A name can have several A records, and resolvers return the whole set, which is how cheap round-robin (a load-balancing trick where DNS returns multiple IPs in rotating order) distribution happens, but DNS does not check whether each server is actually up.
- AAAA record. Maps a hostname to an IPv6 address. Dual-stack services publish both A and AAAA. Modern clients request both and use a strategy like Happy Eyeballs (a fallback technique that races IPv6 against IPv4 and uses whichever connects first) to fail over between them. Publish an AAAA only when the service is reachable at that address; an incorrect AAAA record can delay connections for visitors whose systems prefer IPv6.
- CNAME record. Makes one name an alias of another. The zone apex (the bare domain, like
example.comitself) cannot be a CNAME because it must hold SOA (Start of Authority, the record that marks the zone’s primary server) and NS (Name Server) records. Providers work around that with ALIAS, ANAME, or CNAME flattening, which resolve the target and return an A or AAAA answer on your behalf. - MX record. Lists the servers that accept email for the domain, each with a preference number. Lower preferences win; ties share the load. MX targets must be hostnames with A or AAAA records, never an IP or another CNAME. A missing trailing dot in the zone file is a common reason the wrong server gets the mail.
- TXT record. Holds free-form text. Most use today is policy and verification: SPF (Sender Policy Framework, a list of servers allowed to send mail for the domain), DKIM (DomainKeys Identified Mail, a cryptographic signature that proves a message was not altered in transit), DMARC (Domain-based Message Authentication, Reporting, and Conformance, which tells receivers what to do with mail that fails SPF or DKIM), and provider-ownership challenges for Google, Microsoft, and others. A domain must not publish more than one SPF record starting with
v=spf1at the same name. - NS record. Names the authoritative servers for the zone. The parent zone’s delegation and the zone’s own NS set must agree, or different resolvers will get different answers. At least two NS records are standard, and most registries require it.
- SOA record. Every zone has exactly one. It identifies the primary server, stores a serial number that secondaries compare against to decide whether to transfer the zone, and sets timers for refresh, retry, expire, and the negative-cache TTL (how long resolvers remember that a name does not exist). Managed DNS services maintain these fields, but the serial still matters when debugging stale authoritative answers.
- PTR record. Reverse DNS, mapping an IP address back to a hostname. IPv4 PTR records live under
in-addr.arpa, with the octets reversed. The owner of the IP block controls the reverse zone, so for a hosted server the PTR is set in the provider’s panel, not in your normal DNS zone. Mail servers often check that the PTR hostname resolves forward to the same address; mismatches cause delivery problems. - CAA record. Restricts which certificate authorities may issue TLS certificates for the domain. A public CA checks the relevant CAA set before issuance. A typo here can block both first-time issuance and automated renewal, so it is worth checking the issuer identifier required by your CA before adding the record.
A few specialized types show up in specific environments. SRV records advertise service hostname and port combinations for SIP, XMPP, LDAP, and Active Directory. DNSSEC adds DNSKEY, DS, RRSIG, NSEC, and NSEC3 so validating resolvers can authenticate answers, but enabling DNSSEC at the provider without publishing the required DS record in the parent zone does not actually establish the chain. SVCB and HTTPS records publish connection parameters and address hints, sometimes for HTTP/3. Most domain setups do not need any of these.
Querying with dig
The fastest way to inspect what is actually published is dig, part of the standard BIND utilities. The short-answer form is:
dig +short NAME TYPE
For example, to see the A records for Cloudflare’s resolver:
dig +short one.one.one.one A
Returns both 1.0.0.1 and 1.1.1.1, in either order. Drop +short when you want the response status, TTL, and server details. MX records work the same way:
dig +short gmail.com MX
Returns answers that start with the preference number, like 5 gmail-smtp-in.l.google.com.. The lowest number is tried first. For reverse DNS, dig +short -x 1.1.1.1 builds the reverse-zone name for you.
After changing a record, remember that your resolver or operating system may keep the old answer until its TTL expires. During testing, clearing the local DNS cache forces a fresh lookup.
Trade-offs
The DNS record model has not changed much in 30 years, and the cost of that stability is that several edge cases bite you only when something breaks. A CNAME on the zone apex is illegal because the apex must hold SOA and NS records, so providers invented non-standard workarounds (ALIAS, ANAME, flattening) that work most of the time and fail in confusing ways when they do not. A TTL set too high means migrations take hours; set too low and you hammer the authoritative servers with refresh queries. MX records require fully qualified targets with A or AAAA, which means changing an IP at the mail provider becomes a two-step process instead of one.
For most small domains, the trade-off is between managed DNS at a registrar (cheap, convenient, slow to add advanced types like SRV or SVCB) and a dedicated provider like Cloudflare, Route53, or Bunny DNS (faster propagation, better API, supports modern record types, costs nothing for most use cases). DNSSEC adds a real security benefit against cache poisoning (an attack where forged DNS answers get inserted into a resolver’s cache) but brings operational complexity that a small site rarely needs unless the domain is used for high-value email or financial transactions.
In practice, the migration overhead is low. A typical move from one DNS provider to another takes an hour of setup plus a TTL window of a few hours. One thing that is harder than expected is keeping SOA and NS records in sync across the registrar’s delegation and the provider’s authoritative set during the cutover. One thing that is easier than expected is using the provider’s API to script record changes instead of clicking through a web UI.
If you run a personal site or a small business domain, the basics (A, AAAA, MX, TXT for SPF, NS) are enough and the provider’s defaults will carry you. If you operate mail at any meaningful volume or run services that other companies depend on, the time invested in understanding TTLs, CAA, and reverse DNS pays back the first time something breaks.
Bottom line
Pick a managed DNS provider that gives you an API and supports modern record types. Set sensible TTLs (3600 seconds is a reasonable default, 300 for records you expect to change soon). Use the dig command as your first diagnostic tool before opening provider dashboards. And when something breaks, check the record type the failing service actually depends on, because most “DNS is broken” tickets are really one specific record type having the wrong value, and the fix is a five-character edit, not a network overhaul.