Configuring DNSSEC on EL6 and bind 9

It looks like there isn’t much in the way of documentation to step people through enabling DNSSEC on their Scientific Linux 6 / CentOS 6 / RHEL6 servers – so as I normally do, I’ve decided to write a quick howto based on MANY searches and trial and error.

1) Firstly, we need to enable dnssec in /etc/named.conf. This will enable the DNSSEC feature set in bind. Check you have the following, or add it if it doesn’t exist:
options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

Restart bind after this via service named restart.

2) Next, we want to go to where your DNS zone file is. I’ve used my domain in this example. We now want to create the Zone Key (ZSK). The directories below will probably be different for your system. It will also take quite a while.
# cd /var/named/chroot/var/named/master
# dnssec-keygen -a RSASHA1 -b 1024 -n ZONE

This will create two files:

  •*.key (public key)
  •*.private (private key)

3) Now we need to create the Secure Entry Key (KSK) for the domain. It also takes quite a while. Go grab a coffee after starting this. Or two.
# dnssec-keygen -a RSASHA1 -b 4096 -n ZONE -f KSK

4) To make the zones use DNSSEC, we need to now add ONLY the public portions of the generated keys to the zone file.
# cat*.key >>

WARNING: For the love of $DEITY, make sure you use >> here so you don’t wipe out your zone file!

5) Next up, signing the zone file and adding the fields required:
# dnssec-signzone -e +3024000 -­N INCREMENT

This signs to zone file with an end time 35 days after the start time. This allows you to automatically resign the domain using a script in /etc/cron.monthly without the domain expiring after 30 days (the default). This will also increment the serial on the zone file automatically (so you don’t forget!).

The result, will be the output file

6) We now have to tell bind to use the new signed zone file in /etc/named.conf. We want to replace the entry that currently refers to the non-signed zone file ( for the signed zone file (
zone "" {
file "/var/named/master/";

7) We are now ready to restart bind to activate the new signed config.
# service named reload

8) Now – this is the tricky part. At the time of writing, AusRegistry does not support DNSSEC for .au domains. You now need to provide your KSK to your registrar to create a chain-of-trust. For people who have domain names, this should be possible. For .au domain names, well, you’re out of luck until AusRegistry pulls its finger out.

Things to be aware of:
1) By default, zone signatures (dnssec-signzone) expire 30 days after the last time they are generated. This tutorial extends this to 35 days to allow you to use a cron to resign the zonefile in the monthly cron. I use a script as follows:
cd /var/named/chroot/var/named/master
service named reload

If you put this script in /etc/cron.monthly/, your zones will be automatically resigned every month.

2) Every time you change a zone file, you have to re-sign it. This can be scripted – however I still do this manually.

3) The current best practice is to generate a new KSK every year, and a new ZSK every 3 months. This is pretty much repeating this guide from step 1. It can probably be scripted – as long as you don’t double up on the public keys being placed in the zone file (step 4).


Skip to comment form

    • Benjamin on February 14, 2013 at 2:50 am
    • Reply

    I did some refinement.

    Default place for dnssec keys in RHEL/CentOS is /etc/pki/dnssec-keys/

    The directory usually does not exist

    mkdir /etc/pki/dnssec-keys/

    Create KSK and ZSK

    cd /etc/pki/dnssec-keys/
    dnssec-keygen -a RSASHA1 -b 1024 -n ZONE
    dnssec-keygen -a RSASHA1 -b 4096 -n ZONE -f KSK

    in your zone file (e.g. the zone file is
    /var/named/domain.tld.hosts) include the public keys:

    $INCLUDE /etc/pki/dnssec-keys/
    $INCLUDE /etc/pki/dnssec-keys/

    advantage is: you don’t need to cat >> and it is probably easier to
    script, if you want to.

    And: /etc/pki/dnssec-keys will automatically be mounted for you when you
    use bind-chroot.

    # signing the zone will be
    cd /var/named
    dnssec-signzone -S -K /etc/pki/dnssec-keys -e +3024000 -o \

    in /etc/named.conf

    zone "" {
    file "";

    Here is a automatically signing script example which can be
    in /etc/cron.monthly
    it only works when the zone was signed manually once.


    for i in *.signed; do
    ZONE=`echo $i | /bin/cut -d. -f1-2`
    $SIGNZONE -S -K $DNSSEC_KEYS -e +3024000 -o $ZONE -N INCREMENT \

    /sbin/service named reload

    1. Hi Benjamin,

      This is GREAT. Sadly, I found out that Australia doesn’t sign the root zones yet – so from my end of things, DNSSEC is not available to use on *.au domains.

      Still, when they eventually get around to doing it, I should be ready 🙂

      • Mark McClelland on April 29, 2015 at 11:15 pm
      • Reply

      That automatic signing script works great, but the second and subsequent time it runs, the serials in the signed zone files end up the same as the first time (INCREMENT just increments the serial in the unsigned file by one). In order to fix that, I changed “INCREMENT” to “UNIXTIME” so that the serials would always be greater than the last time the zones were signed.

    • Kris on July 22, 2013 at 9:22 am
    • Reply

    Finally found an easy guide to follow, however I do have one question, perhaps a good thing to mention in the guide:

    Should I specify the the domain or the zone file when running the dnssec-* commands?


    • ray on October 6, 2013 at 3:04 am
    • Reply

    It seems the config quite straight forward.
    Anyone has any idea what are algorithm involve in this DNSSEC process?
    What are the pre-assessment for DNSSEC deployment? (TLD, ISP, software, hardware)
    appreciate if someone just highlighted the key point for this assessment.

    Thanks in advance.

    • Kris on December 2, 2013 at 4:57 pm
    • Reply

    The algorithm is actually included in the commands used to generate the KSK and ZSK, it’s the parameter followed by the -a (for ‘a’lgorithm).

    I’ve not idea what you mean by “pre-assessment’.

    • Ray on December 3, 2013 at 1:18 am
    • Reply

    Ok got it.
    What I mean, what are the consideration to implement this DNSSEC.
    somehow, the key roll over/maintenance of the key is part of the key process thus I need more information for justification.

    • Kris on December 3, 2013 at 4:47 am
    • Reply

    The primary purpose of dnssec is to act as a safeguard against MITM attacks, e.g. where someone attempts to stick a “fake” DNS server between the real servers and the people trying to access them. You can see the potential “benefits” for hackers: that would allow the hackers to redirect people’s browsers to a server hosting a copy of the webmail site they visit, and configure that server to store the user’s login credentials so that they (the hackers) can use their victim’s email accounts to reset all their passwords, e.g. for online banking and shopping accounts.

    dnssec isn’t full-proof, but it does help reduce the risk. It’s therefor up to you to decide whether or not to worth it: if your site gets enough traffic, then it probably is.

    Remember that you can always automate the entire process using a shell script that gets run via cron at the appropriate times. I’ve been intending to do that myself, so when I get around to writing it I can post my script.

Leave a Reply

Your email address will not be published.