User Tools

Site Tools


Lab 10.1 – Implementing DNSSEC


Deploy DNSSEC-signed zones.


DNSSEC (or DNS Security Extensions) provide security to the zone files.

Note: In the steps below, we are using : our domain : zone file for the domain = ZSK generated = KSK generated  


A. DNSSEC Validation

To allow your recursive DNS servers to validate DNSSEC-signed zones.

  1. Update the DNS configuration. Change options in the configuration file /etc/bind/named.conf.options to allow DNSSEC. These options must be enabled for this lab to success. This option is required only for LAB purpose and not applicable to real life:
    dnssec-validation yes;

    dnssec-enable allows named to respond to DNS requests from DNSSEC-aware clients. The default is yes, but is best added in the `named.conf` so you know how to turn it off.
    If `dnssec-validation` is set to auto, it defaults to the DNS root zone as the trust anchor.
    If set to yes, a trust anchor must be explicitly configured using the trusted-keys option in /etc/bind/named.conf.local.

    trusted-keys {
    	. 257 3 8 "AwEAAeBVrjcVk2End+jIb/0b5vRZJlQVgh2nspHrcDISSyeslhEiLWUr W9M8Bl/LrUM0PYbfzkzhwtDayPm3Pz1hJN4cdr/zXcjgG/iuOZzXuAK+ GJmhEbM7QS1Tw7YrZLPO8OjqpnSt+vZirfsfCR44KtN9klrx6YFKrFt0 jB6C4gP4S955RyViqLnhNQfW3sq6LIkiUhpVgO82X0GHfe7FFCgqVxG+ 9nmaTu3M6mE9bsiAjuHyxlc+je8Ll12n56cpCMU+f+46hRSSDH6vtMUl sYaP2rvzjn1Mo1txtTLL8K0eXtHPYIaH6mDU8gcfPNFX+7mdECqMbs7B y0JQRykIHtgDTa9pCCIamrpquXvuAIQSAsnZ6ENzpPLRiaLCU92lCrYm +xL2RwQ4i3Y1sbPVfn6D73OWockfGf+Yc6CSxBCk8LvDM5LKtlN7CvkO DF8Jd9hajAL32ZVF2GlW6ps5+9coE0zJgkaWpNicMczIvL1WYtb+hmaK yR48cPDjdgnnezHifHix3C74zpdL4QmN10muzyGqULUKqYZOXiMQff5i TMtFO5MwAFrAfwmgfw+o+NAryhRwFqWaY0h4z8TTCh3rVRYR5PfOzFcd aoewfzOm90XihvoqRrajaEK1W6F+IS/3UVEo4YR7M8mdZK1QF+g94bg0 4yCZkSGN8Z+xnu0p";
  2. Change the root-hint to the lab root server. This part is also required for this lab only and not required in real life. Create a file named lab-root.hints using the command vi /etc/bind/lab-root.hints with the following contents:
    .	8600000		IN	NS	X.ROOT-SERVER.LOC.
  3. Change the zone “.” block in /etc/bind/named.conf.default-zones to reflect the following
    zone "." {
    	type hint;
    	file "/etc/bind/lab-root.hints";
  4. Reload bind with systemctl reload named

B. Signing the zone

  1. Generate the key pair in /etc/bind/master directory. This command generates the ZSK.
    dnssec-keygen –a <algorithm> –b <keysize> -n ZONE <groupXX>


    dnssec-keygen -a RSASHA256 -b 1024 -n ZONE

    The defaults are RSASHA1 for the algorithm, with 1024 bits for ZSK and 2048 bits for KSK. Since these are all defaults, we can just issue the command:

    dnssec-keygen -n ZONE

    This will generate two file. Now generate KSK. This command generates the KSK

    dnssec-keygen -a <algorithm> -b <keysize> -f KSK -n ZONE <groupXX>

    Or simply

    dnssec-keygen -a RSASHA256 -b 1024 -f KSK  -n ZONE
  2. Include the public DNSKEYs in the zone file. You can either copy the entire file or reference to it using the $INCLUDE directive. Note that you are including only the public portion (.key) into the zone file. The private portion (.private) must be kept secure.
    cat Kgroup*.key >>


    $INCLUDE “K<groupXX>.+005+<id_of_zsk>.key”
    $INCLUDE “K<groupXX>.+005+<id_of_ksk>.key”
  3. Sign the zone using the secret keys. The syntax is:
    dnssec-signzone -o <zonename> -N INCREMENT -f <output-file> -t -k <KSKfile> <zonefile> <ZSKfile>


    dnssec-signzone -o -N INCREMENT -f -t -k

    `dnssec-signzone` does the following things:

    1. Takes the public keys from the*.key) and appends them as DNSKEY records to the zone. (This is what the -S flag does)
    2. Signs the DNSKEY record of the ZSK with the KSK
    3. Puts all the records in the zone in canonical (alphabetical) order
    4. Generates a NSEC records for each record and interleaves them into the ordered zonefile
    5. Creates RRSIG records (signatures) for all the records in the zone by signing them with the ZSK.
  4. This creates a new file named which contains `RRSIG` records for each DNS record. If we don't add the –f option output will automatically append a `.signed` in the zonefile.

    After successful signing it will give some output

    		Verifying the zone using the following algorithms: RSASHA1.
    		Zone fully signed:
    		Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked
    		Signatures generated:                       15
    		Signatures retained:                         0
    		Signatures dropped:                          0
    		Signatures successfully verified:            0
    		Signatures unsuccessfully verified:          0
    		Signing time in seconds:                 0.006
    		Signatures per second:                2423.654
    		Runtime in seconds:                      0.014
  5. The output file is bigger than the original zone file. Check with the commands ls -al or wc.

C. Publishing the zone

  1. Reconfigure to load the signed zone. Edit named.conf.local and point to the signed zone. For example:
    zone “<groupXX>” {
    	type master;
    	// file “”;
    	file “”;

    Change the file to point to the signed zone.

  2. Start/Reload named service. Check if for the DNSKEY record using dig on the same server.
    dig DNSKEY @localhost +multiline

    Check for the presence of RRSIG records.

    dig @localhost +multiline +dnssec A
  3. When we ran the dnssec-signzone command apart from the .signed zone file, a file named was also created, this contains the DS records. Push the DS record up to your parent domain. Open the file dsset-<yourdomain> (ex: This contains your DS records (see example below).		IN DS 4297 5 1 C5A8C518B2208463F87CB30E35F247DD7EACCDB1		IN DS 4297 5 2 27E89E4A769F6C6BC889BB6F2E98374CA835D2B8C750D5505F32144E 1E79B881

    Send this to your parent zone (for the lab, it’s the gTLD server). The parent zone will then include the DS record in their zonefile. The $INCLUDE statement can be used at this stage.

    $INCLUDE “”

    In the class, securely send the file to the instructors. You may then check if it has been successfully added using dig.

    dig @nameserver +noadditional DS | grep DS
  4. For slave servers, the configuration is simple. In the configuration file, add in the options section:
    dnssec-enable yes;
    dnssec-validation auto | yes;

    Then edit the zone section to point to the new signed zonefile. After reload, verify that this file exists in the folder specified in the config.

    zone “<groupXX>” {
    	type slave;
    	masters { X.X.X.X; };
    	// file “”;
    	file “”;
  5. Check if DNSSEC is working using the dig command. The output should show an `RRSIG` next to the record you asked.
    dig @localhost +dnssec +multiline
    dig @localhost +trace +dnssec

    Also check for the `AD` bit in the message header flags. It should look something like:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40679
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

D. Signing the reverse zones.

The steps to sign the reverse zones are similar to the instructions in items B and C. Using the IP block assigned to you, create the reverse zones and sign them accordingly. Sample steps as follows using reverse domain for block ``.

  1. Generate the keys.
    dnssec-keygen –a <algorithm> –b <keysize> –n ZONE
    dnssec-keygen –a <algorithm> –b <keysize> –f KSK –n ZONE
  2. Sign the zone
    dnssec-signzone -o -N INCREMENT -f <output-file> -t -k db.192.168.100
  3. Publish the signed zone
    zone “” {
    	type master;
    	// file “”;
    	file “db.192.168.100.signed”;
  4. Verify using dig command.
    dig @localhost +dnssec +multiline
    dig –x @localhost


NSEC records are created to prove the non-existence of a record. It builds a linked list of all the records in the zone file. The problem with this is it allows anyone to list the zone content. This is called “zone walking.” Some tools, like the ldns-walk (included in the LDNS library), can be used to do exactly this. NSEC3 can be used to provide more security. It uses a hashing algorithm to output a “hash” to replace the real domain names. This makes it difficult for an attacker, but not totally impossible. In the steps above, NSEC was used by default. Let us re-do the key generation and signing this time using NSEC3.

  1. Using NSEC3 to generate keys. To do this, you may use `NSEC3RSASHA1` as your algorithm. The easier way to do this is to use `-3` option instead. This option allows a few other algorithms such as `RSASHA256` and `RSAHSHA512` but sets `NSEC3RSASHA1` as default.
    dnssec-keygen -3
    dnssec-keygen -f ksk -3
  2. Sign the zone with a salt.
    dnssec-signzone -A -3 <salt> -o <zonename> -N INCREMENT -f <output-file> -t -k <KSKfile> <zonefile> <ZSKfile>>/code>The salt is a random hexadecimal number appended to the domain before hashing. It’s a public data that is part of the NSEC3PARAM record. It must be changed once in a while or on regular intervals. To generate the salt, you can use either of these:<code>date | sha1sum | cut –b 1-16
    head –c 1000 /dev/random | sha1sum | cut –b 1-16


    dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -o -N INCREMENT -f <output-file> -t -k

    To use NSEC3 without a salt, simply use a single `-` (dash).

    dnssec-signzone -A -3 - -o -N INCREMENT -f <output-file> -t -k
  3. View the signed zonefile (cat /etc/bind/|grep NSEC). Notice that you now have NSEC3 records added with a hash value of the records in the RDATA.
bdnog11/netsec/bind-implementing-dnssec.txt · Last modified: 2020/01/14 12:34 by Muhammad Moinur Rahman