If you want to secure zone
transfers from a name server, 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, 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;
};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; };The DNS & BIND Cookbook presents solutions to the many problems faced by network administrators responsible for a name server. This title is an indispensable companion to DNS & BIND, 4th Edition, the definitive guide to the critical task of name server administration. The cookbook contains dozens of code recipes showing solutions to everyday problems, ranging from simple questions, like, "How do I get BIND?" to more advanced topics like providing name service for IPv6 addresses.




Help






