Verifying signing is actually working after enabling it
Publishing DNSKEY records without a matching DS in the parent produces a signed-but-unvalidated zone. The check distinguishes the two states.
Network & DNS🌐 YAS server-sideAPI availableadvanced
DNSSEC Check
Verifies whether a domain has DNSSEC enabled (DNSKEY records).
Processed by YAS · not stored
Ready to runInstant execution
Loading tool…
What does this tool do?
Verifies whether a domain has DNSSEC enabled (DNSKEY records).
Why would I use it?
- You want to confirm DNSSEC is protecting your domain.
- You are auditing domains for DNSSEC adoption.
- You are troubleshooting validation failures.
Real-life example
Input
example.com
Output
DNSSEC: ENABLED — 2 DNSKEY records found
Presence of DNSKEY records indicates signing.
Input → Process → Output → Next
- Input
- Enter a domain.
- Process
- YAS queries DNSKEY records and reports status.
- Output
- Enabled/disabled with key details.
- Next action
- Enable DNSSEC at your registrar if it is missing.
Common mistakes
- Assuming DNSKEY presence means validation passes (chain must be complete).
- Using the tool on domains without DS records at the parent.
- Confusing DNSSEC with DNSSEC validation by resolvers.
What the result means
DNSKEY records show the domain is signed; full validation requires the DS chain.
Privacy & security
Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.
API
Endpoint
POST https://yas.sh/api/v1/tools/dnssec-check
Request Header
Content-Type: application/json
cURL
curl -X POST "https://yas.sh/api/v1/tools/dnssec-check" \
-H "Content-Type: application/json" \
-d '{"domain":"yas.sh"}'JavaScript
const res = await fetch("https://yas.sh/api/v1/tools/dnssec-check", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"domain": "yas.sh"
}),
});
const data = await res.json();Python
import requests
r = requests.post("https://yas.sh/api/v1/tools/dnssec-check", json={"domain":"yas.sh"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| domain | string | Yes | Domain, e.g. example.com |
Success response
{ "domain": "yas.sh", "dnssec": true, "zoneSigningKeys": 1, "keySigningKeys": 1, "status": "SIGNED" }Verify whether a domain has DNSSEC (DNSKEY records via Google DoH).
Error responses
400 VALIDATION_ERROR— invalid input or unsupported option.413 PAYLOAD_TOO_LARGE— input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED— rate limit exceeded (60 req/min).
Limits
- Maximum input: 64 KB per request.
- Rate limit: 60 requests/min per IP address.
- Authenticated accounts benefit from higher tier quotas.
DNSSEC Check: technical reference, use cases and FAQ
How DNSSEC Check works
DNSSEC signs DNS records so a resolver can verify they were not altered in transit. Each zone holds a key-signing key and a zone-signing key published as DNSKEY records; record sets are signed into RRSIG records. The chain of trust runs downward: a DS record in the parent zone contains a digest of the child's KSK, so the root's trust anchor validates the TLD, which validates the domain.
Validation fails closed. If a signature is expired, a DS record does not match the published DNSKEY, or an algorithm is unsupported, a validating resolver returns SERVFAIL rather than the unsigned answer — the domain becomes unreachable for a large share of users. That property makes DNSSEC misconfiguration an outage rather than a degraded security posture, which is why key rollovers must be sequenced carefully.
When to use it: real-world scenarios
Diagnosing SERVFAIL affecting only some users
Non-validating resolvers still answer while validating ones fail, producing an outage that looks intermittent. A broken chain explains it immediately.
Preparing a key rollover
Confirming both old and new keys are published and the DS matches before retiring the old key avoids the classic rollover outage.
Meeting a compliance requirement
Government and financial requirements increasingly mandate DNSSEC; evidence of a valid chain is the artefact auditors ask for.
Pro tips
- Signatures expire. Automated resigning must be monitored — an unnoticed failed cron job takes the domain offline when the RRSIG validity window ends.
- Update the DS record at the registrar whenever the KSK changes, and allow for the parent zone's TTL before removing the old key.
- Prefer algorithm 13 (ECDSA P-256) over RSA: smaller signatures mean fewer truncated responses and less DNS amplification exposure.
- Test in a staging zone first. DNSSEC failures are total, not partial, and there is no gradual rollout.
Limitations and edge cases
What this tool deliberately does not do, and where it will disagree with other implementations.
- DNSSEC authenticates DNS data; it does not encrypt queries. Privacy requires DoH or DoT.
- A valid chain says nothing about whether the addresses in the records are safe.
- Validation depends on the resolver: users behind a non-validating resolver gain no protection even from a perfectly signed zone.
- Results reflect this resolver's view and may be affected by caching of stale keys.
Frequently asked questions
- Do I need DNSSEC?
- It prevents cache-poisoning and forged DNS answers, and it is a prerequisite for DANE. The cost is operational: a signing mistake takes your domain offline, so it needs monitoring and automation.
- Why did enabling DNSSEC break my domain?
- Almost always a DS record at the registrar that does not match the published DNSKEY, or signatures that expired. Validating resolvers return SERVFAIL rather than falling back to the unsigned answer.
- Does DNSSEC encrypt my DNS queries?
- No. It provides authentication and integrity only. Query privacy requires DNS-over-HTTPS or DNS-over-TLS, which are separate mechanisms.
- Which algorithm should I use?
- Algorithm 13, ECDSA P-256 with SHA-256. It produces much smaller signatures than RSA, reducing truncation and amplification concerns, and is universally supported by modern resolvers.
Related tools