SpeedDrain
BIND Zone File · Email Auth (SPF/DKIM/DMARC) · Dig CLI

DNS Record Explainer & Generator

Construct and validate DNS zone records. Generate syntax-accurate BIND files for web hosting, nameserver delegation, and email authentication standards.

Recommended Production Presets:

A Record (IPv4 Address)

Spec: RFC 1035

BIND / Standard Zone File Record
example.com. 3600 IN A 198.51.100.42
Verify with CLI (dig terminal command):
dig +nocmd example.com A +multiline +noall +answer

Field-by-Field Breakdown

Maps a hostname directly to a 32-bit IPv4 address.

Host:@ represents root domain, or subdomain prefix (e.g. "api").
TTL:Time To Live in seconds for recursive resolver caching.
Class:IN (Internet class - universal for web DNS).
Target:Valid public IPv4 address (e.g. 198.51.100.42).

DNS Architecture, Propagation & Email Authentication Guide

01.How DNS Resolution & Propagation Works

When a user navigates to your website, their browser initiates a hierarchical lookup query across four distinct server types:

  1. Recursive Resolver: Operated by the user's ISP or public DNS (e.g., 1.1.1.1, 8.8.8.8). Checks local cache before querying.
  2. Root Nameservers: 13 global IP clusters directing queries to appropriate Top-Level Domain (TLD) servers (.com, .org).
  3. TLD Nameservers: Direct the resolver to the authoritative nameservers for your specific domain name.
  4. Authoritative Nameservers: The ultimate source of truth hosting your zone file (e.g. Cloudflare, Route 53).

"Propagation delay" is simply the time it takes for cached records across millions of global recursive resolvers to expire based on your previous TTL.

02.The Email Deliverability Trifecta: SPF, DKIM & DMARC

Modern inbox providers (Gmail, Microsoft 365, Yahoo) strictly require all three authentication protocols to prevent spoofing and domain impersonation:

  • SPF (Sender Policy Framework): A TXT record listing all IP addresses and third-party SaaS services permitted to send emails from your domain (v=spf1 include:_spf.google.com ~all).
  • DKIM (DomainKeys Identified Mail): Adds a cryptographic signature to outbound email headers. Receiving servers verify this signature against your public key published in DNS.
  • DMARC: Bridges SPF and DKIM. Instructs receiving servers what to do with failing emails: p=none (monitor), p=quarantine (spam folder), or p=reject (drop email completely).

03.Understanding TTL (Time To Live) Values

TTL dictates how many seconds intermediate DNS resolvers may cache a record before querying authoritative nameservers again:

  • 300 seconds (5 min): Ideal when planning server migrations or maintenance. Lower your TTL 24–48 hours before an IP change to ensure instant failover.
  • 3600 seconds (1 hour): Standard recommended default for production web applications balancing caching performance with flexibility.
  • 86400 seconds (24 hours): Appropriate for stable infrastructure such as authoritative NS records or MX hostnames that rarely change.

04.The CNAME Apex Restriction & CNAME Flattening

Per RFC 1035 §3.6.2, a CNAME record cannot coexist with any other record type for the same hostname. Because the zone apex (example.com) must possess SOA and NS records, placing a standard CNAME at the apex violates RFC specifications and breaks email MX lookups.

Modern managed DNS providers solve this with CNAME Flattening (or ALIAS / ANAME records): the provider automatically resolves the target CNAME to its underlying A and AAAA IP addresses and returns standard IP responses directly at the root.