Model inputs
This calculator estimates outcomes from your entries and does not perform live DNS queries.
Example data table
These scenarios show typical configurations and the expected modeled outcome.
| Scenario | DS at parent | DNSKEY | RRSIG | Algorithm | Key bits | Timing window | Expected status |
|---|---|---|---|---|---|---|---|
| Enterprise zone, healthy | Yes | Yes | Yes | ECDSA P-256 | 256 | Valid, 21 days remaining | Secure |
| Signed zone, DS missing | No | Yes | Yes | RSA/SHA-256 | 2048 | Valid, 10 days remaining | Insecure |
| Broken chain, missing DNSKEY | Yes | No | Yes | RSA/SHA-256 | 2048 | Unknown | Bogus |
| Expired signatures | Yes | Yes | Yes | Ed25519 | 256 | Expired 2 days ago | Bogus |
| Missing inputs | — | — | — | — | — | — | Indeterminate |
Formula used
The calculator models common resolver outcomes using DNSSEC building blocks: delegation signals (DS), zone keys (DNSKEY), and signatures (RRSIG), plus signature timing windows (inception/expiration) evaluated with a user-defined clock skew.
Modeled status rules
- Secure: DS is present, DNSKEY and RRSIG are present, and (if timing is provided) the signature window is valid.
- Insecure: DS is not present at the parent, meaning validators treat the delegation as unsigned.
- Bogus: DS is present but required data is missing, inconsistent, or signatures appear invalid/expired.
- Indeterminate: domain format or required inputs are not usable.
Risk score
A weighted risk score (0–100) is computed by adding penalties for issues, then clamping to the 0–100 range. Confidence is calculated as 100 − risk.
| Condition | Penalty |
|---|---|
| No DS at parent | +35 |
| No DNSKEY | +30 |
| No RRSIG | +25 |
| Expired signature (when timing supplied) | +35 |
| Inception in the future (when timing supplied) | +20 |
| RSA key < 2048 bits | +15 |
| RSA key < 1024 bits | +30 |
| NSEC3 iterations > 500 | +5 |
| NSEC3 iterations > 1500 | +10 |
| Rollover interval > 365 days | +6 |
| Clock skew tolerance > 30 minutes | +15 |
This scoring is a practical heuristic for auditing readiness; real validators also evaluate cryptographic verification, DS matching, and complete chain-of-trust behavior.
How to use this calculator
- Enter your domain and indicate whether DS, DNSKEY, and RRSIG are present.
- Select your signing algorithm and key size, matching your current deployment.
- Optionally add signature inception/expiration and set clock skew tolerance.
- Choose NSEC or NSEC3 settings, then provide rollover cadence details.
- Press Submit to view status, risk score, and tips above the form.
- Use Download CSV or Download PDF to export results.
For operational decisions, confirm results with a validating resolver and authoritative records from your DNS operator.
Validation inputs this tool models
DNSSEC status is driven by three record types: DS at the parent zone, DNSKEY at the child zone, and RRSIG signatures over the relevant RRsets. The calculator treats missing DS as a broken chain, because a validator cannot build trust from the root to your domain. When DS, DNSKEY, and RRSIG are present, the page assumes a complete chain and focuses on operational details that commonly cause intermittent failures.
Risk scoring and weighting
The risk score is a weighted heuristic from 0 to 100. Higher weight is assigned to chain-of-trust signals, because one missing link turns validation into hard failure. Medium weight is assigned to timing, since expired signatures are a frequent cause of sudden outages after an otherwise stable deployment. Lower weight covers denial-of-existence choice and rollover cadence, which typically degrade resilience before they fully break validation.
Algorithm and key size assumptions
The form lets you choose widely deployed signing families: RSA/SHA-256, ECDSA P-256, ECDSA P-384, and Ed25519. As a practical baseline, many operators use 2048-bit RSA for a KSK and 1024–2048-bit RSA for a ZSK, while elliptic-curve options offer smaller responses and faster verification. The calculator flags very small keys or uncommon selections as higher risk, especially when combined with frequent key rotation.
Signature timing and clock skew
Validation depends on a resolver clock that is “close enough” to real time. Typical RRSIG validity windows range from 7 to 30 days, with rollovers staged so that new signatures overlap old ones. This page uses your inception, expiration, and skew tolerance to estimate whether a validator could see “not yet valid” or “expired” failures during propagation, VM snapshots, or NTP drift incidents.
Rollover and denial-of-existence signals
NSEC is straightforward and produces predictable proof sizes, while NSEC3 adds hashing and optional opt-out behavior for some delegations. Excessive NSEC3 iterations can increase resolver work and enlarge latency under load, so modern guidance favors low iteration counts. The calculator combines your KSK/ZSK cadence with NSEC or NSEC3 choices to highlight periods where caches, DS updates, and signature lifetimes may not overlap cleanly. Document key IDs, signers, and contact paths for incidents.
FAQs
Does this page perform live DNS lookups?
No. It evaluates the values you enter and produces a modeled validation status. To verify live records, query authoritative servers and a validating resolver using standard DNS diagnostic tools.
What does “Partially Validated” mean here?
It indicates that some trust signals are present, but one or more critical elements are missing or risky, such as an absent DS record, weak timing overlap, or aggressive rollover settings that reduce resilience.
Which signing algorithm should I choose?
Pick the algorithm your zone actually uses. RSA/SHA-256 remains common, while ECDSA and Ed25519 reduce response size and speed verification. Ensure your parent, registrar, and DNS provider support the choice end to end.
How should I set signature validity and skew?
Use overlapping RRSIG windows that cover propagation and outages. Many operators use 7–30 day validity and allow small skew for clock drift. Short windows require tighter automation and monitoring to avoid expiry.
When should I use NSEC3 instead of NSEC?
Use NSEC3 only when you need hashed denial-of-existence. Prefer low iteration counts to avoid extra resolver work. If zone enumeration is not a concern, NSEC is simpler and often more reliable operationally.
Why do exports show a risk score rather than pass/fail only?
Pass/fail is useful, but it hides near-miss conditions. The score helps compare configurations, prioritize fixes, and document improvements over time, especially around rollovers, timing overlap, and chain-of-trust completeness.