DNSSEC Validation

Navigation: DNS Security → DNSSEC Validation

DNSSEC proves that a DNS answer was published by the zone owner and was not altered in transit. TOORCE validates the chain from the root trust anchor down to the requested name, then records the result on every log line.

What is validated

Record / object	Purpose
RRSIG	Digital signature over an RRset (A, AAAA, MX, TXT, and others)
DNSKEY	Zone signing keys (ZSK) and key-signing keys (KSK) at the zone apex
DS	Delegation signer in the parent zone; hashes the child KSK
Root trust anchor	IANA root KSK used as the start of the authentication chain

TOORCE supports automatic root trust-anchor and KSK rollover so the appliance follows published root-key changes without a manual file replace on every rollover.

Validation outcomes

`dnssec` value	Meaning	Typical action
secure	Chain of trust is complete and signatures verify	Allow (subject to other engines)
insecure	Zone is unsigned or the chain stops at an insecure delegation	Allow or apply a stricter policy if you require DNSSEC
unsigned	No DNSSEC data for this name (logged form of insecure)	Same as insecure
bogus	Signatures fail, data is missing, or the chain is broken	Block (recommended)
indeterminate	Validator could not complete the check (timeout, SERVFAIL upstream)	Retry / fail closed per policy

Example of a secure allow:

{
  "src_ip": "192.168.1.50",
  "domain": "example.com",
  "qtype": "A",
  "dnssec": "secure",
  "category": "business",
  "reputation": "clean",
  "action": "allow"
}

Recommended policy

Setting	Recommended	Notes
Enable DNSSEC validation	On	Applies to recursive answers TOORCE fetches or forwards
Action on bogus	Block	A failed signature is treated as untrusted data
Action on unsigned	Allow	Most public names are still unsigned; blocking them breaks browsing
Root trust-anchor rollover	Automatic	Follows the current IANA root KSK
Local unsigned zones	Exempt	`corp.local` and AD zones are typically unsigned — do not require DNSSEC

How the chain of trust works

Root trust anchor (KSK)
   →  DS in root  →  TLD DNSKEY (e.g. .com)
   →  DS in TLD   →  zone DNSKEY (example.com)
   →  RRSIG over the A/AAAA (or other) RRset

If any hop is missing or the signature does not match, the answer is bogus. If the parent publishes no DS for the child, the name is insecure / unsigned.

Local and Active Directory zones

Internal zones on AD DNS or BIND are usually not DNSSEC-signed. Configure those suffixes as local / private zones so TOORCE: