DNS treated as the distributed system it is: which records matter, what TTL really controls, why propagation is the wrong word, negative caching, CAA to restrict certificate issuance, and how to move a domain without a gap in service.
DNS is treated as configuration and behaves like a distributed system. You change a value in a control panel, the panel says "saved", and then reality updates unevenly over minutes or hours across thousands of independent caches you do not control. Most DNS incidents come from this gap between how it feels and how it works.
This guide covers the records a Django deployment depends on, how caching really behaves, how to move a domain to a new server without a visible gap, and two mechanisms — CAA and DNSSEC — that are worth understanding before someone suggests enabling them.
These get conflated constantly, and the confusion causes real outages. The registrar is who you buy the domain from. The DNS host runs the servers that answer queries. The nameserver records tell the world which DNS host is authoritative.
They are frequently the same company, which hides the distinction until the day you move one of them. Changing a record at your DNS host takes effect in minutes. Changing which nameservers are authoritative is a registry operation with much longer caching, and it is the change people underestimate. Before touching anything, check where the domain is actually served from:
dig +short NS example.com
dig +short SOA example.comA handful of record types carry almost all the weight. A maps a name to an IPv4 address, AAAA to IPv6. CNAME aliases one name to another. MX directs mail. TXT holds verification strings and mail policy. CAA restricts which authorities may issue certificates for the domain.
For a typical Django deployment that means A and AAAA for the apex and for www, MX and TXT for mail, and CAA if you want to constrain issuance. Everything else is usually a third-party verification record that someone added once and nobody dares remove.
The bare domain cannot be a CNAME, because the apex must also carry NS and SOA records and a CNAME may not coexist with other records. This is not a limitation of your provider; it is how the protocol is defined.
It matters when a platform tells you to point your domain at a hostname rather than an address. For www that is a plain CNAME. For the apex you need either a real address record or a provider-specific flattening feature — often called ALIAS or ANAME — which resolves the target and answers with its addresses. Providers that lack it force you to hardcode an address, which then becomes stale when the platform changes it.
Every record carries a time-to-live: how long a resolver may cache the answer. The crucial consequence is that the TTL in effect during a change is the old one, cached before you touched anything.
Lower the TTL well before a planned change — a day ahead is comfortable, an hour is not, because resolvers that already cached the old value keep it for the old duration. Do the work, confirm everything is stable, then raise the TTL again. Leaving it low forever means more queries and more sensitivity to any DNS outage.
dig +noall +answer example.com A # the number before IN is the remaining TTL
dig +noall +answer example.com A # run again after ten seconds: it counts downNothing propagates. There is no push. Authoritative servers answer the new value immediately; every resolver in the world keeps serving the old one until its cached copy expires and it asks again. What people call propagation is thousands of independent caches expiring at different moments.
This explains behaviour that otherwise looks like magic: a colleague sees the new site while you see the old one, your phone on mobile data differs from your laptop on WiFi, and clearing your browser cache changes nothing because the cache in question is not in your browser.
Check the authoritative answer and a few public resolvers. The authoritative server tells you the change is live; the public resolvers tell you how the world is experiencing it.
dig +short @$(dig +short NS example.com | head -1) example.com A # authoritative
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
printf "%-10s " "$r"; dig +short @$r example.com A
doneIf the authoritative answer is correct and the public resolvers are not, you are simply waiting. If the authoritative answer is wrong, you have edited the wrong zone — which happens more often than anyone admits, usually because the domain is served by a provider nobody remembered.
A frequently missed detail: "this name does not exist" is itself a cacheable answer, and the duration comes from the SOA record's minimum field rather than from any TTL you set on the record you just created.
So if you query a hostname before creating it, then create it, you may keep getting NXDOMAIN for a while — and no amount of re-checking will change that. Create the record first, then query. If you have already poisoned your own cache, query the authoritative server directly to confirm the record exists.
The sequence that avoids gaps has five steps: lower the TTL a day in advance; bring the new server into a fully working state and test it directly, bypassing DNS; change every record for the hostname at once; verify across resolvers; then keep the old server running until traffic has genuinely moved.
That last point is the safety net. For as long as the old machine answers, a rollback is a DNS change rather than a restore. Shutting it down the same day converts a five-minute recovery into an afternoon.
A hostname often has more records than you remember: A, AAAA, and sometimes a CNAME for www pointing at the apex. Changing only the A record leaves IPv6 clients — and certificate authorities, which tend to prefer IPv6 — talking to the old server.
The result is a site that works for most people, fails for some, and refuses to issue a certificate for reasons the error message never explains. Enumerate before you edit:
for t in A AAAA CNAME MX TXT CAA NS; do
printf "%-6s " "$t"; dig +short example.com $t | tr '\n' ' '; echo
doneMoving a website is not moving your mail, but they share a zone. When you migrate DNS to a new provider, the mail records must be recreated exactly — MX, plus the TXT records holding your sender policy and signing keys.
Miss one and outbound mail starts landing in spam folders while the website looks perfect. It is a slow, quiet failure: nobody reports the newsletter that silently went to junk. Copy the full zone before migrating, and compare it afterwards record by record.
A CAA record states which certificate authorities are permitted to issue for your domain. Compliant authorities check it and refuse if they are not listed.
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"It is a cheap, meaningful control: it narrows the set of parties who can mint a valid certificate for your name. The operational catch is that it also blocks you if you later switch providers and forget to update it, producing an issuance failure whose message rarely mentions CAA. If issuance suddenly fails after years of working, check this record.
DNSSEC signs DNS answers so a resolver can verify they were not tampered with. It defends against cache poisoning and answer forgery — genuine attacks with serious consequences.
The cost is operational. Signatures expire and must be refreshed. The chain of trust runs from the registry through a record at your registrar down to your zone, and if that chain breaks — a mismatched key after a provider migration, an expired signature — validating resolvers do not degrade gracefully. They return failure, and your domain becomes unreachable for a large portion of the internet while resolving perfectly for everyone else, which makes the diagnosis genuinely confusing.
Enable it if your provider handles signing and key rollover automatically. If you are moving DNS providers, disable it first, migrate, then re-enable — never carry a half-migrated chain.
A wildcard record answers for any name not otherwise defined. Convenient for multi-tenant applications where each customer gets a subdomain.
The blind spot: a wildcard only applies where no other record exists at that name. Define anything at all for a subdomain — a stray TXT record from a verification years ago — and the wildcard no longer answers its address queries. The subdomain stops resolving to your application, and the cause is a record that appears unrelated.
Health-checking DNS services will swap an address when a server stops responding. It sounds like automatic failover and behaves like something slower, because clients hold cached answers for the TTL and some intermediaries ignore short TTLs entirely.
Treat it as a way to shorten an outage rather than prevent one. If you need real failover, it belongs at a layer that does not depend on client-side caching — a load balancer or an anycast network in front of both servers.
Uptime monitoring checks whether your site responds. It will not tell you that a record was changed, that DNSSEC signatures are close to expiry, or that your nameservers disagree with each other.
A weekly automated comparison of the live zone against a known-good copy catches accidental deletions and unauthorised changes. Given that control of DNS is effectively control of the domain — including the ability to obtain certificates for it — that is a security control, not just an operational nicety.
Know which of the three roles you are changing: registrar, DNS host, or the nameserver delegation between them. Lower TTL a day before a planned change, because the TTL that governs a cutover was set long before it. Stop expecting propagation and start expecting expiry. Verify against the authoritative server and several public resolvers. Change every record for a hostname together — IPv6 included — or you will debug a certificate failure that has nothing to do with certificates. Preserve mail records when moving providers. Use CAA to narrow who may certify your domain, and remember to update it when you switch. Treat DNSSEC as valuable and unforgiving, particularly during migrations.