DNSSEC is a set of DNS extensions that sign your domain’s records, so a validating resolver can detect forged or altered answers. It protects the directions to your website and mail, not the traffic itself. A business that takes payments, logins or sensitive data should consider it, provided it is set up and changed carefully.
I have worked in IT and development since 1998. This guide includes what happened when we moved rizonetech.com’s DNS to a new provider in October 2026, with DNSSEC switched on. The standards and figures below are from the published sources, read on 12 October 2026.
What problem does DNSSEC solve?
When someone opens your website or sends you email, their device asks a DNS resolver where your domain lives. Without DNSSEC, the resolver has no way to check that the answer is genuine. An attacker who gets a forged answer accepted, which ICANN calls poisoning the resolver’s cache, can send your visitors and mail to a server they control. The address in the browser stays the same, although HTTPS certificate checks can still block the connection if the attacker cannot present a valid certificate for your domain.
What does DNSSEC actually do?
DNSSEC adds signatures that a validating resolver checks against a chain of trust. For a .co.za domain, that chain runs from the root of the DNS through .za and co.za to your domain; a .com domain follows the .com branch. RFC 4033, the standard that defines it, says the extensions “provide origin authentication and integrity protection for DNS data”. If an answer has been forged or altered, the signature does not match, and a validating resolver refuses it.
Two points are easy to miss:
- The resolver does the checking. Google Public DNS and Cloudflare’s 1.1.1.1 both validate. APNIC’s measurement estimates that 56.2% of the users it measured in South Africa were behind validating resolvers over the 30 days to 9 October 2026. Users whose resolvers do not validate get no protection from it.
- It proves the answer, not the owner. DNSSEC shows that a DNS answer came unchanged from whoever controls the domain’s zone. It says nothing about whether the website is trustworthy.
What does DNSSEC not do?
RFC 4033 is plain about it: the extensions “do not provide confidentiality”, and they provide “no protection against denial of service attacks”. In practice:
- It does not encrypt anything. HTTPS protects the connection to your website.
- It does not stop spam or phishing. SPF, DKIM and DMARC help authenticate your email and reduce direct spoofing of your domain, but they do not prevent every phishing technique.
- It does not protect a stolen registrar login. An attacker who can change your nameservers and DS records can point the domain at a DNS service they control and build a new, valid signing chain. Turn on multifactor authentication at your registrar, as ICANN advises.
How do you switch DNSSEC on?
It takes two parties. Your DNS provider signs the zone and gives you a DS (Delegation Signer) record. Your registrar then publishes that DS record in the parent zone, for a .co.za domain the co.za registry. Only then does the chain of trust reach your records. Cloudflare’s DNSSEC guide describes the provider’s half: when you enable it, Cloudflare “signs your zone, publishes your public signing keys, and generates your DS record”.
South Africa’s namespace supports it: .za and co.za are signed, and the registry for co.za has published its DNSSEC framework.
What can go wrong with DNSSEC?
The two halves can fall out of step, and then validating resolvers refuse your domain altogether. They return an error called SERVFAIL, so the website does not load and mail cannot find your servers.
The riskiest moment is changing DNS provider. We met it in October 2026, moving rizonetech.com from one DNS provider to Cloudflare. The domain was signed by the old provider, with its DS record at the registry. Cloudflare’s own setup guide warns that changing nameservers while DNSSEC is active can make a domain unreachable. So the order had to be:
- Copy the whole zone to the new provider and check it. Include the website, mail and verification records, and confirm the new nameservers answer every one correctly before anything changes.
- Record the DS record’s full time to live from the parent zone’s own nameservers, while it is still published.
- Remove the DS record at the registrar. Our domain registrar could show DNSSEC through its API but not change it, so this was done in its portal.
- Wait for the old DS to leave every resolver’s cache. Confirm that the parent’s nameservers no longer publish it, then wait at least the time to live you recorded. In our move, public resolvers reported 86,400 seconds (24 hours) for a
.comDS and 7,200 seconds (2 hours) for a.co.zaDS. The.comregistry dropped ours at once. Theco.zaregistry was still publishing ours a minute after removal, and had dropped them when we checked again about four and a half hours later, so the wait started only then. - Change the nameservers, while the old provider still answers with the same records.
- Wait for the old nameserver records to leave resolvers’ caches. Start the clock only when the parent zone’s own nameservers publish the new delegation, not when you submit the change. Then let the previous delegation’s time to live, and the old zone’s own nameserver records, expire. Do not assume a fixed time. Keep the old provider serving the zone throughout.
- Then switch DNSSEC on at the new provider and publish its new DS record. Cloudflare’s guide gives the same order.
- Check that the whole chain validates, with DNSViz or a validating resolver, before you call the move done.
Removing the DS first is the safe direction. While a resolver still holds the old DS, the old provider’s signatures still match, so answers validate. The price is a gap: once the old DS leaves the caches, the domain has no DNSSEC protection until the new chain is published and validates. Breakage needs the other mix: a cached DS that points at keys the new provider does not have. Cloudflare documents a way to migrate without switching DNSSEC off, but only when the old provider can accept the new provider’s keys.
Does your business need DNSSEC?
It depends on what you would lose if your domain’s answers were forged:
| Your situation | DNSSEC |
|---|---|
| You take payments, run customer logins or hold sensitive data | Worth enabling, with someone who will manage changes to it |
| Forged DNS answers redirecting your visitors or mail would cause serious harm | Worth enabling |
| A brochure website and ordinary business email | Lower priority than HTTPS, SPF, DKIM, DMARC and multifactor authentication on your registrar account |
| You are about to change DNS provider | Plan the DS removal and timing, or a coordinated migration, first |
| You are moving only the registration to another registrar | Confirm the existing DS record and DNS service stay in place |
The main cost is care: every change of DNS provider needs a DNSSEC plan, either the temporary DS removal above or a supported coordinated migration.
How can you check whether your domain uses DNSSEC?
Run the free Domain health check. It checks your domain’s DNSSEC status, nameservers and other public DNS records, and where available its registration through RDAP, and explains each result in plain words. For a .co.za expiry date, check your registrar account.
Finding a DS or DNSKEY record does not prove that validation works. DNSViz draws the whole chain from the root to your domain. An unsigned result means you have no DNSSEC protection. A broken chain needs your DNS provider and registrar to fix it, because validating resolvers may refuse your domain until they do.
FAQ
Does DNSSEC encrypt my DNS traffic?
No. It signs DNS answers so they can be checked, but anyone on the path can still read them. Encrypted DNS is a separate technology.
Can DNSSEC take my website offline?
Yes, if the DS record at the registrar and the signed zone at the DNS provider fall out of step, for example during a careless provider change. Validating resolvers then refuse the domain until it is fixed.
Does a .co.za domain support DNSSEC?
Yes. The co.za zone is signed and chained to .za. Whether you can add a DS record depends on your registrar’s tools; some do it through their portal only.
What should you do next?
Check your domain with the free Domain health check. For the email side of the same picture, read our DNS and email security whitepaper, or why business emails go to spam. If you would rather have it set up and watched, DNS Shield covers DNSSEC, SPF, DKIM and DMARC for your domain.
Published 16 June 2026. Last updated 12 October 2026.