Authoritative vs. recursive servers
Authoritative servers publish answers for your zone. Recursive resolvers (like 1.1.1.1) fetch answers on behalf of clients. Keep these roles separate: your authoritative servers should not perform recursion.
Learn
PacStac Stewardship
DNS Foundations
Domain Name System (DNS) is the phone book of the Internet. It converts human-friendly names into IP addresses. For PacStac, DNS provides a globally visible, tamper-resistant channel for publishing wallet proofs. Understanding the system—its history, moving parts, and operational quirks—helps you manage proofs confidently.
Origins & history
1969-1983
Host files and ARPANET
Before DNS, a single HOSTS.TXT file listed every known machine. Administrators emailed updates to the Stanford Network Information Center, which redistributed the file nightly. As networks scaled, this centralized workflow became brittle and error-prone.
1983
Inventing DNS
Paul Mockapetris authored RFCs 882/883 (later 1034/1035), introducing the Domain Name System. DNS replaced HOSTS.TXT with a hierarchical namespace, caching resolvers, and a protocol that could evolve without downtime.
1990s
Commercial Internet
Registrars, TLD operators, and enterprise name servers emerged. BIND became the reference implementation. Security incidents (cache poisoning, hijacks) drove best practices such as split-horizon DNS and secondary servers.
2000s
Anycast & modern resolvers
Public resolvers (Google Public DNS, Cloudflare, Quad9) adopted anycast for resilience. DNSSEC, EDNS0, and dynamic updates expanded the protocol while keeping backward compatibility.
Mindset for today
Use multiple authoritative servers
At least two name servers in different networks prevents a single outage from taking you offline. Many registrars provide secondary hosting; otherwise configure one manually or use Anycast services.
Treat TTL values as SLAs
Time To Live controls cache freshness. Low TTLs give agility but increase query volume. High TTLs lower cost but slow propagation. For stewardship proofs, 5–15 minutes strikes a good balance.
Keep change logs
Document every zone edit—who requested it, when it was applied, and the intended rollback plan. Pairing DNS changes with incident response runbooks prevents guesswork later.
Checklist: keeping DNS healthy
- • Monitor authoritative name servers for latency and NXDOMAIN spikes.
- • Automate zone backups before every change; keep at least 30 days of history.
- • Use infrastructure as code (Terraform, OctoDNS) or registrar APIs to avoid manual typos.
- • Validate DNSSEC if you use it—broken signatures cause more downtime than no DNSSEC.
Next steps
Continue with TXT records to learn how proofs are encoded, or skip to /.well-known for HTTP-based verification.