Home

DNSSEC: Securing DNS Queries with BIND

Security
Difficulty: Advanced
4 min read

A tutorial to install and configure DNSSEC with BIND on Linux to protect your DNS infrastructure against cache poisoning attacks.

Back to tutorials

Key takeaways

  • DNSSEC is not encryption: it adds digital signatures that guarantee the authenticity and integrity of DNS answers. Queries stay readable on the wire, but cache poisoning becomes detectable.
  • The key hierarchy comes down to three objects: the ZSK signs the zone records, the KSK only signs the ZSK, and the DS record is a hash of the KSK published at your registrar to hook the zone into the global chain of trust.
  • On the BIND9 side, three directives are enough in the zone declaration: inline-signing yes, auto-dnssec maintain and key-directory. BIND then generates the keys and signs the zone on its own, with no zone file surgery.
  • The DS record is extracted with dnssec-dsfromkey -2 against the KSK .key file. You must carry the four values over to the registrar: key tag, algorithm, digest type and the digest itself.
  • Validation is checked with dig +dnssec: the ad (Authenticated Data) flag in the header means the resolver verified the signature. ZSK rollover is automatic, KSK rollover stays manual because it requires a new DS at the registrar, typically every 1 to 2 years.
What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) is a technology that strengthens authentication in the DNS by using digital signatures. It allows a DNS client to verify that the responses it receives from a DNS server are authentic and have not been tampered with. It does not encrypt queries, but it guarantees their integrity.

Why use DNSSEC?

The DNS was designed without security. An attacker can intercept a DNS query and return a fake IP address, redirecting a user to a malicious site. This is known as DNS cache poisoning. DNSSEC prevents this type of attack.

Prerequisites

  • A working BIND9 DNS server, acting as master for a zone (e.g. `example.com`).
  • Root access or sudo privileges.
  • Your domain name registrar must support DNSSEC so you can publish your keys.

Premium Content

This advanced tutorial is reserved for premium members.

9,90€ / month
  • All advanced tutorials
  • New content every week
  • Progress tracking
  • Cancel anytime
Log in Create an account
MR

Written by

Morgann Riu

Cybersecurity and Linux administration expert. I share my knowledge through free tutorials and training to help system administrators and developers secure their infrastructures.

My profile LinkedIn GitHub

Frequently asked questions

BIND signed my zone but no resolver validates it, why?
As long as the DS record is not published at the registrar, the signed zone is anchored to nothing: resolvers treat it as unsigned and ignore the signatures. Extract the DS with dnssec-dsfromkey -2, enter its four fields in your registrar's DNSSEC section, then wait: propagation takes anywhere from a few minutes to 24 hours.
Why two keys, a ZSK and a KSK, instead of just one?
The ZSK signs every record in the zone: it does the heavy lifting and therefore needs to be rolled often. The KSK, which is stronger, only signs the ZSK. Only the KSK hash goes to the registrar as a DS record, which lets you renew the ZSK as often as needed without ever touching the registrar configuration again.
Does DNSSEC encrypt my DNS queries?
No, and that is the most common misconception. DNSSEC provides authentication and integrity, not confidentiality: an observer on the network still sees which names you resolve. What it does guarantee is that an answer has not been forged or tampered with in transit, which blocks cache poisoning. Confidentiality is handled by other mechanisms, such as encrypted DNS transports.
Do I have to handle key rollover manually?
With auto-dnssec maintain, BIND takes care of ZSK rollover automatically, so there is nothing to do on your side. The KSK is a different story, because changing it means publishing a new DS record at the registrar, an operation that cannot be automated from the server. That manual rollover is usually planned every 1 to 2 years.
How do I concretely verify that validation works?
From the command line, run dig +dnssec www.example.com @8.8.8.8 and look for the ad flag in the answer headers: its presence proves a third-party resolver validated your chain of trust end to end. The +dnssec option also displays the RRSIG records. For a graphical view of the whole chain, dnsviz.net and dnssec-analyzer.verisignlabs.com give a full diagnosis from the domain name alone.

Share this tutorial

X LinkedIn WhatsApp

Did you enjoy this article?

Was this article helpful?

Thanks for your feedback!

Comments

Recommended for you

Sécurité

iptables : Configurer un Pare-feu sur Linux

 Sécurité

UFW : Pare-feu simple pour Linux

 Sécurité

Bastion SSH : Sécuriser l'Accès à Vos Serveurs

 Sécurité

Snort : Détection d'intrusion réseau (NIDS)

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.

← Back to home
↑