DNS deep dive: zones, records and DNSSEC

Zone files and delegation, the record types that matter, TTL and caching behaviour, why propagation is really cache expiry, and what DNSSEC and DoH do and do not fix.

The record types you will actually use

example.com.        3600  IN  SOA   ns1.example.com. admin.example.com. (
                                    2026091801 ; serial, increment on every change
                                    7200       ; refresh
                                    3600       ; retry
                                    1209600    ; expire
                                    300 )      ; negative TTL
example.com.        3600  IN  NS    ns1.example.com.
example.com.        3600  IN  NS    ns2.example.com.
example.com.        300   IN  A     203.0.113.10
www.example.com.    300   IN  A     203.0.113.10
example.com.        300   IN  AAAA  2001:db8::10
api.example.com.    60    IN  CNAME edge.example.net.
example.com.        3600  IN  MX    10 mail.example.com.
example.com.        3600  IN  TXT   "v=spf1 include:_spf.example.net -all"
_dmarc.example.com. 3600  IN  TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
TypePoints toNotes
AIPv4 addressThe base record
AAAAIPv6 addressClients prefer it when both exist
CNAMEAnother nameCannot coexist with other records at the same name
MXMail host with a priorityLower priority value wins
TXTArbitrary stringsSPF, DKIM, DMARC and site verification
NSAuthoritative name serversDefines delegation for a zone
SOAZone metadataThe serial drives secondary replication
PTRA name from an addressReverse DNS, lives in a separate zone
CAAPermitted certificate authoritiesRestricts which CAs may issue for the domain

TTL, caching and propagation

A DNS change does not propagate anywhere. It is simply not visible until the caches that hold the old answer expire, and the TTL is the only thing controlling how long they hold it.

  1. Lower the TTL well before a planned change, at least one old TTL in advance.
  2. Wait for the old TTL to expire everywhere, then make the change.
  3. Verify with several resolvers in different networks, not just your own.
  4. Raise the TTL again once the change is confirmed stable.
  5. Remember that resolvers may ignore your TTL and enforce their own minimum.
# ask a specific resolver, bypassing the local cache
dig +short @1.1.1.1 example.com A
dig @8.8.8.8 example.com MX +noall +answer
dig +trace example.com            # walk from the root down

# see the remaining TTL and the authority
dig example.com A | grep -A2 "ANSWER SECTION"

# reverse lookup
dig -x 203.0.113.10 +short

DNSSEC, DoH and the limits of each

FeatureProtects againstDoes not protect
DNSSECForged or modified answers on the pathConfidentiality; the query is still visible
DoH / DoTOn-path observers reading or altering queriesA malicious resolver; it sees everything
DNSSEC plus DoHBoth tampering and observationA compromised authoritative server or key
CAAMis-issuance by an unauthorised CAA CA that is authorised but compromised
AnycastSingle point of failureBGP hijacking of a more specific prefix
  • DNSSEC signs records so a resolver can detect tampering, but it does not hide the query content.
  • DoH and DoT encrypt the transport to the resolver, which is useful against local interception but moves trust to the resolver.
  • Encrypted DNS inside an application can bypass enterprise policy, so deployment needs a governance decision, not only a technical one.
  • A high negative TTL on a zone keeps a missing-name answer cached, which is good for load and bad when you add the name.
💡
Debug from the bottom up: dig +trace shows the delegation path, and querying each level's name servers separates a broken zone from a stale cache. Most DNS incidents are caching or delegation, not protocol failure.

FAQ

Can I use a CNAME at the apex of a domain?
Not with the standards, because the apex must also carry SOA and NS records, and a CNAME may not coexist with other data. Providers offer a proprietary alias record that behaves like a CNAME at the apex.
How long does a DNS change take?
As long as the old TTL plus resolver minimums. It is never instant, and lowering the TTL in advance is the only reliable way to make it fast.

TLS and HTTPS: certificates and the handshake Network debugging toolkit

Last refreshed 2026-09-18.