What is DNSSEC and How to Protect Your Domain from DNS Hijack

The DNS system that translates domain names into IP addresses was designed in the early days of the internet with little consideration for security. This has led to vulnerabilities such as DNS Cache Poisoning and DNS Hijacking. DNSSEC was developed specifically to address these threats by adding cryptographic authentication to DNS responses.

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is a suite of extensions to the DNS protocol that adds digital signature verification to DNS responses. Every DNS response is accompanied by a digital signature, allowing resolvers to verify that the data came from a legitimate source and was not tampered with in transit.

DNSSEC does not encrypt DNS data — DNS queries and responses remain in plain text. Instead, it adds authentication and integrity verification to confirm that answers originate from the authoritative name server, not an attacker intercepting the traffic.

Threats That DNSSEC Prevents

DNS Cache Poisoning

An attacker injects forged DNS responses into a recursive resolver's cache, causing users querying that domain to receive a fake IP address and be directed to a malicious website without their knowledge.

DNS Hijacking

An attacker gains control of a DNS server or modifies DNS records for a domain, redirecting traffic to servers under their control. This can lead to credential theft or malware distribution.

Man-in-the-Middle DNS Attacks

An attacker intercepts and modifies DNS responses in transit before they reach the user. DNSSEC prevents this because any modification will cause the signature validation to fail.

How DNSSEC Works

DNSSEC uses public key cryptography to build a Chain of Trust from the root zone down to your domain. It introduces several new record types:

• DNSKEY — Contains the zone's public key used to verify signatures
• RRSIG — The digital signature for each Resource Record Set
• DS (Delegation Signer) — A hash of the DNSKEY stored in the parent zone to establish the Chain of Trust
• NSEC/NSEC3 — Provides authenticated denial of existence for records that do not exist

Validation Process

1. The resolver receives a DNS response with an RRSIG signature
2. It retrieves the DNSKEY from the zone and verifies the RRSIG
3. It checks the DNSKEY against the DS record in the parent zone
4. This process repeats up to the root zone trust anchor
5. If the Chain of Trust is complete and valid, the response is trusted

How the Chain of Trust Works — DS, DNSKEY and RRSIG in Depth

The core of DNSSEC is the Chain of Trust, which links trust from the root zone down through each level until it reaches your domain. Every zone signs its own data with a private key and publishes the matching public key in a DNSKEY record, while the parent zone stores only a hash of that key (the DS record) to vouch for the child zone. This means a resolver never has to trust any single name server directly — it trusts a chain of signatures that leads all the way back to the root, which is the trust anchor built into every validating resolver.

Within each zone there are two types of key that serve different purposes, allowing keys to be rotated flexibly without notifying the parent every time:

• KSK (Key Signing Key) — Signs only the DNSKEY RRset. This is the key the parent's DS record points to, so rotating it is harder because the DS at the registrar must also be updated.
• ZSK (Zone Signing Key) — Signs all the other records in the zone (A, MX, TXT, etc.). It can be rotated frequently and easily because it does not affect the DS at the parent.

When a resolver receives an answer, it validates in this order: use the DNSKEY (ZSK) to verify the RRSIG of the requested record → use the KSK to verify the DNSKEY RRset → compare the hash of the KSK against the DS record at the parent → verify the RRSIG of that DS with the parent's key, and so on up to the root zone. If any hash or signature fails to match, the resolver returns SERVFAIL instead of handing the user a potentially forged answer.

How to Enable DNSSEC for Your Domain

Enabling DNSSEC requires configuration on both the authoritative name server (where your zone file lives) and the registrar (where your domain is registered):

Step 1 — Sign the Zone on Your Name Server

If you use AsiaGB or Cloudflare name servers, zone signing can be handled automatically. Simply enable DNSSEC in the name server settings, and the system generates the DNSKEY and RRSIG records for you.

Step 2 — Submit the DS Record to Your Registrar

After zone signing, you will receive a DS record (containing the Key Tag, Algorithm, Digest Type, and Digest). Submit these values to your domain registrar's management panel so the parent zone can link the Chain of Trust to your domain. A DS record looks like this:

example.com.  3600  IN  DS  12345 13 2 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE...

Here is what each value means — these are the fields most registrar forms ask you to enter:

For .co.th and .in.th domains, submitting the DS record may need to go through the registry's support or form, while .com domains can have their DS records entered directly from the AsiaGB domain management panel. After submitting, the DS record propagates according to the parent zone's TTL (usually within a few hours).

Verify DNSSEC with dig and DNSViz

After enabling DNSSEC, confirm the Chain of Trust is complete before considering the job done. The fastest way is the dig command from your own machine:

# Check whether the zone is signed (has RRSIG)
dig example.com A +dnssec +multiline

# Check the DS record stored at the parent zone
dig example.com DS +short

# Check the zone's DNSKEY (KSK + ZSK)
dig example.com DNSKEY +short

# Compare a normal lookup with +cd (checking disabled) to see if validation passes
dig example.com A

If validation succeeds, dig's answer will include the ad (Authenticated Data) flag in the HEADER, for example flags: qr rd ra ad;. If ad is missing or you get status: SERVFAIL, the Chain of Trust is incomplete — usually because the DS at the registrar has not propagated yet or was entered incorrectly.

Beyond dig, visual tools make the big picture clearer:

• dnsviz.net — Draws the Chain of Trust from the root down to your domain and highlights any broken links in red
• MXToolbox DNSKEY/DNSSEC Checker — Quickly inspects DNSKEY and DS records
• Verisign DNSSEC Debugger — Shows the status of each validation step

Pitfalls — Key Rollover and DNS Migrations That Break DNSSEC

DNSSEC is a double-edged sword: configured correctly it is very secure, but mishandling keys or migrating DNS the wrong way can make a domain vanish from the internet instantly for validating resolvers (such as Google's 8.8.8.8 and Cloudflare's 1.1.1.1). The most common problems are:

1. Migrating DNS providers without removing the DS first

This is the number-one cause of domain outages. When you move from one DNS provider to another, the new provider generates its own KSK, so the old DS record at the registrar no longer matches the new DNSKEY set → the Chain of Trust breaks → SERVFAIL. The correct procedure is to remove the DS record at the registrar first, wait for the TTL to expire (temporarily disabling DNSSEC), then migrate DNS, and only afterwards re-enable DNSSEC and submit the new DS.

2. Key rollover

Keys should be rotated periodically for security, but it must be done with overlap, not an instant swap — for the ZSK use the Pre-Publish method (announce the new ZSK ahead of time before it starts signing), and for the KSK use the Double-Signature method (sign with both the old and new KSK at once, update the DS at the parent to include both values, then remove the old one). If you swap keys instantly without allowing for TTL, users still caching the old key will fail validation.

3. Clock skew

Every RRSIG has an inception and expiration time. If a server or resolver's clock is wrong, or a signature expires because automatic zone re-signing was forgotten, the signature is immediately considered invalid. Automated DNS systems (like those from AsiaGB or Cloudflare) re-sign before expiry, avoiding this problem.

Benefits and Limitations of DNSSEC

Benefits

• Effectively prevents DNS Cache Poisoning and Hijacking
• Increases trust for users on DNSSEC-validating resolvers
• Foundation for DANE (DNS-based Authentication of Named Entities) for TLS verification

Limitations

• DNSSEC does not encrypt DNS traffic — DNS over HTTPS (DoH) or DNS over TLS (DoT) is needed for that
• Larger DNS responses due to attached signatures
• Key rotation must be managed carefully
• Not all registrars support DS record submission

Frequently Asked Questions About DNSSEC

Does DNSSEC encrypt my DNS data?

No. DNSSEC does not encrypt DNS — queries and responses are still sent in plain text, so anyone intercepting the traffic can still see which domains you look up. DNSSEC only provides authentication and integrity. For DNS privacy you need DNS over HTTPS (DoH) or DNS over TLS (DoT) as well, which operate at a different layer than DNSSEC and can be used together.

Will enabling DNSSEC slow down my website?

Not noticeably. The only effects are slightly larger DNS responses due to attached signatures and a small amount of extra validation work for the resolver, measured in milliseconds. For typical websites this has no impact on page load speed.

What if my registrar doesn't support DNSSEC?

If your current registrar has no field to enter a DS record, you cannot enable DNSSEC even if your DNS provider signs the zone. The solution is to transfer the domain to a registrar that supports it, such as AsiaGB, which supports DS record configuration for .com, .co.th, and .in.th domains.

Can I still migrate hosting on a domain that has DNSSEC enabled?

Yes, normally. Migrating your web server (changing A/AAAA records to point to a new IP) does not affect DNSSEC as long as you keep the same DNS provider, because the new records are signed automatically with the same key set. DNSSEC only causes problems when you change the DNS provider or name servers without updating the DS record.