DNSSEC and DNS Security

When a resolver receives an A record, a public key, and a signature, and the signature verification succeeds, the result still cannot be immediately trusted: an attacker can also generate their own keys and sign their own fake addresses. The key to DNSSEC is connecting the signing key of the target RRset to a trust anchor already trusted on the local machine, and then determining whether the signature, negative proof, and validity period are all valid.

Security Goals: Authenticate RRsets, Do Not Guarantee Business Goodwill

DNSSEC provides DNS data source authentication, integrity, and authenticated denial of existence. The basic object of signing is the RRset, not signing each RR independently, nor signing the entire response packet containing ID, Flags, and arbitrary additional data uniformly. A cache or another authoritative server can deliver the same signed data; verification does not require connecting to a specific physical server. RFC 4033: Capabilities and Boundaries

It does not encrypt names, addresses, or query times, does not guarantee service availability, and does not prove that the domain operator is not malicious. An incorrectly signed erroneous A record by the domain owner is still an authenticated misconfiguration; compromise of the private key or registrar account is also beyond the capability of "preventing man-in-the-middle tampering."

Traditional DNS random transaction IDs, source ports, response correlation, and cache admission checks can increase the difficulty of forgery, but they are not cryptographic source authentication. DNSSEC complements these checks; enabling it does not allow the cancellation of all resolver protections.

What Each of the Four Record Types Does

RRSIG contains the Original TTL because TTLs in cache forwarding are decremented; canonicalized signature verification requires using the specified original values, name forms, and ordering. The Key Tag is a short identifier for filtering candidate keys; collisions are possible and it cannot be treated as a cryptographic fingerprint. RFC 4034: Record Formats and Canonicalization

The DS digest input is the concatenation of the wire-format encoding of the canonicalized owner name and the DNSKEY RDATA, which contains Flags, Protocol, Algorithm, and public key bytes; one cannot hash only the public key, nor even the Base64 text used for display. The digest algorithm is determined by the Digest Type, not all DS records are fixed to SHA-256.

Trust Chain: Do Not Omit Child Zone Keyset Verification

A trust anchor can be represented as pre-trusted DNSKEY or DS-type information. Deployment can establish a global chain from the root, or trust anchors from other zones can be configured; it is not fixed to "a hash of the root DNSKEY." Taking the example from the root to the target zone, repeatedly execute parent zone DS verification, child zone DNSKEY digest matching, and child zone DNSKEY RRset verification, and finally verify the target records.

Directly verifying the signature of A after downloading the child zone DNSKEY only proves that "the private key corresponding to this public key signed it." One must first prove that the public key used has trusted authorization before concluding a secure result. The DS saved in the parent zone is signed by the parent zone, and the child zone DNSKEY RRset is signed by the corresponding child zone key; the responsibilities of the two cannot be reversed. RFC 4035: Verification Process

"Receiving no DS" does not equal having obtained a reliable proof of "DS does not exist"; the former could also be timeout, truncation, or filtering. Similarly, an isolated signed zone that is not connected to an existing trust anchor cannot claim that the entire internet will verify it just because it has an RRSIG.

TTL, Signature Time, and Clocks

If an RRset with TTL=3600 s is received, but the signature expires in only 900 s, even if the signature is currently valid, the verified cache cannot unconditionally be used for another 3600 s. The effective cache lifetime is also constrained by RRSIG TTL, Original TTL, and remaining signature time. RFC 4035: Authenticated Caching

Signature Inception/Expiration are absolute validity intervals, while TTL is the relative cache lifetime; the two cannot reset each other by continuously re-fetching. Early re-signing and reasonable time synchronization affect availability; significant local clock offset can cause multiple normally valid zones to simultaneously appear as signatures not yet effective or expired.

Why is it not Secure if the Signature Verifies?

Keep the target signature correct for now, and separately remove DS matching or keyset verification. Without establishing a trusted path in the last block, it cannot become Secure. Move the time to before expiration; the lifespan is compressed by the remaining signature time; at t=2900, the time condition can still pass, but the cache lifespan upper limit is already zero; only later does it exceed the signature validity period.

KSK, ZSK, and Rollover: Roles Are Not Fixed Algorithm Levels

KSK usually signs the DNSKEY RRset, and ZSK usually signs other authoritative RRsets in the zone; a combined signing key can also be used. The Zone Key mask for DNSKEY is 0x0100, and SEP is 0x0001, leading to common flags=256/257. SEP is a role hint and cannot be treated as a cryptographic permission limit that "this key can only sign DNSKEY."

No protocol stipulates that KSK is always 2048-bit RSA, ZSK is always 1024-bit, or that they must be changed annually/monthly. Key algorithm, signature refresh, and key replacement are different choices: the same key can be re-signed multiple times; a signature nearing expiration does not mean the key must be replaced simultaneously. RFC 6781: DNSSEC Operations

Rollover must consider that old DNSKEY, old DS, and old signatures may still be in different caches. The general approach is to reserve publication and cache propagation time for the new key, allow necessary combinations to verify during the overlap period, and then retire old materials according to the corresponding rollover plan. It cannot be generalized to "delete old key first, then upload new DS"; this would prevent validators still trusting the old DS from matching the child zone key.

Changes to parent zone DS and actual responses from each authoritative node should be recorded, rather than just looking at the management backend showing success. The retirement waiting time is determined by relevant TTLs, signature validity periods, and the plan; this article does not fabricate a fixed hourly table applicable to all operators.

NSEC/NSEC3: Providing Checkable Basis for Negative Answers

Assume the existing names adjacent in DNS specification name order in the zone are a.example. and c.example.. A signed NSEC linking these two names can help prove that there is no b.example. between them. For NODATA where the name exists but a certain type does not, the type bitmap provides different proof information.

This is just interval intuition; complete NXDOMAIN requires correct handling of closest encloser, wildcards, and other conditions; one cannot simply find a string lexicographical interval and declare the proof complete. NSEC uses DNS name specification order, not the default string sorting of any arbitrary language.

NSEC3 hashes canonical names to form corresponding intervals, increasing the cost of reading names directly from the chain, but short, common names may still be guessed via dictionary attacks. Opt-Out allows corresponding unsigned delegations to not enter the hash chain item by item, having specific proof boundaries; it is not a switch for arbitrary record exemption from signing. RFC 5155: NSEC3

Higher iteration counts increase verification workload and cannot be treated as a universal tuning item where "larger is safer." RFC 9276 recommends NSEC3 use zero extra iterations and empty salt settings; parameters still need to be selected based on the support of the signature/verification software used and verification costs. RFC 9276: NSEC3 Parameters

DO, AD, CD: Catching Flags Does Not Equal Self-Verification

The DO bit expresses the capability/requirement for DNSSEC data related to the request; dig +dnssec can display RRSIGs, but this does not automatically make it a complete local validator. AD is the resolver's declaration of authentication status; clients can only accept it according to policy if they trust the resolver and the path to it has corresponding protection. CD requests disable corresponding checks, used to contrast issues, and does not make data trustworthy.

One can separately observe authoritative original records, recursive server results, and local validator detailed diagnostics. When SERVFAIL occurs, it could also be network failure, truncation handling, or resource limits; one cannot assert it is definitely a DNSSEC failure; Extended DNS Errors can supplement reasons, but not every response has them, and they cannot replace one's own trust judgment. RFC 8914: EDE

DANE: Determining TLS Trust Rules Based on Usage

The owner of TLSA usually contains port and transport protocol, e.g., _443._tcp.example.com.; RDATA contains certificate usage, selector, matching type, and associated data. The selector distinguishes between the full certificate and SubjectPublicKeyInfo, and the matching type distinguishes between plaintext matching and digest matching. RFC 6698: TLSA

Therefore, DANE does not uniformly equate to "no longer needing any PKI checks." Applications must also correctly bind the service name, obtain Secure TLSA, and complete TLS's proof of possession of the corresponding private key and the rules for that usage. Simple hash matching is insufficient, and usage=3 cannot be detached from requirements to be claimed as "maximum security."

DANE already has SMTP application specifications; one cannot claim zero adoption rate just because general browser support is limited. How to discover MX, determine TLSA availability, and handle failures in SMTP are supplemented by email scenario specifications. RFC 7672: SMTP DANE

Local Recalculation: DS Digest Input and Time Constraints

import hashlib
import struct

def owner_wire(name):
    return b''.join(bytes([len(x)])+x.encode('ascii')
                    for x in name.rstrip('.').lower().split('.'))+bytes(1)

# Teaching byte string simulation of 32 B public key field; no private key or real signature generated.
public_bytes = bytes(range(32))
rdata = struct.pack('!HBB',257,3,15)+public_bytes
owner = owner_wire('Example.COM.')
digest = hashlib.sha256(owner+rdata).digest()
assert len(digest)==32
assert digest == hashlib.sha256(owner_wire('example.com.')+rdata).digest()
assert digest != hashlib.sha256(public_bytes).digest()
assert digest != hashlib.sha256(owner_wire('other.example.')+rdata).digest()
changed_flags = struct.pack('!HBB',256,3,15)+public_bytes
assert digest != hashlib.sha256(owner+changed_flags).digest()
assert 257&0x100 and 257&1
assert 256&0x100 and not 256&1
# Teaching values not crossing time sequence wraparound; complete verification has other checks.
now,inception,expiration = 2000,1000,2900
def signature_time_valid(at):
    return inception <= at <= expiration
assert signature_time_valid(now)
assert signature_time_valid(expiration)
assert not signature_time_valid(expiration + 1)
assert min(3600,3600,3600,expiration-now)==900
assert min(3600, 3600, 3600, expiration - expiration) == 0
assert not signature_time_valid(3000)
print('DS input includes owner/flags, public key encoding differences, flags, and validity period constraint checks passed')

The example only verifies encoding dependencies and time budgets; it does not perform RRSIG cryptographic verification or build a real trust chain; no DNSKEY/DS publication, production key rollover, or resolver policy adjustment is done.

Continue Reading

• DNS Protocol and Resolution: Delegation, RRset, TTL, and EDNS.
• DNS Privacy: Transport confidentiality and resolver trust.
• Certificates and PKI: TLS identity verification and certificate chains.