100% Australian owned and operated
The short version
- Ordinary DNS answers aren’t signed, so a resolver can’t tell a genuine answer from a forged one.
- DNSSEC adds digital signatures. A resolver that checks them will refuse a forged answer.
- Trust runs down a chain: the root vouches for .au, .au vouches for your zone through a
DSrecord at the registry, and your zone signs its own records. - It doesn’t encrypt anything. And if the chain is broken, your domain vanishes for everyone whose resolver checks.
The problem: DNS answers aren’t checked
The DNS was built in a more trusting era. When a resolver asks a question and an answer comes back, it has very little to go on. As ICANN puts it, “the resolver can only check that a response appears to come from the same IP address where the resolver sent the original query.”
That leaves room for forgery. If someone can slip a false answer in ahead of the real one, the resolver will accept it, cache it, and send everyone who asks to the wrong server for as long as the TTL lasts. The visitor typed the right name and still ended up somewhere else.
What DNSSEC adds
DNSSEC, the DNS Security Extensions, adds signatures. In ICANN’s words it “strengthens DNS authentication using digital signatures based on public key cryptography”. The zone’s owner signs its records with a private key, and anyone can check those signatures with the matching public key.
The standard, RFC 4033, names what you get: “origin authentication and integrity assurance services for DNS data”. In plain terms, a resolver can tell that an answer really came from your zone, and that nobody changed it on the way.
The chain of trust
A signature is only useful if you can trust the key that made it. DNSSEC solves that by having each level of the DNS vouch for the one below, following the same chain of zones that a lookup follows.
ICANN sums the idea up: “the parent zone signs the child zone’s public key, and allows a chain of trust to be built from parent to child.” The chain has to start somewhere, and it starts at the top: “Most resolvers are configured with just one trust anchor: the public key for the root zone.”
The three records behind it
| Record | What it is | Where it lives |
|---|---|---|
DNSKEY | The zone’s public key | In your zone, at your DNS host |
RRSIG | A signature covering one set of records | In your zone, beside the records it signs |
DS | A fingerprint of your zone’s key | At the registry, one level up |
The DS record is the link between your zone and the registry, and it’s the only one you handle yourself. RFC 4034 notes that it “appears only on the upper (parental) side of a delegation”. So it isn’t added in your DNS editor. It’s added where the domain is registered, and passed on to the registry from there.
Who does what
- Your DNS host creates the keys, signs the zone, and re-signs it whenever a record changes. This part should be automatic.
- You copy the DS record from your DNS host to the place your domain is registered. Some DNS hosts and registrars can do this hand-off between themselves.
- The registry publishes the DS record, signed with its own key.
- Resolvers do the checking, if they’re set up to. One that does is called a validating resolver.
What DNSSEC doesn’t do
It’s easy to assume more than is there. RFC 4033 is explicit about the limits:
- It doesn’t hide anything. “DNSSEC is not designed to provide confidentiality”. Lookups are signed, not encrypted, and anyone watching the network can still see which names are being asked for.
- It doesn’t stop attacks that flood a server. “DNSSEC provides no protection against denial of service attacks.”
- It doesn’t secure the website. That’s the job of HTTPS. DNSSEC makes sure visitors are sent to the right server; HTTPS protects what happens once they arrive.
The catch: a broken chain takes you offline
DNSSEC fails closed. If a validating resolver can’t verify an answer, it doesn’t fall back to the unsigned version. ICANN describes the result: “the user will (purposely) get no data back.” To that user, your domain simply doesn’t exist.
That’s exactly right when the answer is forged. It’s painful when the cause is your own setup. The usual ways a chain gets broken:
- Changing DNS hosts with the old DS record still in place. The registry keeps vouching for a key the new host doesn’t have. This is the big one. Moving your DNS safely covers the order to do things in.
- A DS record typed in wrong. One wrong character and nothing validates.
- A DNS host that stops signing while the DS record stays at the registry.
The symptom is distinctive: the site works for some people and not for others, depending on whether their resolver validates.
Should you switch it on?
A fair answer has two halves.
- Yes, if your DNS host makes it automatic. When signing and key changes are handled for you, DNSSEC costs you one DS record and closes a real gap.
- Take care if anything is manual. A setup where you have to remember steps is a setup that will one day be forgotten, and the penalty is an outage.
Either way, write down that the domain is signed. The person who changes DNS hosts in three years needs to know before they start, and it may well be you.
At Chill Domains. For endings that support it, your dashboard has a DNSSEC page where you add or remove DS records, and we pass them to the registry. Our own DNS hosting doesn’t sign zones, so to use DNSSEC you run your DNS at a provider that does, such as Cloudflare, and add the DS record it gives you. Remove the DS record first if you ever move your DNS back.
Terms in this lesson
- DNSSEC
- An add-on to DNS that signs answers digitally, so a resolver can check they haven’t been forged on the way.
- Chain of trust
- How DNSSEC proves an answer is genuine: the root vouches for each ending, each ending vouches for the domains under it, and your zone signs its own records.
- Trust anchor
- The one key a DNSSEC-checking resolver has to know in advance: the root zone’s.
- DS record
- The record that links a DNSSEC-signed zone to the level above.
- DNSKEY record
- The public key a DNSSEC-signed zone publishes, so resolvers can check the signatures on its records.
- RRSIG record
- A DNSSEC signature.
- Validating resolver
- A resolver that checks DNSSEC signatures and refuses any answer that fails.
- DNS host
- The company that runs the nameservers holding your zone.
- Resolver
- The server that does DNS lookups on your behalf and remembers the answers.
Every term, in full, is in the glossary.
Sources
All read on 2 October 2026.
- DNSSEC: What Is It and Why Is It Important? (ICANN): the gap in ordinary DNS, signatures, the chain of trust, the root trust anchor and what happens when validation fails.
- RFC 4033, DNS Security Introduction and Requirements (IETF): what DNSSEC provides and what it doesn’t.
- RFC 4034, Resource Records for the DNS Security Extensions (IETF): the DS record sits on the parent side of a delegation.