Domain & DNS Hub: From Resolution to Mail Authentication, Full Chain

# One wrong record costs you the whole site; one missing record costs you the inbox Domain pointing, record types, SSL automation, SPF/DKIM/DMARC — the full chain in one place, every step with a copyable verification command. DNS mistakes pay two prices: "site unreachable for everyone" or "every mail lands in spam". Ten systematic minutes beat both. ## Quick decision block - New domain + new server → the minimal viable resolution, three steps - Going HTTPS → the SSL automation section - Sending business mail → SPF/DKIM/DMARC trio, non-negotiable - Resolves but doesn't open → the four-layer troubleshoot chain ## Minimal viable resolution (three steps) 1. At the registrar, confirm NS records point at your DNS provider (or use the registrar's default DNS). 2. Add `A @ → server IPv4` and `A www → same IPv4`; add AAAA when IPv6 exists — on mobile networks IPv6 reachability directly affects open rates. 3. Wait out TTL (new records usually minutes; NS changes up to 24–48 h), verify with dig before touching anything downstream. ## Record type cheat sheet - **A / AAAA:** name → IPv4 / IPv6; the basic pointing. - **CNAME:** name → another name; CDN and object-storage onboarding. The apex (@) cannot CNAME — use ALIAS/ANAME or A records. - **MX:** mail receivers with priority (lower wins); required for mail flow. - **TXT:** free text carrying SPF, ownership proofs, and friends. - **NS:** which servers are authoritative for the zone. - **SRV / CAA:** service discovery (XMPP etc.) / which CAs may issue for the name. ## TTL and propagation TTL is how long each cache layer keeps a record, in seconds. Before a planned migration, drop TTL to 300–600 s one or two days ahead; cut over fast; raise back to 3600 s when stable. "Global propagation takes 48 hours" is true only for NS changes or stubborn carrier caches — A-record changes usually land in minutes. Verify with dig instead of waiting. ## SSL automation Use ACME (Let's Encrypt/ZeroSSL): certbot, acme.sh or one-click panel issuance with 60–90 day auto-renewal. Three gotchas: the A record must be live before issuance; DNS-01 validation unlocks wildcard certs and tolerates an unready server; and the renewal job needs monitoring — expired certificates remain a low-skill, high-frequency outage class. ## Mail authentication trio (SPF / DKIM / DMARC) - **SPF:** a TXT record declaring which servers may send for your domain, e.g. `v=spf1 include:_spf.mx.example.com -all`. - **DKIM:** private key signs mail; the public key publishes in TXT; receivers verify integrity. - **DMARC:** tells receivers what to do on SPF/DKIM failure — start `p=none` and read reports, then tighten to quarantine/reject. Miss one and business mail gambles with the spam folder. Corporate mail providers publish the exact record values; copy them into your DNS panel verbatim. ## DNS security Enable DNSSEC against resolution hijack. At the registrar: 2FA and registrar lock, always — domain theft is the most expensive incident class, recovery measured in weeks. Behind a CDN, never let DNS expose the origin IP (historical records leak; when changing origin, consider changing IP). ## DNS performance: the invisible hop before first byte Before any connection, a first-time visitor resolves your name: on a local-cache miss the resolver may walk root → TLD → authoritative, and transoceanic that hop alone costs a hundred-plus milliseconds. Three levers: **long TTLs** on stable records (3600 s+; let caches work), **fewer distinct domains** per page (every third-party name adds resolution), and **pre-resolution hints** (`dns-prefetch`/`preconnect`) for critical origins. Quantify your own dns time with `curl -w`'s dns field (method in the diagnostics hub). ## Disaster-ready resolution architecture DNS is where single-point risk concentrates — when resolution dies, every redundancy behind it dies with it. Three practices: **two or more authoritative providers** (NS records at different operators; one failure, the other serves); **add-before-delete for changes** (verify the new record live, then remove the old — always keep a rollback path); **archive the record set** (export after every change; incidents then become minutes of checklist work, not hours of memory archaeology). ## Certificates and domains: three edge cases - **Wildcard certs:** one `*.example.com` covers all subdomains but requires DNS-01 validation; wildcards do NOT cover the apex — list `example.com` separately. - **SAN certs:** bundle www, api, admin-style names in one certificate; manage the name list deliberately, each addition is a re-issuance. - **Apex-vs-www canonical:** pick one, 301 the other, and keep cookies/CDN rules aligned — the choice belongs with the SEO canonical, not with DNS aesthetics.