Generating SIG(0) Keys
SIG(0) keys are generated with the following command:
$ dnssec-keygen -a -b -n HOST
is the desired algorithm of the key and can be any of the following values: RSAMD5, RSASHA1, DSA. We recommend that you use RSAMD5.
is the desired size in bits of the key and the ranges are different depending on the algorithm:
* RSAMD5: 512 to 4096 (recommended size 1024)
* RSASHA1: 512 to 4096 (recommended size 1024)
* DSA: 512 to 1024 (must be divisible by 64, recommended size 1024)
is the name of the key. Since it must be published in the zone file, it should be a subname of the zone that it is being published in. It is recommended that the keyname be the fully qualified domain name of the host so that the update-policy self works correctly. (see Section 6.2.22.4 of the BIND ARM for more information on update-policy).
The key will be stored in the file K++.private
is an identity tag to be able to differentiate between different keys under the same name.
There will also be a corresponding K++.key file that contains a DNS KEY resource record formatted for inclusion in the zone file.
One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy. One solution to this is to use the -r parameter that allows you to specify another random device, such as /dev/urandom.
Configuring the DNS Server
Configuring the server also depends on which type of key you choose.
TSIG Keys
The /etc/named.conf file must be edited to configure the server for dynamic update.
The first step is to configure the server to use the key. This is accomplished with the following lines in the /etc/named.conf file:
key {
algorithm HMAC-MD5;
secret "";
};
is the name of the key chosen when the key was generated (See the previous step, Generating TSIG keys).
is the string after the Key: line in the generated key file (See the previous step, Generating TSIG keys).
SIG(0) Keys
Only the zone file must be edited to configure the server for dynamic update with sig(0). No changes are needed in /etc/named.conf as the client's public, not private, key is in the zone file.
The first step is to add the generated key, using the K++.key file, to the zone file. This generated key file contains a properly formatted resource record that can be simply copy-and-pasted into the zone file.
If you are using DNSSEC signed zones, then the next step is to resign your zone.
Allowing Updates
The final step is to configure the zone to allow updates using the key. The following statements should be added to the zone options block in /etc/named.conf. The simplest configuration is to add:
update-policy {
grant name A TXT;
};
e.g.
zone "example.com" {
type master;
file "master/example.com";
update-policy {
grant foo.example.com. name foo.example.com. A TXT;
};
};
Complex example with a number of hosts allowed to update only their own A+TXT records and one master key allowed to update anything:
update-policy {
grant host1.example.com. name host1.example.com. A TXT;
grant host2.example.com. name host2.example.com. A TXT;
grant host3.example.com. name host3.example.com. A TXT;
grant host4.example.com. name host4.example.com. A TXT;
grant bofh.example.com. subdomain example.com. ANY;
};
Simple example where every key can update the A+TXT records of its matching hostname:
update-policy {
grant * self * A TXT;
};
Note: update-policy is described further in Section 6.2.22.4 of the BIND ARM.
The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended.
allow-update {
key ;
};
is the name of the key chosen when the key was generated (See the previous step, Keys)
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html
2 comments:
I would like to exchange links with your site goodsarves.blogspot.com
Is this possible?
BIND 8.2 introduced a new mechanism for securing DNS messages called transaction signatures, or TSIG for short. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages, particularly responses and updates.
Post a Comment