DNSSEC: Cryptographic Protection for Your Domain

DNSSEC (DNS Security Extensions) is a set of DNS protocol extensions that adds cryptographic signatures to DNS records. It protects against attacks such as DNS Cache Poisoning and DNS Spoofing.

Why you need DNSSEC

Without DNSSEC an attacker can forge a DNS response and redirect visitors to a fake site (even if you have HTTPS). The attack is known as DNS Hijacking or Cache Poisoning.

With DNSSEC every DNS record carries a digital signature. If the response has been altered, the signature will not match and the query will be rejected.

How DNSSEC works

1. The zone is signed with a pair of keys: ZSK (Zone Signing Key) and KSK (Key Signing Key)
2. The DS record (Delegation Signer) is published in the parent zone (.com, .ua)
3. A DNSSEC-aware resolver verifies the signature on every query
4. If the signature is invalid — SERVFAIL, the query is rejected

DNSSEC: enable it or not

Checking DNSSEC

# Check the domain signature
dig example.com DNSKEY +dnssec

# Online validator
# dnsviz.net — a visual map of the DNSSEC chain

Enabling DNSSEC at ZevsHost

1. Log in to the Client Area → Domains → domain management
2. Open the DNSSEC section → enable it
3. The system will automatically create the DS records and the keys
4. The DS record will be published in the zone registry

Signing Algorithms: Algorithm 8, 13 and 15

DS and DNSKEY records carry a numeric Algorithm field that identifies the cryptographic algorithm used to sign the zone. It determines whether a resolver can validate the signature at all.

Changing the algorithm on an already-signed live zone is not a one-shot operation: you have to publish the new DNSKEY, wait for the old records' TTL to expire everywhere in the world, and only then update the DS record at the registrar. Skipping the pause between steps produces a temporary Bogus status for some users.

SERVFAIL vs Bogus — the difference

Both statuses look like "the site won't open" to a visitor, but they mean different things:

• SERVFAIL — the resolver could not get an answer at all: an expired signature, an unreachable authoritative server, or an error in the zone itself
• Bogus — the resolver got an answer, but the signature failed validation: the DS in the registry does not match the zone's actual DNSKEY

# Check the validation status explicitly, with delv (ships with BIND)
delv example.com A

# Expected output when there is a problem:
# resolution failed: bogus

Unlike dig, delv reports the failure reason as text instead of a bare SERVFAIL code — it is the first tool for diagnosis, not guesswork over resolver logs.

When Not to Enable DNSSEC

• The zone moves between DNS providers often — DS desynchronization on every migration is a bigger risk than the benefit
• The domain's registrar technically cannot publish DS records (true for some ccTLDs) — enabling it on the hosting side gives no protection
• There is no key-rotation process or RRSIG expiry monitoring — a forgotten expired signature will break resolution completely
• DNS is used with aggressive second-level IP failover — DNSSEC makes debugging such setups harder, see DNS failover
• The domain runs on a TTL under 60 seconds for fast switching — at that TTL, operational DNSSEC mistakes surface faster than monitoring can react

Checking the Chain of Trust After a Registrar Change

# Check the DS record visible in the parent zone
dig example.com DS +short

# Check the full chain from the root
dig +trace example.com A

# Compare the Key Tag in the DS with the tag of the active DNSKEY
dig example.com DNSKEY +short

After a domain transfer to a new registrar, the DS record is physically stored in the TLD registry, not at the registrar — so changing registrars does not break DNSSEC by itself. What breaks it is the new registrar's support team occasionally clearing the DS records "just in case" during a transfer — that is worth confirming in advance.