DNSSEC Audit API: Check Domain Signing Status from WHOIS JSON

Introduction

DNSSEC protects resolvers from forged DNS answers by building a chain of trust from the parent zone to your records. For security and platform teams, the operational question is rarely “what is DNSSEC?” — it is “which of our domains claim to be signed, and which critical ones are still unsigned?”

WhoisJSON returns that registry-side signal in the dnssec field of the WHOIS API response. Values such as signedDelegation and unsigned are enough to drive portfolio audits, migration checklists and compliance reports — if you treat them as status evidence, not as a finished cryptographic proof.

This article is intentionally narrower than the complete WHOIS JSON field reference. It focuses on DNSSEC audit workflows: policy tiers, bulk scoring, false positives, and how DNSSEC differs from CAA and SSL certificate controls.

The Right Mental Model

A useful DNSSEC program has three layers. Mixing them up creates noisy alerts or false confidence.

Layer	Question	WhoisJSON role
Registry / WHOIS status	Does the parent show a signed (or unsigned) delegation?	`dnssec` on `/api/v1/whois`
Live DNS configuration	Are NS/SOA consistent with the expected DNS provider?	NS lookup +SOA lookup
Cryptographic validation	Do resolvers validate DS → DNSKEY → RRSIG end-to-end?	Out of scope — use validating resolvers or dedicated DNSSEC tools

Do not equate signedDelegation with “DNSSEC is healthy.” It means the registry advertises a signed delegation. Broken keys, missing RRSIG coverage or resolver failures need separate validation.

DNSSEC vs CAA vs SSL

These controls are complementary. Auditing one does not replace the others.

Control	Protects against	Primary signal in WhoisJSON
DNSSEC	Forged or tampered DNS answers (when validation succeeds)	WHOIS `dnssec`
CAA	Unauthorized public CA certificate issuance	DNS `CAA` via `/nslookup`
SSL/TLS cert	Expired, replaced or untrusted HTTPS certificates	`/ssl-cert-check`

Audit tip: for login and payment hostnames, require DNSSEC where policy mandates it,and CAA + SSL monitoring. They fail for different reasons.

Reading the `dnssec` Field

QueryGET /api/v1/whois?domain=example.com with Authorization: TOKEN=YOUR_API_KEY. Normalize the string before comparing (case and spacing can vary by source).

RequestcURL

curl "https://whoisjson.com/api/v1/whois?domain=example.com" \
  -H "Authorization: TOKEN=YOUR_API_KEY"

ExcerptJSON

{
  "name": "example.com",
  "nameserver": ["a.iana-servers.net", "b.iana-servers.net"],
  "dnssec": "unsigned"
}

Typical value	Audit interpretation
`signedDelegation`	Registry indicates a signed delegation — pass for “must be signed” assets if live DNS also matches policy
`unsigned`	No DNSSEC at registry — fail for critical tiers, acceptable for low-risk marketing domains if documented
`unsigned delegation`	Treat like unsigned for scoring; log the raw string for evidence
Empty / absent	Unknown — retry, check `source`, do not invent a status

Portfolio Policy Tiers

Not every domain needs DNSSEC on day one. Define tiers so unsigned marketing microsites do not drown out unsigned SSO domains.

Tier 0 — Critical

Apex login, API, payment, IdP and email-sending domains. Require signedDelegation.

Tier 1 — Production web

Customer-facing sites. Prefer signed; warn if unsigned for more than N days after migration.

Tier 2 — Brand / redirect

Parked brand domains. Optional DNSSEC; still monitor NS and transfer locks.

Tier 3 — Experimental

Labs and short-lived campaigns. Track status, do not page on unsigned alone.

Store the expected tier next to each domain in your inventory (see domain inventory). The audit job only compares WHOIS dnssec to that baseline.

Audit Workflow

Export the domain list with tier and owner.
Call /whois for each domain (bounded concurrency).
Normalize dnssec → signed, unsigned, or unknown.
Emit findings only when status violates the tier policy.
On mismatches, enrich with NS/SOA to see if a DNS migration is in flight.
Escalate persistent Tier 0 failures; ticket Tier 1 warnings.

Propagation window: after enabling DNSSEC at the DNS provider and publishing DS records, registry status can lag. Allow a documented grace period before failing a migration ticket.

Python: Portfolio DNSSEC Audit

dnssec_audit.pyPython

import re
import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://whoisjson.com/api/v1"
HEADERS = {"Authorization": f"TOKEN={API_KEY}"}

# tier -> require signedDelegation
POLICY = {
    0: True,
    1: True,
    2: False,
    3: False,
}

def normalize_dnssec(value: str | None) -> str:
    if not value or not str(value).strip():
        return "unknown"
    v = re.sub(r"\s+", " ", str(value).strip().lower())
    if "signed" in v and "unsigned" not in v:
        return "signed"
    if "unsigned" in v:
        return "unsigned"
    return "unknown"

def audit_domain(domain: str, tier: int) -> dict:
    r = requests.get(
        f"{BASE}/whois",
        params={"domain": domain},
        headers=HEADERS,
        timeout=20,
    )
    r.raise_for_status()
    data = r.json()
    status = normalize_dnssec(data.get("dnssec"))
    require_signed = POLICY.get(tier, False)
    finding = None
    if require_signed and status != "signed":
        finding = "dnssec_required_but_not_signed"
    return {
        "domain": domain,
        "tier": tier,
        "dnssecRaw": data.get("dnssec"),
        "dnssec": status,
        "registrar": (data.get("registrar") or {}).get("name"),
        "nameservers": data.get("nameserver") or [],
        "finding": finding,
        "ok": finding is None,
    }

inventory = [
    ("login.example.com", 0),
    ("www.example.com", 1),
    ("promo.example.com", 3),
]
for domain, tier in inventory:
    print(audit_domain(domain, tier))

Node.js: Same Policy Check

dnssec-audit.jsNode.js

const API_KEY = "YOUR_API_KEY";
const BASE = "https://whoisjson.com/api/v1";
const POLICY = { 0: true, 1: true, 2: false, 3: false };

function normalizeDnssec(value) {
  if (!value || !String(value).trim()) return "unknown";
  const v = String(value).trim().toLowerCase().replace(/\s+/g, " ");
  if (v.includes("signed") && !v.includes("unsigned")) return "signed";
  if (v.includes("unsigned")) return "unsigned";
  return "unknown";
}

async function auditDomain(domain, tier) {
  const url = new URL(`${BASE}/whois`);
  url.searchParams.set("domain", domain);
  const res = await fetch(url, {
    headers: { Authorization: `TOKEN=${API_KEY}` },
  });
  if (!res.ok) throw new Error(`WHOIS failed: ${res.status}`);
  const data = await res.json();
  const status = normalizeDnssec(data.dnssec);
  const requireSigned = Boolean(POLICY[tier]);
  const finding =
    requireSigned && status !== "signed"
      ? "dnssec_required_but_not_signed"
      : null;
  return {
    domain,
    tier,
    dnssecRaw: data.dnssec ?? null,
    dnssec: status,
    finding,
    ok: finding === null,
  };
}

auditDomain("example.com", 0).then(console.log);

False Positives and Gaps

Migration lag. DS published at the DNS host but registry still shows unsigned — wait for parent publication before failing Tier 0.

Signed but broken. Registry says signedDelegation while zone signatures are expired — WHOIS will not catch this; schedule separate validator checks for Tier 0.

TLD / source variance. Some responses omit dnssec or use alternate wording. Normalize to signed / unsigned / unknown; never crash on unexpected strings.

Subdomain confusion. DNSSEC is usually evaluated at the zone apex. Auditing www alone can miss apex policy — inventory the zone you actually sign.

What This Audit Cannot Prove

End-to-end RRSIG validity for every record type
That every recursive resolver on the internet will validate successfully
Protection equivalent to CAA (certificate issuance) or TLS (HTTPS trust)
That an unsigned domain is malicious — most of the internet is still unsigned

Use WHOIS DNSSEC status as acheap, scalable registry signal inside inventory and monitoring. Pair critical domains with NS baselines ( nameserver monitoring) and certificate controls where user traffic is sensitive.

Frequently Asked Questions

How do I check DNSSEC status with WhoisJSON?

Call GET /api/v1/whois and read the dnssec field. Normalize values such as signedDelegation and unsigned before applying portfolio policy.

Does signedDelegation mean DNSSEC is fully working?

No. It indicates the registry advertises a signed delegation. Cryptographic validation of DNSKEY and RRSIG records requires a validating resolver or dedicated DNSSEC tooling.

Is DNSSEC the same as CAA?

No. DNSSEC protects DNS authenticity. CAA restricts which certificate authorities may issue certificates. Audit both for high-value hostnames.

Should every domain in my portfolio be signed?

Not necessarily. Require DNSSEC on critical identity and payment zones first. Document exceptions for low-risk or short-lived domains so alerts stay actionable.

Can I bulk-audit DNSSEC?

Yes. Reuse the same /whois call per domain with bounded concurrency, score against tier policy, and store raw dnssec strings for evidence.

Conclusion

A DNSSEC audit with WhoisJSON is a policy problem, not a field tutorial: decide which domains must be signed, read code dnssec | from WHOIS JSON, normalize status, and alert only on tier violations. Keep cryptographic validation as a separate control for the domains that matter most.

Audit DNSSEC status with WhoisJSON

Get registry DNSSEC signals in normalized WHOIS/RDAP JSON — alongside registrar, NS and EPP status for the same domain.

Explore WHOIS API View Documentation