DNSSEC is the standard for providing security for your domain name in order to protect it from attackers who want to intercept communications by directing web browsers, email servers, etc. to destinations other than the correct destination. Enabling DNSSEC is actually very straight forward. I’ll explain the steps for those who use BIND to provide DNS services, as that’s one of the most popular DNS servers on the Internet.
The first step is to generate a pair of keys. The first key is called the “Zone Signing Key” (ZSK) and it can be created using this command (replace “example.com” with your domain name):
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com
Next, you need to create a key called the “Key Signing Key” (KSK). It is created using the following command:
dnssec-keygen -a RSASHA1 -b 4096 -n ZONE -f KSK example.com
Note that the -b flag indicates the number of bits of security.
These two commands will produce four files:
- Kexample.com.+005+30578.key
- Kexample.com.+005+30578.private
- Kexample.com.+005+13262.key
- Kexample.com.+005+13262.private
The format of the filenames is “Knnnn+aaa+iiiii.{key|public}”. The value “nnnn” refers to the domain name you are securing. The value “aaa” refers to the cryptographic algorithm used. In the example above, 005 refers to RSA/SHA-1 (per RFC 4034). The “iiiii” is a key identifier, which is just a 16-bit value that identifies this particular key for this particular domain.
Next, you concatenate the .key files to the end of your zone file, like this:
cat Kexample.com.+005+30578.key Kexample.com.+005+13262.key >>example.com.zone
Now, you have to “sign” your zone file like this. To do that, you need to identify which of the keys refers to your KSK and ZSK. If you took notice of the file names created after executing the key creation commands above, you’d know. Otherwise, just look at the file in a text editor and you’ll see which one. In our example, we’ll assume that “Kexample.com.+005+30578” is the ZSK and “Kexample.com.+005+13262” is the KSK. You’ll then execute this command:
/usr/sbin/dnssec-signzone –o example.com -N keep -k Kexample.com.+005+13262 example.com.zone Kexample.com.+005+30578
This will result in the creation of a file called “example.com.zone.signed”.
Now, you just have to make a few small adjustments to the /etc/resolv.conf file. Here are the important changes:
options {
...
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
...
}
...
include "/etc/named.root.key";
...
zone "example.com" IN {
type master;
file "example.com.zone.signed";
allow-update { "none"; };
};
...
Place both the example.com.zone and example.com.zone.signed into the directory where BIND keeps its zone files. Restart named and/or issue these commands:
/usr/sbin/rndc reload
/usr/sbin/rndc flush
At this point, your DNS server is ready to go. However, your registrar must have an appropriate “glue” records in place. Usually, these records are DS records. Fortunately, those records are generated for you automatically by the “dnssec-signzone” command. You will see a file called “dsset-example.com.” with the DS records inside. All you have to do is insert those into your registrar’s DNS, much like you might assign your name servers. The procedures for doing this vary by registrar, so I cannot explain the procedure. However, it’s not so hard once you find the right place. The registrar should validate that everything is working properly before activating the DS records. One would not want an incorrect record in place, as that would break the trust chain established via DNSSEC and thereby “break” the domain resolution.
ICANN has list of registrars now supporting DNSSEC. Not all of them do and they certainly do not support DNSSEC for all TLDs. So, it is best to check with your registrar before going through all of the steps and being disappointed.
If you wish to validate that DNSSEC is working properly, you can use the “dig” command on Linux machines like this:
dig +topdown +sigchase example.com
That command will report success or failure in the trust chain. Alternatively, visit DNSSECReport.com and perform a basic test via the web.
One last point to make is that it is recommended that you re-sign your domain at least every 30 days. It's not necessary to generate new keys, but merely re-sign the zone file. (Note that if you did decide to change the key used to sign the domain that you need to ensure that you properly handle the key rollover. Otherwise, for a period of time some DNS servers might assume your domain's signature is invalid. DNSSEC Key rollover is a whole other topic.)