DNS

Saphira Linux dnsDragon

A Saphira feature for running your own authoritative DNS with BIND 9. The first dnsDragon is a proper, practical guide: install BIND from Saphira packages, understand where it lives, build your first zone, and sign it with DNSSEC — without hiding DNS behind a dashboard. You own the machine, the configuration and the DNS.

In testing, functionality present — helpers missing

Why DNSSEC

Normal DNS answers are not authenticated. A resolver has no cryptographic proof that the answer it received really came from the authoritative server and was not tampered with in transit. DNSSEC adds that proof: each signed record carries a cryptographic signature (RRSIG) that a validating resolver can check against a public key published in the zone.

NoteDNSSEC does not encrypt your DNS traffic and does not hide who queries what. It provides integrity and authenticity: the answer is genuine and complete.

Signing the zone on the server

Signing happens on the authoritative server, with two key pairs: a Zone Signing Key (ZSK) that signs the records day to day, and a Key Signing Key (KSK) that signs the ZSK and is what the parent ultimately trusts. Generate them, then sign the zone. The output is a new zone file (commonly .signed) containing DNSKEY, RRSIG and NSEC records alongside your original data.

# Generate a ZSK and a KSK for the zone
cd /var/bind
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
dnssec-keygen -a RSASHA256 -b 4096 -f KSK -n ZONE example.com

# Sign the zone (increments the serial, adds DNSKEY/RRSIG/NSEC)
dnssec-signzone -A -3 $(head -c 8 /dev/random | od -An -tx1 | tr -d ' 
') -N INCREMENT -o example.com example.com.zone

# Validate the signed result
named-checkzone example.com example.com.zone.signed

DNSKEY — the public ZSK and KSK, published in the zone so resolvers can verify signatures.
RRSIG — the signature over each record set, produced with the private ZSK.
NSEC (or NSEC3) — proves the absence of a name, so a negative answer is authentic too.

WarningThe private ZSK and KSK never leave the server and are never published. Only the public DNSKEY records go into the zone. Do not paste private keys into documentation or anywhere else.

Signing is not the same as trust

A signed zone proves its own records internally, but the world still needs a way to know your public key is really yours. That link is the DS record, published in the parent zone. For example.com the DS lives in .com; for a .uk name the DS lives at Nominet. You, the zone owner, do not control the parent — your registrar does.

So establishing trust is a two-step handoff. First, derive the DS record from your KSK. Then give that DS to your registrar, who publishes it in the parent zone. Until the DS is present at the parent, validating resolvers will not trust your signatures even though the zone is correctly signed.

# Derive the DS record from the KSK (use the .key file of the KSK)
dnssec-dsfromkey -a SHA256 Kexample.com.+008+*.key

# Example output you hand to your registrar:
# example.com. IN DS 12345 8 2 3f7e...longhexdigest...

# Then: log in to your registrar (e.g. UK2.net) and add that DS record.

GoodThis is the chain of trust: your signed zone → your DNSKEY/KSK → the DS your registrar publishes in the parent → upwards to the root. Break the DS link and the whole chain below it becomes untrusted, even with a perfectly signed zone.

Verify the chain of trust

Once the zone is signed and the DS is published at the parent, prove it end to end with delv, which performs full DNSSEC validation. A clean validated answer means the chain holds; a failure usually means the DS at the parent does not match the key in the zone, or the DS is missing entirely.

delv example.com +vtrace
dig +dnssec example.com SOA

WarningIf delv reports bogus, check the DS first. A signed zone with no matching DS at the parent is the single most common DNSSEC mistake — the signatures are correct, but nothing upstream vouches for them.

What dnssec-validation means here

You will see dnssec-validation no in authoritative server configurations (including Saphira's own). That setting controls whether this server acts as a validating resolver for other people's data. An authoritative-only server has recursion off and never validates others' answers, so the setting is irrelevant to it — and it has nothing to do with whether its own zones are signed. Signing (dnssec-signzone) and validation (dnssec-validation) are separate concerns.