DNSSEC Part II: the Implementation
This article is the second in a series on DNSSEC. In the first one, I gave a general overview of DNSSEC concepts to lay the foundation for this article, which discusses how to enable DNSSEC for a zone using BIND. If you want to deploy DNSSEC but aren't sure what I mean when I say KSK, ZSK, DLV or DS record, you may want to go back to Part I to refresh yourself on the concepts, because in this article, I'm going to dive right in to implementation.
Adding DNSSEC to a zone using BIND involves a few extra steps on top of what you normally would do to configure BIND as a master for your zone. First, you will need to generate a Key-Signing Key (KSK) and Zone-Signing Key (ZSK), then update the zone's config and sign it with the keys. Finally, you will reconfigure BIND itself to support DNSSEC. After that, your zone should be ready, so if your registrar supports DNSSEC, you can update it or otherwise use DLV with a provider like dlv.isc.org. Now, let's look at the steps in more detail using my greenfly.org zone as an example.
Make the Keys
The first step is to generate the KSK and ZSK for your zone. As I mentioned in my
previous article, the KSK is used only to sign ZSKs in the zone and to provide a
signature for the zone's parent to sign, while ZSKs sign the records in each
zone. Having separate keys also allows you to create a stronger KSK and have a
weaker ZSK that you can rotate out each month. So first, let's create a KSK for
$ cd /etc/bind/ $ dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK greenfly.org
By default, the
dnssec-keygen command dumps the generated keys in the current
directory, so change to the directory in which you store your BIND
-b arguments set the algorithm (RSASHA1) and key
size (2048 bit), while the
-n option tells
dnssec-keygen what kind of key it is
creating (a ZONE key). You also can use
dnssec-keygen to generate keys for DDNS
and other BIND features, so you need to be sure to specify this is for a zone. I
also added a
-f KSK option that tells
dnssec-keygen to set a bit that denotes
this key as a KSK instead of a ZSK. Finally, I specified the name of the zone this
key is for: greenfly.org. This command should create two files: a .key file, which
is the public key published in the zone, and a .private file, which is the private
key and should be treated like a secret. These files start with a K, then the
name of the zone, and then a series of numbers (the latter of which is
randomly generated), so in my case, it created two files:
Kgreenfly.org.+005+10849.key and Kgreenfly.org.+005+10849.private.
Next I need to create the ZSK. The command is very similar to the command to
create the KSK, except I lower the bit size to 1024 bits, and I remove the
$ dnssec-keygen -a RSASHA1 -b 1024 -n ZONE greenfly.org
This command creates two other key files: Kgreenfly.org.+005+58317.key and Kgreenfly.org.+005+58317.private. Now I'm ready to update and sign my zone.
Update the Zone File
Now that each key is created, I need to update my zone file for greenfly.org (the
file that contains my SOA, NS, A and other records) to include the public KSK and
ZSK. In BIND, you can achieve this by adding
$INCLUDE lines to the end of your
zone. In my case, I added these two lines:
$INCLUDE Kgreenfly.org.+005+10849.key ; KSK $INCLUDE Kgreenfly.org.+005+58317.key ; ZSK
Sign the Zone
Once the keys are included in the zone file, you are ready to sign the zone
itself. You will use the
dnssec-signzone command to do this:
$ dnssec-signzone -o greenfly.org -k Kgreenfly.org.+005+10849 \ db.greenfly.org Kgreenfly.org.+005+58317.key
In this example, the
-o option specifies the zone
origin, essentially the
actual name of the zone to update (in my case, greenfly.org). The
-k option is
used to point to the name of the KSK to use to sign the zone. The last two
arguments are the zone file itself (db.greenfly.org) and the name of the ZSK file
If you are using DLV, you will add an extra
-l option to specify the DLV server
you are using:
$ dnssec-signzone -l dlv.isc.org -o greenfly.org -k \ Kgreenfly.org.+005+10849 db.greenfly.org \ Kgreenfly.org.+005+58317.key
In either case, the command will create a new .signed zone file (in my case,
db.greenfly.org.signed) that contains all of your zone information along with a
lot of new DNSSEC-related records that list signatures for each RRSET in your
zone. If you aren't using DLV, it also will create a dsset-zonename file that
contains a DS record you will use to get your zone signed by the zone parent. If
you are using DLV, you will get a dlvset-zonename file. Any time you make a
change to the zone, simply update your regular zone file like you normally would,
then run the
dnssec-signzone command to create an
updated .signed file. Some
administrators recommend even putting the
dnssec-signzone command in a cron job
to run daily or weekly, as by default the key signatures will expire after a
month if you don't run
dnssec-signzone in that time.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide