DNSSEC explained for small businesses.

What does it do?

Plain DNS is unauthenticated. Every record a resolver returns is essentially "trust me, this is what the answer is". An attacker who can poison a resolver, run a hostile public wifi DNS, or compromise an upstream resolver can quietly hand out wrong answers for any domain — pointing your website at their server, or your MX records at their mail server. DNSSEC fixes this by signing every record with a private key. The matching public key is itself signed by your registrar's key, which is signed by the .au registry's key, which is signed by the root. The chain ends at trust anchors built into every modern resolver.

When a resolver receives a signed answer, it walks the chain upward and verifies each signature. If any link fails, the answer is discarded and the lookup returns SERVFAIL. The attacker cannot forge a valid signature without your private key, so the entire class of DNS-spoofing attacks goes away.

Why it matters

Imagine an Adelaide professional services firm with a domain hosted on a registrar that supports DNSSEC but the firm has never enabled it. An attacker compromises a smaller upstream resolver used by a regional ISP for a few hours and inserts fake A records for the firm's domain pointing to a cloned login portal. Customers on that ISP hit the fake portal, see a valid-looking certificate the attacker has quickly issued via a cheap CA that only validates over HTTP, and submit their account credentials. With DNSSEC enabled, every resolver in the path would have refused the forged answer, the cert issuance step would itself have failed under CAA constraints, and the cloned portal never makes it onto any visitor's screen.

How to set it up

DNSSEC is configured in two places: at your DNS host, where the records are signed, and at your registrar, where the fingerprint of the signing key is published as a DS record. Both pieces have to agree.

• In your DNS host (Cloudflare, Route 53, DNSimple, your registrar's own DNS), turn on DNSSEC. The host will generate a key and produce a DS record value, typically something like:

yourdomain.com.au.  DS  2371 13 2 2A5A85D3...

• In your registrar control panel, paste that DS record into the DNSSEC section. Some registrars (auDA-accredited ones in particular) expose this as a single "Add DS record" form; others want you to enter the algorithm, digest type and key tag separately.
• Wait twenty-four to forty-eight hours for the .au or .com.au registry to publish the DS record.
• Verify chain validation. A clean result looks like a green tick at dnssec-analyzer.verisignlabs.com or an ad flag on a dig +dnssec response.

Plan migrations carefully. If you change DNS hosts, never delete the DS record before the new host's zone is signed, and never publish a DS record before the new host's keys exist. The standard pattern is to add the new DS, wait one TTL, then remove the old DS.

Common mistakes

• Switching DNS providers without rotating the DS record. The single most common DNSSEC outage.
• Enabling DNSSEC at the DNS host but never publishing the DS record at the registrar. Signing has no effect.
• Using a deprecated algorithm. Algorithms 5 and 7 (SHA-1 family) should be replaced with 13 (ECDSAP256SHA256).
• Letting the signing keys expire without rotation. Modern hosts handle this automatically; older self-hosted setups often do not.

How AttackEdge checks it

The AttackEdge scan checks whether your domain has a valid DNSSEC chain from the root through your TLD to your zone, flags signing algorithm choices, and surfaces missing or orphaned DS records. Full methodology on /what-we-check, alongside the rest of the DNS posture checks that build on top of DNSSEC.