DNS Records Explained: A, CNAME, TXT, Email Security & DNS over HTTPS

The Domain Name System (DNS) is a globally distributed, hierarchical database responsible for translating human-memorable hostnames (devutils.run) into machine-routable IP addresses. When a client initiates a domain lookup, the resolution traverses four distinct infrastructure tiers:

1. Recursive Resolver: Maintained by ISPs or public providers like Cloudflare (1.1.1.1) or Google (8.8.8.8). The resolver handles the recursive querying burden on behalf of the stub client and caches answers according to TTL (Time to Live) values.
2. Root Nameservers: 13 logical root server clusters operated worldwide that direct queries to the appropriate Top-Level Domain (TLD) nameservers based on the domain suffix (.run, .com).
3. TLD Nameservers: Managed by domain registries, directing queries to the authoritative nameserver responsible for the specific domain zone.
4. Authoritative Nameservers: The final authority holding the verified DNS record sets configured by the domain owner.

• A Record: Maps a hostname directly to a 32-bit IPv4 address (192.0.2.1).
• AAAA Record: Maps a hostname to a modern 128-bit IPv6 address (2001:db8::1).
• CNAME (Canonical Name): Aliases one domain name to another canonical hostname. Under original RFC specs, CNAME records cannot coexist with other records on the zone apex (root domain), giving rise to modern DNS provider features like CNAME Flattening / ANAME.
• MX (Mail Exchange): Specifies the priority-weighted hostnames of mail servers responsible for accepting incoming email for the domain.
• TXT (Text): Stores arbitrary machine-readable strings, vital for domain ownership verification and email security authentication.
• CAA (Certification Authority Authorization): Specifies which Certificate Authorities (such as Let's Encrypt) are authorized to issue SSL/TLS certificates for the domain, preventing fraudulent issuance.

The core email transmission protocol (SMTP) lacks native source address validation, allowing attackers to forge the sender From: header easily. Modern domain defense mandates the configuration of three complementary DNS TXT records:

1. SPF (Sender Policy Framework): A TXT record enumerating all authorized IP addresses and third-party mail relays permitted to dispatch emails using your domain.
2. DKIM (DomainKeys Identified Mail): The sending mail server attaches an asymmetric cryptographic digital signature to email headers. Recipient servers fetch the public key from the sender's DNS TXT record (selector._domainkey) to verify tamper-evidence.
3. DMARC (Domain-based Message Authentication, Reporting, and Conformance): Instructs recipient mail systems on how to handle messages that fail SPF or DKIM checks (none, quarantine, reject) and specifies reporting endpoints for threat analysis.

// Sample SPF Record (TXT @)
v=spf1 include:_spf.google.com ~all

// Sample DMARC Enforcement Policy Record (TXT _dmarc)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@devutils.run; pct=100; adkim=s; aspf=s

Traditional DNS lookups operate over unencrypted UDP port 53 in cleartext. This fundamental architecture allowed local Wi-Fi operators, ISPs, and eavesdroppers to monitor every domain visited by a client and execute DNS spoofing / cache poisoning attacks.

• DoT (DNS over TLS): Standardized under RFC 7858, DoT wraps standard DNS queries inside an encrypted TLS session on dedicated port 853.
• DoH (DNS over HTTPS): Standardized under RFC 8484, DoH encapsulates DNS queries inside HTTP/2 or HTTP/3 HTTPS requests over standard web port 443. Because DoH traffic is multiplexed alongside ordinary encrypted web traffic, it prevents ISP packet snooping and tampering without requiring specialized ports.

DNS performance, global latency, and high availability hinge upon strategic Time to Live (TTL) tuning:

• Low TTL (60–300s): Essential during planned data center migrations, Blue-Green deployments, and dynamic failover routing. The operational trade-off is increased query volume to authoritative nameservers.
• High TTL (86400s / 24h): Ideal for static records like MX, SPF, and stable infrastructure. Maximizes recursive resolver cache hit ratios, reducing DNS lookup latency for clients.
• Negative Caching (SOA MINIMUM): Governs how long recursive resolvers cache NXDOMAIN (non-existent domain) answers. Pointing a service to a domain before creating its DNS record can cause resolvers to cache the failure, prolonging perceived downtime.
• Debugging with dig: Always query the authoritative nameserver directly or run dig +trace devutils.run to trace each delegation step from root servers to authoritative endpoints.

# Trace the complete DNS resolution delegation hierarchy
dig +trace devutils.run A

# Query Cloudflare 1.1.1.1 directly bypassing local OS cache
dig @1.1.1.1 devutils.run A +short