Knowledge Base ISC Main Website Ask a Question/Contact ISC
Inline Signing in ISC BIND 9.9.0 -- Examples
Author: Evan Hunt Reference Number: AA-00626 Views: 16954 Created: 2012-02-24 16:34 Last Updated: 2013-03-06 09:08 100 Rating/ 3 Voters

When DNSSEC was first introduced, the only way to sign DNS data was using the 'dnssec-signzone' utility; this would take an unsigned zone file and generate a new zone file containing signatures.  This file would be loaded by named and served the same as any other zone file.  Because DNSSEC signatures expire, the zone would have to be periodically resigned and reloaded.

Later, named acquired the ability to sign zones internally.  The master server for a zone could now add and remove keys and generate and regenerate DNSSEC signatures automatically, remaining up to date without operator intervention.  This required the zone to be configured as dynamic, however, which is incompatible with some existing DNS configurations, such as zones which are transferred from a provisioning database, are served from a master server not running BIND 9, or which need to be static.

With the release of BIND 9.9, ISC introduces a new "inline-signing" option for BIND 9, which allows named to sign zones completely transparently.  A server can load or transfer an unsigned zone, and create a signed version of it which answers all queries and transfer requests, without altering the original unsigned version.  As the unsigned zone is updated, named will detect the changes that are made to it, and apply those changes to the signed version.  This allows a seamless transition to DNSSEC with minimal disruption to existing systems.

EXAMPLE 1: MASTER SERVER

We begin with a master zone, served by a BIND 9 server on address 10.10.10.4.  The zone data is stored on disk in a conventional zone file, and initially it is not signed.  There are three slaves, 10.10.10.1, 10.10.10.2, and 10.10.10.3.  All four authoritative servers can be queried.

We can enable DNSSEC signing by upgrading the master server to BIND 9.9 and turning on inline-signing:


        In the file example.com.db:


    $ORIGIN example.com.
    $TTL 300
    @ IN SOA ns1.example.com. hostmaster.example.com. (
                                    2012022301 1800 1800 1814400 3600
                              )
          NS ns1.example.com.
          NS ns2.example.com.
          NS ns3.example.com.
          NS ns4.example.com.

    ns1.example.com. IN A 10.10.10.1
    ns2.example.com. IN A 10.10.10.2
    ns3.example.com. IN A 10.10.10.3
    ns4.example.com. IN A 10.10.10.4

    ; ... more zone data

The named.conf configuration for the master zone is as follows:

        zone example.com {
            type master;
            file "/etc/bind/master/example.com.db";
            allow-transfer { localhost; 10.10.10.1; 10.10.10.2; 10.10.10.3; }
        };

To enable DNSSEC, first we need to generate two DNSSEC keys, one with and one without the KSK flag:

        $ mkdir /etc/bind/keys
        $ cd /etc/bind/keys
        $ dnssec-keygen example.com
        Generating key pair.....................++++++
        ...............++++++ 
        Kexample.com.+005+08160
        $ dnssec-keygen -fk example.com
        Generating key pair.....................................+++
        .............................................................+++ 
        Kexample.com.+005+19273

We add a few lines to the zone options in named.conf:

        zone example.com {
            type master;
            file "/etc/bind/master/example.com.db";
            allow-transfer { localhost; 10.10.10.1; 10.10.10.2; 10.10.10.3; };

            # look for dnssec keys here:
            key-directory "/etc/bind/keys";

            # publish and activate dnssec keys:
            auto-dnssec maintain;

            # use inline signing:
            inline-signing yes;
        };

And reset the server configuration:

        $ ls
        example.com.db
        $ rndc reconfig
        $ cd /etc/bind/master
        $ ls
        example.com.db  example.com.db.signed  example.com.db.signed.jnl

The new files "example.com.db.signed" and "example.com.db.signed.jnl" contain the DNSSEC-signed version of the zone; "example.com.db" retains the unsigned version..

The new "rndc signing -list" command can be used to confirm that the new zone has been fully signed:

        $ sbin/rndc signing -list example.nil
        Done signing with key 8160/RSASHA1
        Done signing with key 19273/RSASHA1

And we can confirm that named is serving the signed data by querying directly:

        $ dig +dnssec +noall +answer @localhost -t SOA example.com
        example.com.            300     IN      SOA     ns1.example.com.
        hostmaster.example.com. 2012022304 2000 2000 1814400 3600
        example.com.            300     IN      RRSIG   SOA 7 2 60
        20120325012742 20120224002742 8160 example.nil.
        he6IjhV2x330PhpsvynsCsFahDyxfXawtfrO70A4rn4x+q09tRPd2FWQ
        z0SZlxOBbqfPxx5bNV8kY4rFh/5s0AXN1DSHiWD6+PMpSsrFkb4b7D16
        brAIhNGZzqwTNwjqACB8Zfiv70wb9qWGsQV1z6U0s6/Eez7DTaEtRPN4 OWE=

Note that the serial number in this response is not the same as the one in the file example.com.db.  Named keeps track of the serial number of the signed version of the zone independently of the unsigned version.  If the unsigned zone is updated with a new serial number that's higher than the one in the signed copy, then the signed copy will be increased to match it, but otherwise the two are kept separate.

There is no need to configure example.com as a dynamic zone; there are no 'update-policy' or 'allow-update' statements in the above zone options.  The "example.com.db" file is never modified by this process.  Before, named could only use one file for a given zone; if it was configured for automatic DNSSEC maintenance, the file would be overwritten with a fresh copy of the zone whenever the signatures were updated.  Any comments in the file would be obliterated.  This is no longer the case; signed DNS data is stored in example.com.db.signed and in the associated journal file, not in the original zone file.

These files are not human readable: for faster loading, the signed data is stored in raw (binary) format.  To examine it, you can use the 'named-checkzone' command to dump the zone contents as text:

        $ named-checkzone -D -f raw -o - example.com example.com.db.signed

... or simply look at the zone with 'dig':

        $ dig @localhost axfr example.com

EXAMPLE 2: SLAVE SERVER, USING HIDDEN MASTER

Again, we have a master server and three slaves.  Unlike the previous example, this is a "hidden master" configuration, in which only the slave servers are accessible to the global internet; 10.10.10.4 allows the slaves to transfer the zone from it, but it does not answer queries.

We wish to enable DNSSEC without modifying the master server's configuration at all.  It may, for example, be a provisioning system not running BIND 9, but only providing DNS data via zone transfer to the slaves, and enabling DNSSEC on it is not practical.  Using inline-signing, we can place a "bump in the wire" signing server between the master and the slaves:


The slaves' configuration initially looks like this:

        zone example.com {
            type slave;
            masters { 10.10.10.4; };
            file "/etc/bind/slave/example.com.bk";
        };

To enable DNSSEC, we bring up a new BIND 9.9 server on the address 10.10.10.5.  The existing master server must be configured to allow transfers to this address.

As in example 1, we create DNSSEC keys:

        $ mkdir /etc/bind/keys
        $ cd /etc/bind/keys
        $ dnssec-keygen example.com
        Generating key pair........................+++++
        ...............++++++ 
        Kexample.com.+005+17262
        $ dnssec-keygen -fk example.com
        Generating key pair.....................................+++++
        ........................................................+++ 
        Kexample.com.+005+44139

We configure named to slave to the existing master server, but with inline-signing turned on:

        zone example.com {
            type slave;
            masters { 10.10.10.4; };
            file "/etc/bind/slave/example.com.bk";

            # look for dnssec keys here:
            key-directory "/etc/bind/keys";

            # publish and activate dnssec keys:
            auto-dnssec maintain;

            # use inline signing:
            inline-signing yes;
        };

When the new server is started, it will transfer a copy of the example.com domain from 10.10.10.4.  It will keep a copy of this unsigned version of the zone, and create a signed version internally.  You can verify the correctness of the DNSSEC data by querying the local server, as we saw in example 1.

At this point you can take as long as you wish to confirm that 10.10.10.5 is now serving a signed version of the zone, that it properly detects changes to the zone, that signatures are being properly maintained, etc.  Once you are completely satisfied, you make the signed data public by reconfiguring the existing slave servers so that they treat the new server as master for the example.com domain:

        zone example.com {
            type slave;
            masters { 10.10.10.5; };               # Formerly 10.10.10.4!
            file "/etc/bind/slave/example.com.bk";
        };

After each slave's configuration is reset with "rndc reconfig", it will transfer a new copy of the zone, but from the signing server instead of from the hidden master. The DNSSEC-signed version of the zone is now being publicly served, with very little disruption to existing processes.

© 2001-2014 Internet Systems Consortium

Feedback 8
  • #
    [Tuan Vo]: The dnssec-keygen will be running so slow if we input only domain name 2014-01-02 10:07

    Anyone see if the dnssec-keygen works very slow on Centos if we run it with domain name only? From this article example:
    $ dnssec-keygen example.com
    Generating key pair........................+++++
    ...............++++++
    Kexample.com.+005+17262
    $ dnssec-keygen -fk example.com
    Generating key pair.....................................+++++
    ........................................................+++
    Kexample.com.+005+44139
    I tried them and saw that dnssec-keygen works so slow. If I add another option argument (example: dnssec-keygen -r random.data example.com), it work immediately. It does not happen on Windows.
    After trying to debug, I see it stick around the RSA_generate_key_ex(rsa, key->key_size, e, &cb)) in the lib\dns\opensslrsa_link.c
    Do you have any ideas?

  • #
    [Cathy Almond]: Re: The dnssec-keygen will be running so slow if we input only domain name 2014-01-08 08:39

    Your problem is most likely a lack of entropy (i.e. /dev/random is blocking while it waits for more 'randomness' to be generated by system activity) - this is a common problem, particularly if running in a virtual environment.

    A short term solution (but one that is not recommended in production, because it's not truly random) is to use instead /dev/urandom. Longer term look at using a hardware entropy generator (these are often available as a small USB plugin or similar). There are also some software-based options available.

  • #
    [Robert Kulp]: Multiple zones w/same file? 2013-10-24 19:38

    Anyone know if this works if the master server has multiple zones that use the same zone file? For example: Three identical domains - example.com, example.net, and example.org share a common zone file, example.com.db. Will DNSSEC work with each of these or are separate zone files needed (example.com.db, example.net.db, and example.org.db)?

    Thanks - Robert

  • #
    [Cathy Almond]: Re: Multiple zones w/same file? 2013-10-29 17:25

    You need unique file names for the zone data files when you deploy DNSSEC with inline-signing.

    Where the inline-signing is implemented on a master, named will load the unsigned zone data from your non-unique file OK - but after signing, it needs to create a new zone data file for each zone. The name chosen is the name of the original file (from the zone statement), suffixed with "-signed". At this point you will have a filename collision between the zones.

    If you're implementing inline-signing via a slave - you are required to specify a filename for the zone and the same filename collision will occur after signing.

    And additionally, even without inline-signing, it has always been the case that slave servers cannot share the same file between zones. When refreshing the zone from the master, a slave named transfers the zone data directly into its working memory, and then afterwards backs it up to disk. In that situation, each zone will write to the same file, but with its own zone data replacing that which had been written by another zone.

  • #
    [ marcelloc]: slave servers key transfering 2013-10-23 20:06

    How are keys copied/synced to slave servers?

  • #
    [Cathy Almond]: Re: slave servers key transfering 2013-10-24 12:17

    DNSSEC keys are a private/public pair. DNSSEC-signing uses the private/secret keys and takes place only on the master server. There is no reason for a slave server to hold the private key(s). The public keys for a zone are published in the zone itself as DNSKEY records. They will be included in the zone transfers from master to slave.

  • #
    [Harald A. Irmer]: Thanks for the article - but what about key expiration? 2013-03-08 15:38

    After "generate two DNSSEC keys, one with and one without the KSK flag" can I leave the system alone - at least for key production - which would be very fine, or have I to take care for periodical key renewing? If necessary, what are the rules for key renewing, to set up scripts e.g., please?

  • #
    [Cathy Almond]: Re: Thanks for the article - but what about key expiration? 2013-10-10 12:47

    Once you have configured BIND so that your signatures are refreshed automatically, in theory you don't need to do anything and could keep your keys indefinitely. But it is good practice to change your keys periodically to make it harder for potential attackers. For information on managing key rollovers, please see section 4.8.5 of the BIND 9.9 ARM, and also the article https://kb.isc.org/article/AA-00822 "Automatic DNSSEC Zone Signing Key rollover explained" (you will need to register to view this).

Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu