What Are DNSSEC Records and How to Verify Them

DNS was designed in the 1980s without any built-in security. A resolver that asks "what IP does example.com resolve to?" has no way to verify the answer is genuine. DNSSEC (Domain Name System Security Extensions) fixes this by adding cryptographic signatures to DNS records.

The Problem DNSSEC Solves

Without DNSSEC, a network attacker can perform DNS cache poisoning: they inject forged DNS responses into a resolver's cache, redirecting users to attacker-controlled servers without the users knowing. This is also known as a Kaminsky attack, after Dan Kaminsky who demonstrated a practical version in 2008.

DNSSEC ensures that:

1. DNS records come from the authoritative zone owner (authenticity).
2. Records haven't been modified in transit (integrity).

DNSSEC does not provide confidentiality — queries and responses are still unencrypted. That's the job of DNS over HTTPS (DoH) or DNS over TLS (DoT).

How DNSSEC Works

DNSSEC adds several new record types:

The trust chain works from the root zone (.) down:

1. The root zone signs .com's DS record.
2. .com signs example.com's DS record.
3. example.com signs its own DNSKEY and all resource records (A, MX, AAAA, etc.).

A validating resolver walks this chain from root to leaf, verifying each signature. If any signature is missing, expired, or invalid, the resolver returns SERVFAIL instead of the (potentially forged) answer.

Checking DNSSEC with the API

Use the DNS Toolkit DNSSEC endpoint to verify whether a domain's DNSSEC chain is intact:

curl -X GET "https://dns.toolkitapi.io/v1/dns/dnssec?domain=example.com" \
  -H "X-API-Key: YOUR_KEY"

The response tells you whether the domain is signed, whether the chain validates, and flags any issues:

{
  "domain": "example.com",
  "signed": true,
  "valid": true,
  "algorithm": "ECDSAP256SHA256",
  "key_tag": 12345,
  "issues": []
}

Common issues include expired RRSIG records, mismatched DS records (often after a key rollover), or missing NSEC records.

DNSSEC Adoption

Despite being standardised in 2005 (RFC 4033–4035), DNSSEC adoption remains incomplete. As of 2025, roughly 90% of TLDs sign their zones, but fewer than 5% of registered domains are signed. Validating resolvers (like Cloudflare's 1.1.1.1 and Google's 8.8.8.8) do enforce DNSSEC — meaning that a misconfigured DNSSEC deployment breaks resolution for all users of those resolvers.

Verifying DNSSEC in Production

If you manage a domain, verify your DNSSEC chain after any DNS change, especially:

• Key rollovers (adding or removing DNSKEY records)
• Nameserver changes
• Registrar transfers (the DS record lives at the registrar)

Automated monitoring with the DNS Toolkit API can alert you within minutes of a chain break, long before your users notice.

import httpx

resp = httpx.get(
    "https://dns.toolkitapi.io/v1/dns/dnssec",
    params={"domain": "yourdomain.com"},
    headers={"X-API-Key": "YOUR_KEY"},
)
result = resp.json()
if not result.get("valid"):
    print("DNSSEC chain is broken!", result.get("issues"))

Summary

DNSSEC adds a chain of cryptographic trust to DNS, protecting against cache poisoning and man-in-the-middle attacks. Verifying the chain programmatically is a must for any production domain that enables DNSSEC — a misconfigured chain will break your site for millions of users.