User Tools

Site Tools


bdnog11:netsec:bind-implementing-dnssec

This is an old revision of the document!


Lab 10.1 – Implementing DNSSEC

Objectives

Deploy DNSSEC-signed zones.

Background

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

Note: In the steps below, we are using

	
groupXX.net : our domain  
db.groupXX.net : zone file for the domain  

KgroupXX.net.+005+12345.key/private = ZSK generated  
KgroupXX.net.+005+67890.key/private = KSK generated  

Steps

A. DNSSEC Validation

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

  1. Update the DNS configuration. Add options in the configuration file /etc/bind/named.conf.local to allow DNSSEC. These options must be enabled:
    dnssec-enable yes;
    dnssec-validation yes|auto;


    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. 
	trusted-keys {
		// parent zone
		. 257 3 5 “<key-here>”;
	};

2. For the lab, we will use trusted-keys. A file containing the root’s public key (`http://192.168.30.254/dns/trusted-keys`) will be provided. Copy this into your `named.conf`

#####B. Signing the zone.

1. Generate the key pair. This command generates the ZSK.

	dnssec-keygen -r /dev/urandom –a <algorithm> –b <keysize> -n ZONE <groupXX>
example:
	
	dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 -n ZONE groupXX.net
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 -r /dev/urandom -n ZONE groupXX.net
	
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 -r /dev/urandom -f KSK -n ZONE groupXX.net

2. Include the public DNSKEYs in the zone file.

You can either copy the entire file or reference to it using the \$INCLUDE directive. To do the latter, simply add the lines below. Note that you are including only the public portion (.key) into the zone file. The private portion (.private) must be kept secure.

	$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>
example:

	dnssec-signzone -o groupXX.net -N INCREMENT -f db.groupXX.net.signed -t \
	-k KgroupXX.net.+005+12345 db.groupXX.net KgroupXX.net.+005+67890
`dnssec-signzone` does the following things:  
1. Takes the public keys from the KgroupXX.net.+005+*.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  
4. Creates RRSIG records (signatures) for all the records in the zone by signing them with the ZSK.  
This creates a new file named `groupXX.net.signed` 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. 
	<db.groupXX.net>.signed
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
	db.groupXX.net.signed
	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
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` and point to the signed zone. For example:

	zone “<groupXX>” {
		type master;
		# file “db.groupXX.net”;
		file “db.groupXX.net.signed”;
	};
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 groupXX.net. @localhost +multiline
Check for the presence of RRSIG records.

	dig groupXX.net. @localhost +multiline +dnssec A
	

3. When we ran the `dnssec-signzone` command apart from the `.signed` zone file, a file named `dsset-groupXX.net` was also created, this contains the DS records. Push the DS record up to your parent domain. Open the file `dsset-<yourdomain>` (ex: `dsset-groupXX.net`). This contains your DS records (see example below).

	groupXX.net.		IN DS 4297 5 1 C5A8C518B2208463F87CB30E35F247DD7EACCDB1
	groupXX.net.		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 “dsset-groupXX.net.”
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 groupXX.net | grep DS

3. 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 “db.groupXX.net”;
		file “db.groupXX.net.signed”;
	};

4. 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 groupXX.net
	dig @localhost +trace +dnssec groupXX.net
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 `192.168.100.0/24`.

1. Generate the keys.

	dnssec-keygen –r /dev/urandom –a <algorithm> –b <keysize> \ 
	–n ZONE 100.168.192.in-addr.arpa
	dnssec-keygen –r /dev/urandom –a <algorithm> –b <keysize> \
	–f KSK –n ZONE 100.168.192.in-addr.arpa

2. Sign the zone

	dnssec-signzone -o 100.168.192.in-addr.arpa -N INCREMENT -f <output-file> -t -k \
	K100.168.192.in-addr.arpa.+005+12345 db.192.168.100 K100.168.192.in-addr.arpa.+005+67890

3. Publish the signed zone

	zone “100.168.192.in-addr.arpa” {
		type master;
		# file “db.groupXX.net”;
		file “db.192.168.100.signed”;
	};

4. Verify using dig command.

	dig @localhost +dnssec +multiline 1.100.168.192.in-addr.arpa
	dig –x @localhost 192.168.100.1

#####E. NSEC and NSEC3

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 -r /dev/random -3 <groupXX>
	dnssec-keygen -f ksk -r /dev/random -3 <groupXX>
	

2. Sign the zone with a salt.

	dnssec-signzone -A -3 <salt> -o <zonename> -N INCREMENT \
	-f <output-file> -t -k <KSKfile> <zonefile> <ZSKfile>
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:

	date | sha1sum | cut –b 1-16
	head –c 1000 /dev/random | sha1sum | cut –b 1-16
Example:
	dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b \
	1-16) -o groupXX.net -N INCREMENT -f <output-file> -t -k \ 
	KgroupXX.net.+005+12345 db.groupXX.net KgroupXX.net.+005+67890
To use NSEC3 without a salt, simply use a single `-` (dash). 

	dnssec-signzone -A -3 - -o groupXX.net -N INCREMENT -f <output-file> -t -k \ 
	KgroupXX.net.+005+12345 db.groupXX.net KgroupXX.net.+005+67890

3. Open the signed zonefile (`db.groupXX.net.signed`). Notice that you now have NSEC3 records added with a hash value of the records in the `RDATA`.

bdnog11/netsec/bind-implementing-dnssec.1578825799.txt.gz · Last modified: 2020/01/12 16:43 by Muhammad Moinur Rahman