1. DNSSEC Fundamentals: Cryptographic Chain of Trust
Legacy DNS infrastructure lacks built-in source origin authentication. This structural design permits network-level attackers to perform cache poisoning attacks (such as DNS Cache Poisoning / Kaminsky Attacks) and execute Man-in-the-Middle (MitM) interceptions.
DNSSEC (Domain Name System Security Extensions - RFC 4033/4034/4035) integrates asymmetric digital signatures into DNS responses. It guarantees origin authenticity and data integrity by verifying a continuous cryptographic chain starting from Root Trust Anchors (.) down to a target domain's authoritative zone.
2. Core Cryptographic Resource Records: DS, DNSKEY, and RRSIG
For DNSSEC validation to function, a signed DNS zone publishes and maintains three primary cryptographic record types:
| DNS Record | Publication Location | Cryptographic Role |
|---|---|---|
| DNSKEY | Domain Authoritative Zone | Stores the public Key Signing Key (KSK) and Zone Signing Key (ZSK) used to verify signatures across the zone. |
| DS (Delegation Signer) | Parent TLD Zone (.com, .org, .net) | Contains the SHA-256 hash digest of the child KSK. Binds the parent zone to the child zone in the global chain of trust. |
| RRSIG | Attached to each signed RRSet | Digital signature generated by the private ZSK covering the validity of target record sets (A, MX, TXT, CNAME). |
3. Anti-Downgrade TLS Protection via DANE (RFC 6698)
In server-to-server SMTP transactions (port 25), TLS encryption is negotiated via the opportunistic STARTTLS extension. An active network attacker can manipulate early handshake banners and strip 250-STARTTLS strings (a STRIPTLS downgrade attack), causing sending MTAs to transmit mail in unencrypted cleartext.
DANE (DNS-based Authentication of Named Entities - RFC 6698) eliminates this flaw by publishing binding X.509 certificate hashes inside DNSSEC-validated records. When a sending MTA detects a valid TLSA record, it strictly refuses cleartext delivery and validates the destination server's certificate against the published digest.
4. TLSA Record Syntax & Parameters for MX Hosts
TLSA records are published at labels derived from the target port and transport layer (_port._proto.hostname). For an MX mail server listening on port 25:
- Certificate Usage (3): DANE-EE (Domain Issued Certificate). Binds directly to the server certificate leaf, bypassing third-party Certificate Authority (CA) trust stores.
- Selector (1): SubjectPublicKeyInfo. Extracts and hashes strictly the RSA/ECC public key material, preserving validity during routine certificate renewals.
- Matching Type (1): SHA-256 cryptographic digest.
5. CLI Verification via `dig` and `openssl`
Verify DNSSEC chain validation and TLSA record presence using command-line tools: