Domains & DNS

01Three different roles: registrar, nameservers, DNS hosting

These are often confused because one company can do all three. The registrar is where you buy and renew the domain (for example Namecheap, Porkbun or Cloudflare Registrar); it talks to the registry that runs the TLD, such as .com. In the registrar panel you set which nameservers are authoritative for your domain. The nameservers belong to a DNS host, and the DNS host is where your actual records live: A, CNAME, MX and so on. So you can buy a domain at one registrar, point its nameservers to Cloudflare, and manage all records in Cloudflare. If you edit records at the registrar while nameservers point elsewhere, nothing happens, which is a very common source of confusion. Analogy: the registrar is the land registry, the nameservers are the sign saying which office keeps the address book, and the DNS host is that office.

• Registrar: ownership, renewal, nameserver setting, WHOIS/RDAP contact, transfer lock.
• Nameservers: which DNS provider answers authoritatively for the domain.
• DNS hosting: the records themselves.

02How a lookup works

Your device asks a recursive resolver (your ISP, 1.1.1.1, 8.8.8.8). If the answer is not cached, the resolver asks a root server where .com lives, asks the .com servers which nameservers serve example.com, then asks those authoritative nameservers for the record. Each answer is cached for its TTL (time to live) in seconds. Next time, anyone using that resolver gets the cached answer instantly. This caching is why DNS scales to the whole internet, and also why changes are not visible everywhere at once.

1# Ask a specific resolver, then follow the whole chain
2dig example.com A @1.1.1.1
3dig +trace example.com
4# Which nameservers are authoritative?
5dig example.com NS +short
6# Ask the authoritative server directly (skips caches)
7dig example.com A @ns1.example-dns.net +short

03Record types you will actually use

A maps a name to an IPv4 address, AAAA to IPv6. CNAME makes one name an alias of another name; it cannot sit on the root domain (apex) next to other records, so providers offer ALIAS, ANAME or CNAME flattening for the apex. MX tells the world which servers receive email, with a priority (lower is tried first). TXT holds text, used for domain verification and email security: SPF lists who may send mail for you, DKIM publishes a signing key, DMARC says what receivers should do with mail that fails. NS delegates a zone, CAA limits which certificate authorities may issue certificates for your domain, and SRV describes services with a port. Each record has a name, a type, a value and a TTL.

1example.com.        300  IN A      203.0.113.10
2example.com.        300  IN AAAA   2001:db8::10
3www.example.com.    300  IN CNAME  example.com.
4example.com.        3600 IN MX     10 mail.example-mail.com.
5example.com.        3600 IN TXT    "v=spf1 include:_spf.example-mail.com -all"
6_dmarc.example.com. 3600 IN TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
7example.com.        3600 IN CAA    0 issue "letsencrypt.org"

04TTL and "propagation"

DNS does not really propagate; caches expire. If a record has a TTL of 86400 (one day), a resolver that cached the old value may keep using it for up to a day after you change it. Changing nameservers is slower still, because the delegation at the TLD level often has a TTL of a day or two. The practical recipe for a migration: lower the TTL to 300 seconds at least one old-TTL period before the switch, make the change, verify from several resolvers, and raise the TTL again after things are stable. Some resolvers also cache negative answers ("this name does not exist") according to the SOA record, so create records before you announce them.

• 300 s for records you might change soon; 3600 s or more for stable ones.
• Check from multiple resolvers, not only from your own laptop.
• Browser and OS caches can hold old answers; flush or test with dig.

05Checking records with dig and nslookup

dig is the standard tool on Linux and macOS; nslookup works everywhere, including Windows. Always check the authoritative answer as well as a public resolver, so you know whether the problem is your record or a cache. For email, check MX and the TXT records for SPF, DKIM (on a selector subdomain) and DMARC. For certificates, check CAA. Online tools that query from many countries help confirm that a change has reached most resolvers. The +short flag prints only the answer, which is handy in scripts and runbooks.

1dig +short example.com A
2dig +short www.example.com CNAME
3dig +short example.com MX
4dig +short example.com TXT
5dig +short selector1._domainkey.example.com TXT
6nslookup -type=MX example.com 8.8.8.8
7# Windows / PowerShell
8Resolve-DnsName example.com -Type A -Server 1.1.1.1

06Production tips

Treat the domain itself as critical infrastructure. Turn on auto-renew and registrar lock, use an account with two-factor authentication, and keep contact email on a mailbox you will still own in five years. Enable DNSSEC if your registrar and DNS host support it, so answers cannot be forged. Keep an exported copy of your zone file. Before moving nameservers, recreate every record at the new host first, especially MX and TXT, or email will silently break. Remove dangling records that point to services you no longer use, because they can be taken over by others.

07Delegation, glue records and the SOA

A zone is the part of the DNS tree one set of nameservers is responsible for. The .com zone does not hold your A record; it holds NS records that delegate example.com to your nameservers. If your nameservers live inside the same domain (ns1.example.com), there is a chicken-and-egg problem, so the parent zone also stores their IP addresses as glue records, set at the registrar. Every zone starts with an SOA record: the primary nameserver, a contact, a serial number that secondaries use to know when to transfer updates, and the negative-caching TTL. That last value controls how long resolvers remember that a name does not exist. A lame delegation happens when the parent points to nameservers that do not actually answer for the zone, which causes slow or failed lookups for some resolvers.

1# Delegation as seen by the .com servers
2dig example.com NS @a.gtld-servers.net +norecurse
3# SOA: primary NS, serial, refresh, retry, expire, negative TTL
4dig example.com SOA +short
5# A name that does not exist returns NXDOMAIN plus the SOA
6dig nothing-here.example.com A

08DNSSEC: signing the answers

Classic DNS has no way to prove that an answer is genuine, so a cache-poisoning attack could send users to a fake IP. DNSSEC adds signatures. Your DNS host signs every record set (RRSIG records) with a zone key published as a DNSKEY record. The parent zone holds a DS record, a hash of your key, which you add at the registrar. Validating resolvers follow the chain from the root's key, to .com, to your DS, to your DNSKEY, to the signature on the answer. If anything does not match, the resolver returns SERVFAIL instead of a forged answer. The operational risk is that a mismatch also breaks a legitimate domain: moving DNS hosts without removing or updating the DS record first takes the domain offline for every validating resolver. Managed providers handle key rotation; your job is the DS record.

1dig example.com DNSKEY +dnssec +short
2dig example.com DS +short          # what the parent publishes
3dig example.com A +dnssec          # look for the "ad" flag from a validating resolver
4# Online: dnsviz.net shows the full chain of trust

09Modern records: HTTPS/SVCB, CAA details and serve-stale

The HTTPS record (RFC 9460, a form of SVCB) lets a domain tell browsers, before connecting, which protocols it supports (for example h3 and h2), alternative ports, IP hints and keys for Encrypted Client Hello. It can also sit on the apex and point to another hostname, which solves part of the old apex-CNAME problem for browsers that support it. Cloudflare and other providers publish it automatically for proxied hostnames. CAA records can also carry iodef (where CAs report refused requests) and issuewild (which CA may issue wildcards). On the resolver side, many implementations follow serve-stale (RFC 8767): if your authoritative servers are unreachable, they may keep serving expired answers for a while. It helps availability during outages but means very short TTLs are never a guarantee of fast failover.

1dig example.com HTTPS +short
2# 1 . alpn="h3,h2" ipv4hint=203.0.113.10
3dig example.com CAA +short
4# 0 issue "letsencrypt.org"
5# 0 issuewild ";"          <- nobody may issue wildcards
6# 0 iodef "mailto:[email protected]"

10Security: takeovers, zone hygiene and anycast

A subdomain takeover happens when a record, usually a CNAME, points to a third-party resource you deleted, such as a cloud storage bucket, a PaaS app or a landing-page service. Someone else claims that resource name and now serves content on your subdomain, with your cookies in scope. Prevent it by deleting DNS records before or together with the resource, and by auditing the zone regularly. Other hygiene rules: never allow open zone transfers (AXFR) to anyone, avoid wildcard records unless you mean them, and keep internal hostnames out of public DNS because they reveal your network map. For resilience, good DNS providers use anycast: the same nameserver IP is announced from many locations, so queries go to the nearest healthy site and large floods are spread out.