DNS was designed to trust whatever answer arrives first. DNSSEC adds signatures to DNS records, so resolvers can check that an answer really came from the domain's owner and was not altered on the way. Registrars and hosting panels now make a DNSSEC setup look like a single switch, and for domains hosted with a large DNS provider it often is. When your business runs its own authoritative DNS server, or moves domains between providers, a few details decide whether DNSSEC protects you or takes your domain offline. This guide covers those details in plain terms.
What is DNSSEC, and what it does not do
What is DNSSEC in practice? The records in a zone are signed with a private key, and the matching public key is published in the zone itself. A fingerprint of that key, the DS record, sits in the parent zone, for example .com, and gets there through your registrar. Validating resolvers follow this chain of trust from the root down and reject answers whose signatures do not match. That protects against cache poisoning and forged answers that could send visitors or email to the wrong server.
DNSSEC does not encrypt DNS traffic, does not hide which names are looked up and does not replace HTTPS. It also cannot help if someone gets into your registrar or DNS account, so strong passwords and two-factor authentication there matter more than any protocol.
How a DNSSEC setup works step by step
- Sign the zone on the authoritative server, which creates the keys and signatures.
- Check that signed answers come from every nameserver for the domain, secondaries included.
- Publish the DS record at the registrar. Until this step nothing validates, so mistakes in the first two steps are harmless.
- Verify the chain with dig +dnssec or delv against a validating resolver, or with an online DNSSEC analyzer.
- Monitor signature expiry and key changes from then on.
The order matters. Publishing a DS record for a zone that is not properly signed on every nameserver makes validating resolvers reject the domain outright.
BIND dnssec-policy and PowerDNS DNSSEC
In current BIND 9 releases, signing is driven by a policy. Adding a BIND dnssec-policy statement to the zone, and the built-in default policy is a good start, makes BIND create the keys, sign the zone and keep re-signing it automatically. The default policy uses one combined signing key with the ECDSA P-256 algorithm, algorithm 13, which keeps responses small. The BIND DNSSEC guide covers the details, including how BIND can check the parent zone for the DS record before it continues a key change. As with any bind configuration change, run the configuration checks before reloading. Signing zones on BIND or PowerDNS servers is part of our DNS server configuration work.
PowerDNS DNSSEC works differently because zones live in a database. The pdnsutil tool secures a zone and prints the DS records to hand to the registrar, and PowerDNS signs answers as it serves them. Secondary nameservers need attention with either product. If a secondary receives the zone by zone transfer, it must serve the signed version; a secondary that builds the zone on its own returns unsigned answers and breaks validation for part of your visitors.
What causes a DNSSEC validation failure
When DNSSEC breaks, the domain does not look slow or partly wrong. For users behind validating resolvers, which include many large public resolvers and internet providers, it simply stops resolving: websites, email and everything else on the domain. The usual causes:
- Expired signatures. Signatures carry an expiry date. If signing stops, for example because a server was rebuilt without its keys, the zone keeps working until the signatures run out, then fails all at once.
- A DNSSEC key rollover done out of order. Replacing the key-signing key means publishing the new DS record at the right moment and removing the old one only after caches have expired. BIND's default policy avoids routine rollovers of that key, which is one reason it suits small organizations.
- Changing DNS provider with DNSSEC on. The new provider signs with different keys while the registrar still holds the old DS record.
- Secondaries that serve unsigned data, as described above.
Moving or switching off DNSSEC safely
To move a signed domain to another DNS host, the simplest safe route is to go unsigned first. Remove the DS record at the registrar, wait until the old DS record's time to live has passed everywhere, which for many top-level domains is about a day, then move the domain, sign it at the new provider and publish the new DS record. Some providers support a smoother transfer with both sets of keys in place, but only if both sides cooperate. BIND has a built-in insecure policy for the same reason: it walks a zone back to unsigned in safe steps once the parent no longer points to its keys.
The same caution applies to domain name resolution inside your office network. If your local resolver validates DNSSEC, a broken domain elsewhere fails for your staff too, and switching validation off to "fix" it removes the protection for every other domain.
Frequently asked questions: dnssec setup
Does a small business need DNSSEC?
It is worth having where your DNS provider and registrar handle it automatically. If you run your own nameservers, enable it once monitoring and a written procedure for provider moves are in place, because a mistake affects the whole domain.
Where do I get the DS record?
From the DNS server or provider that signs the zone. You then enter it at the registrar, which passes it on to the parent zone. If the DNS host and the registrar are the same company, this often happens automatically.
Does DNSSEC slow down my website?
Not noticeably. Responses are somewhat larger and resolvers do a little more work, but answers are cached like any other DNS data, and modern elliptic-curve keys keep the overhead small.
Planning to sign your domains, or to move signed domains between DNS hosts? Our DNS server configuration and management service covers BIND and PowerDNS servers, secondaries, MX, SPF, DKIM and DMARC records and DNSSEC for businesses in Los Angeles and beyond. For firewalls and remote access, see our network setup, VPN and security service. Contact us with a list of your domains and where their DNS is hosted today.
