DNSSEC Guide : Chapter 7. Recipes

In this recipe, our servers are illustrated as shown in Figure 7.1, “Inline Signing Recipe #1”: we have a master server 192.168.1.1 and three slave servers (192.168.1.2, 192.168.1.3, and 192.168.1.4) that receive zone transfers. In order to get the zone signed, we need to reconfigure the master server, as described in the section called “Easy Start Guide for Signing Authoritative Zones”. Once reconfigured, a signed version of the zone is generated on the fly by inline-signing, and zone transfers will take care of synchronizing the signed zone data to all slave name servers, without configuration or software changes on the slave servers.

Figure 7.1. Inline Signing Recipe #1

Below is what the named.conf looks like on the master server, 192.168.1.1:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

On the slave servers, named.conf does not need to be updated, and it looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.1; };
};

In fact, the slave servers do not even need to be running BIND, it could be running any other DNS product that has DNSSEC support.

In this recipe, we are taking advantage of the power of inline signing by placing an additional name server 192.168.1.5 between the hidden master (192.168.1.1) and the DNS slaves (192.168.1.2, 192.168.1.3, and 192.168.1.4). The additional name server 192.168.1.5 acts as a "bump in the wire", taking unsigned zone from the hidden master on one end, and sending out signed data on the other end to the slave name servers. The steps described in this recipe may be used as part of the DNSSEC deployment strategy, since it requires minimal changes made to the existing hidden DNS master and DNS slaves.

Figure 7.2. Inline Signing Scenario #2

It is important to remember that 192.168.1.1 in this case is a hidden master not exposed to the world, it must not be listed in the NS RRset. Otherwise the world will get conflicting answers, unsigned answers from the hidden master, and signed answers from the other name servers.

The only configuration change needed on the hidden master 192.168.1.1 is to make sure it allows our middle box to perform a zone transfer:

zone "example.com" IN {
    ...
    allow-transfer { 192.168.1.5; };
    ...
};

On the middle box 192.168.1.5, all the tasks described in the section called “Easy Start Guide for Signing Authoritative Zones” still need to be performed, such as generating key pairs and uploading information to parent zone. This server is configured as slave to the hidden master 192.168.1.1, receiving the unsigned data, and then using keys accessible to this middle box, sign data on the fly, and send out the signed data via zone transfer to the other three DNS slaves. Its named.conf looks like this:

zone example.com {
    type slave;
    masters { 192.168.1.1; };
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

Finally, on the three slave servers, configuration should be updated to receive zone transfer from 192.168.1.5 (middle box) instead of 192.168.1.1 (hidden master). If using BIND, the named.conf looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.5; };   # this was 192.168.1.1 before!
};