7.11 Securing Zone Transfers

7.11.1 Problem

You want to secure zone transfers from a name server.

7.11.2 Solution

Use the allow-transfer substatement to specify the addresses of slave name servers allowed to transfer zones. Or, even better, define a TSIG key on the master and slave name servers (see Section 7.10), and specify the TSIG key in the allow-transfer substatement.

allow-transfer can be used as either an options substatement or as a zone substatement. As a zone substatement, allow-transfer applies only to transfers of that zone, and overrides any allow-transfer options substatement for transfers of that zone.

For example, to restrict transfers of the zone foo.example to the slave name server at 192.168.0.2, you might use this zone statement:

zone "foo.example" {
    type master;
    file "db.foo.example";
    allow-transfer { 192.168.0.2; };
};

To restrict transfers of all authoritative zones to slave name servers signing their requests with the TSIG key ns1-ns2.foo.example, you might use the following options statement:

options {
    directory "/var/named";
    allow-transfer { key ns1-ns2.foo.example; };
};

The keyword key is necessary to distinguish the name of the TSIG key from a named ACL.

Obviously, the slave doesn't need any special configuration to initiate its zone transfers from its own address, but it does require configuration to tell it to sign requests with a particular TSIG key. To tell a slave to sign all zone transfer requests to the name server at 192.168.0.1 with the key ns1-ns2.foo.example, you could add the following server statement to named.conf:

server 192.168.0.1 {
    keys ns1-ns2.foo.example;
};

7.11.3 Discussion

For readability's sake, consider defining ACLs with descriptive names even when you're only using IP addresses in your allow-transfer substatements. For example, you could rewrite the zone statement above like so:

acl ns2.foo.example { 192.168.0.2; };

zone "foo.example" {
    type master;
    file "db.foo.example";
    allow-transfer { ns2.foo.example; };
};

Isn't that better?

You can mix IP addresses and TSIG keys in an allow-transfer substatement, too, in which case the individual elements or logically OR'd together.

Restricting zone transfers to a slave name server by both a TSIG key and the slave's address is more difficult than you might imagine. First, define an ACL that matches all IP addresses except the address of the slave:

acl not-ns2.foo.example { !192.168.0.2; any; };

Use the negation of this ACL as the first term of the argument to allow-transfer, and the TSIG key as the second:

options {
    directory "/var/named";
    allow-transfer { !not-ns2.foo.example; key ns1-ns2.foo.example; };
};

The negation operator in the first term tells the name server to deny zone transfers from addresses that match the negated ACL, not-ns2.foo.example, and the negated ACL matches every address but that of the slave. In other words, the first term denies all addresses but the address of the slave. The next term guarantees that only requests from the slave that are signed with the specified TSIG key are permitted; any other requests from the address of the slave are implicitly denied.

Finally, remember that a BIND name server's default is to allow transfers of any zone, so you'll need to deny all transfers on slave name servers that don't serve any other slaves with:

allow-transfer { none; };

7.11.4 See Also

Section 7.10 for instructions on defining TSIG keys and "Preventing Unauthorized Zone Transfers" in Chapter 11 of DNS and BIND.