BRev DS record — delegation signer
A DS record is a hash of a zone’s Key Signing Key, published in the PARENT zone. That location is the whole design: if the digest lived in your own zone, an attacker who could forge your zone could forge the digest too. Putting it one level up means .com vouches for your key, the root vouches for .com, and the resolver’s configured trust anchor for the root closes the chain.
Practically, this is the one DNSSEC record you cannot publish yourself. It goes to the registry through your registrar — a field in the domain control panel, or automated through CDS/CDNSKEY records that let the child signal a change for the parent to pick up. That handoff between two organisations is where most DNSSEC failures originate.
The record carries a key tag (a short fingerprint identifying which DNSKEY it refers to), the algorithm number, a digest type, and the digest itself. Digest type 2 is SHA-256 and is what to use; type 1 is SHA-1 and is deprecated. Publishing two DS records during a key roll is normal and correct — it is how the old and new keys are both valid across the transition.
What a DS record looks like
Type 43 · Delegation signer (DNSSEC chain of trust). Zone-file form below — owner name, TTL, then the record and its RDATA.
| Name | TTL | Record | What it means |
|---|---|---|---|
| example.com. | 86400 | DS 2371 13 2 0123456789abcdef… | Published in the .com zone by the registrar: key tag 2371, algorithm 13, SHA-256 digest. |
| example.com. | 86400 | DS 61045 13 2 fedcba9876543210… | A second DS during a KSK roll — both the outgoing and incoming keys validate meanwhile. |
| _ds-check | — | dig +dnssec DS example.com @a.gtld-servers.net | Ask the PARENT directly. Querying your own nameservers does not show the DS the registry holds. |
The mistakes that break production
Changing DNS provider with DNSSEC enabled
The single most common DNSSEC outage. The new provider signs with its own keys while the parent still holds a DS for the old provider’s key, so every validating resolver fails the chain and returns SERVFAIL — a complete outage for a large share of users. Remove the DS at the registrar first, wait out its TTL, migrate, then publish the new DS.
Querying your own nameservers to check the DS
The DS lives in the parent zone, so asking your authoritative servers tells you nothing about what the registry actually published. Query a TLD server directly, or use a resolver that shows the parent’s answer — this page queries over DoH, which returns the delegation-side record.
Query a DS record now
The box below is seeded with cloudflare.com. Choose DS as the type and press Look up — the query goes from your browser straight to Cloudflare or Google over DNS-over-HTTPS, with no server of ours in the path.
DNS is the internet's address book: it turns a name like example.com into the addresses and service endpoints machines actually connect to. Every record has a type (what kind of fact it states) and a TTL (how long resolvers may cache it).
Record types
| Type | What it stores |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Canonical name (alias) |
| MX | Mail exchanger (priority target) |
| TXT | Text — SPF, verifications, DKIM, arbitrary data |
| NS | Authoritative nameservers |
| SOA | Start of authority (serial, refresh, retry, expire, minimum) |
| SRV | Service locator (priority weight port target) |
| CAA | Which CAs may issue certificates |
| PTR | Reverse DNS (IP → name) |
| DNSKEY | DNSSEC public key |
| DS | Delegation signer (DNSSEC chain of trust) |
| HTTPS | HTTPS service binding (ALPN, ECH, hints) |
| SVCB | General service binding |
| TLSA | DANE — pin certificates in DNS |
| NAPTR | Name authority pointer (SIP/ENUM) |
TTL & “propagation”
DNS changes don't “push” anywhere — resolvers simply keep the old answer until its TTL runs out, then fetch the new one. So a change “propagates” in at most the old record's TTL. Planning a change? Lower the TTL (e.g. to 300s) a day in advance, make the change, then raise it back. The compare card above shows whether major public caches have picked your change up yet.
FAQ
Where is the DS record published?
In the parent zone — for example.com that is .com, populated through your registrar. It cannot be added to your own zone file, because the point is that the parent, not you, vouches for your key.
What is the difference between DS and DNSKEY?
DNSKEY is the public key, published in your zone. DS is a digest of that key, published in the parent. The resolver uses the parent’s DS to decide whether to trust the child’s DNSKEY.
How do I disable DNSSEC safely?
Remove the DS record at the registrar first, wait for its TTL to expire everywhere, and only then stop signing the zone. Doing it in the other order leaves a chain pointing at keys that no longer exist, which is a full outage for validating resolvers.