DNSSEC, NSEC, NSEC3, and parent DS records

Ordinary DNS says 'this nameserver answered'. DNSSEC adds cryptographic signatures so a validating resolver can establish 'this answer belongs to the owner of this zone and was not altered'. Signed zones publish DNSKEY records, answers carry RRSIG signatures, and authenticated denial records prove that a name or record type really does not exist. DNSSEC does not encrypt DNS requests, hide the names people ask for, or replace TLS for websites and mail.

DNS root
   │ DS for test.
   ▼
.test parent zone
   │ DS for example.test
   ▼
example.test authoritative zone
   ├── DNSKEY: public signing keys
   ├── RRSIG: signatures over DNS records
   └── NSEC or NSEC3: signed proof of authenticated non-existence

Both NSEC and NSEC3 provide authenticated denial of existence. A resolver needs this proof to trust an NXDOMAIN or no-data answer. The choice is not 'secure versus insecure': both are DNSSEC mechanisms. The trade-off is operational simplicity and what negative proofs reveal about names in the zone.

NSEC3 does not make a public zone private. Hostnames such as mail, www, vpn, and autoconfig are easy to guess. If a name must be private, keep it in an internal DNS view reachable only through the appropriate LAN or VPN; do not rely on DNSSEC denial style to hide it.

dnsDragon uses BIND as the authoritative DNS engine. The live reference deployment demonstrates the real shape of a serious authority: separate forward and reverse zone declarations, an authoritative-only listener, controlled transfer and notification paths, persistent signing state, protected private signing keys, and tested backups. Recreate the shape for your own domain; never copy another operator's key files, addresses, ACLs, or transfer secrets.

1. 1. Start with a working unsigned authority

   Set the registrar delegation to at least two reachable authoritative nameservers, publish their glue where it is needed, and prove SOA/NS/A/AAAA answers directly before adding DNSSEC.

2. 2. Choose the signing owner

   Use dnsDragon/BIND's managed signing path or an offline signing workflow. Decide where private keys live, who can read them, how they are backed up, and who performs rollovers before generating keys.

3. 3. Enable signing and validate locally

   Validate named.conf and the unsigned zone before reload. Confirm the server publishes DNSKEY and RRSIG records from both IPv4 and IPv6 authoritative addresses.

4. 4. Publish the DS at the parent

   Derive the DS from the active key and submit it through the registrar's DNSSEC/DS facility. The registrar, registry, or parent operator—not the child-zone server—publishes this record.

5. 5. Prove validation from outside

   Use a validating resolver or delv from an independent network. Check both ordinary positive answers and a deliberately non-existent name so you prove signed negative answers too.

# A BIND primary-zone shape for managed inline signing.
# Paths and policy names are examples; use your dnsDragon/BIND design.
zone "example.test" {
    type primary;
    file "/var/bind/primary/example.test.zone";
    key-directory "/var/bind/keys/example.test";
    inline-signing yes;
    dnssec-policy default;
};

# Validate before changing the running authority.
named-checkconf /etc/bind/named.conf
named-checkzone example.test /var/bind/primary/example.test.zone

# Normal Saphira/OpenRC operation after validation.
rc-service named reload
rc-service named status

Offline signing is useful when the signer is deliberately separate from the serving system. The private key is the sensitive asset; its .private file must never be committed, copied into a public zone repository, pasted into a ticket, or published in documentation. The public .key file and the derived DS are designed to be shared. Prefer dnsDragon/BIND managed policy when it matches the operational model; use an offline process only when you can own its rollover and backup discipline.

# Generate example keys in a protected directory.
# Record the returned key names; do not use another operator's key files.
dnssec-keygen -a ECDSAP256SHA256 -n ZONE -K /var/bind/keys/example.test example.test
dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE -K /var/bind/keys/example.test example.test

# NSEC signing: no -3 option.
dnssec-signzone -g -o example.test /var/bind/primary/example.test.zone Kexample.test.+013+12345

# NSEC3 signing: -3 supplies an operator-chosen hexadecimal salt.
# Choose policy deliberately; do not copy this illustrative salt.
dnssec-signzone -3 a1b2c3d4 -o example.test /var/bind/primary/example.test.zone Kexample.test.+013+12345

# The signer writes a .signed zone. Validate it before serving it.
named-checkzone example.test /var/bind/primary/example.test.zone.signed

The DS record lives above your zone. For example.test it is published in the test parent; for a .uk domain it is ultimately a Nominet-parent concern, normally accessed through your registrar. Your nameserver can generate the public DS data, but it cannot publish it to the parent itself. That division is intentional: each level in DNS controls only its own zone.

# Build a SHA-256 DS record from the public KSK key file.
# -2 selects SHA-256; keep the resulting DS fields together.
dnssec-dsfromkey -2 Kexample.test.+013+12345.key

# Before parent publication, inspect the active child DNSKEY.
dig +dnssec example.test DNSKEY +multi

# After publication, query for the DS through a validating resolver.
dig +dnssec example.test DS +multi
delv example.test SOA

Copy the complete DS record exactly as the registrar asks: key tag, algorithm, digest type, and digest. Do not invent a DS from a ZSK, alter the digest formatting, or publish an old DS after a rollover. Keep a dated record of the key tag, zone, DS submission, parent confirmation, and validation result.

DNSSEC keys and signatures have lifetimes. BIND managed signing can automate the schedule, while an offline process makes the operator responsible for every publish, re-sign, and parent DS transition. Either model needs a written record of the active DNSKEY key tag, parent DS, rollover dates, signing host, protected backups, and who may contact the registrar.

1. 1. Add and serve the replacement key first

   Publish the new DNSKEY and signatures while the current key and DS still validate. Confirm both authoritative servers serve the same key set over IPv4 and IPv6.

2. 2. Publish the matching replacement DS at the parent

   Generate it from the intended active key, submit it through the registrar, and confirm the parent returns it. Allow the published TTLs and your signing policy to overlap.

3. 3. Validate before retirement

   Use direct dig DNSKEY/DS checks and delv from an independent network. Only retire old key material when the planned overlap is complete and the new chain is proven.

4. 4. Recover a wrong or missing DS deliberately

   Compare the parent DS to active public DNSKEY records. Restore the matching signing state or correct/remove the parent DS; do not delete live keys or generate replacements blindly.

rndc zonestatus example.test
dig @ns1.example.test example.test DNSKEY +dnssec +multi
dig @ns2.example.test example.test DNSKEY +dnssec +multi
dig +dnssec example.test DS +multi
delv example.test SOA

# An expired or wrong chain often looks like this at a validating resolver:
# status: SERVFAIL
# Then compare the direct authoritative DNSKEY and the parent DS before changing keys.