named transfer:
----------
$ dnssec-keygen -a hmac-md5 -b 512 -n host transfer
----------
Next we set up matching key statements in named.conf for both the master and slave servers (similar to the contents of the /etc/rndc.key file created earlier). Remember not to transfer the secret key from one machine to the other over an unsecure channel. Use ssh, sftp (secure FTP), or something similar. Remember also that the shared secrets shouldn't be stored in world-readable files. The statements, identical on both machines, would look something similar to this:
----------
key transfer {
algorithm 'hmac-md5';
secret '...'; # Key from .private file
};
----------
Finally, we set up a server statement on the master to instruct it to use the key we just created when communicating with the slave, and to enable authenticated zone transfers with the appropriate allow-transfer directives:
----------
server 192.0.2.96 {
key { transfer; };
};
----------
The BIND 9 ARM contains more information on TSIG configuration and DNSSEC support in BIND.
Using Split DNS
BIND is often run on firewalls—both to act as a proxy for resolvers inside the network and to serve authoritative data for some zones. In such situations, many people prefer to avoid exposing more details of their private network configuration via DNS than is unavoidable (although there is some debate about whether this is actually useful). Those accessing your system from outside the firewall should see only information they are explicitly allowed access to, whereas internal hosts are allowed access to other data. This kind of setup is called
Suppose that you have a set of zones you want to expose to the outside world and another set you want to allow hosts on your network to see. You can accomplish that with a configuration such as the following:
----------
acl private {
localhost; 192.168.0.0/24;
# Define your internal network suitably.
};
view private_zones {
match { private; };
recursion yes;
# Recursive resolution for internal hosts.
zone internal.zone {
# Zone statements;
};
# More internal zones.
};
view public_zones {
match { any; }
recursion no;
zone external.zone {
# Zone statements;
};
# More external zones.
};
----------
Further, you might want to configure internal hosts running named to forward all queries to the firewall and never try to resolve queries themselves. The forward only and forwarders options in named.conf do this. (forwarders specifies a list of IP addresses of the nameservers to forward queries to.)
The BIND 9 ARM discusses several details of running BIND in a secure split-DNS configuration.
You can use the following commands to manage DNS in Fedora:
> dig — The domain information groper command, used to query remote DNS servers
> host — A domain nameserver query utility
> named — A domain nameserver included with Fedora
> system-config-bind — A GUI tool to configure DNS information
> nsupdate — A Dynamic DNS update utility
> rndc — The nameserver control utility included with BIND
Reference
> http://www.dns.net/dnsrd/ — The DNS resources database.
> http://www.isc.org/products/BIND/ — The ISC's BIND web page.
> http://www.bind9.net/manuals — The BIND 9 Administrator Reference Manual.
> http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Chroot-BIND- HOWTO.html — A guide to how chroot works with BIND 9.
> http://langfeldt.net/DNS-HOWTO/ — The home page of the DNS HOWTO for BIND versions 4, 8, and 9.
> http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/DNS- HOWTO.html#s3 — Setting up a resolving, caching nameserver. Note that the file referenced as /var/named/root.hints is called /var/named/named.ca in Fedora.
> http://spf.pobox.com/ — The home page of Sender Policy Framework, a method of preventing email address forgery.
>
