Andrew Hudson - Fedora™ Unleashed, 2008 edition

224.0.0.0/3; # Multicast addresses

/* RFC 1918 addresses may be fake too. Don't list these if you

use them internally. */

10.0.0.0/8;

172.16.0.0/12;

192.168.0.0/16;

};

----------

DNS Security Extensions (DNSSEC), a set of security extensions to the DNS protocol, provides data integrity and authentication by using cryptographic digital signatures. It provides for the storage of public keys in the DNS and their use for verifying transactions. DNSSEC still isn't widely deployed, but BIND 9 does support it for interserver transactions (zone transfers, NOTIFY, recursive queries, dynamic updates). It is worth configuring the transaction signature (TSIG) if your slaves also run BIND 9. We briefly discuss using TSIG for authenticated zone transfers here.

To begin, we use dnssec-keygen, as we did with rndc, to generate a shared secret key. This key is stored on both the master and slave servers. As before, we extract the Key:data from the .privatefile. The following command creates a 512-bit host key named transfer:

----------

$ dnssec-keygen -a hmac-md5 -b 512 -n host transfer

----------

Next we set up matching keystatements in named.conffor both the master and slave servers (similar to the contents of the /etc/rndc.keyfile 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 serverstatement 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-transferdirectives:

----------

server 192.0.2.96 {

key { transfer; };

};

----------

The BIND 9 ARM contains more information on TSIG configuration and DNSSEC support in BIND.

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 split DNS .

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 namedto forward all queries to the firewall and never try to resolve queries themselves. The forward onlyand forwardersoptions in named.confdo 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

► 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 chrootworks 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.hintsis called /var/named/named.cain Fedora.

► http://spf.pobox.com/— The home page of Sender Policy Framework, a method of preventing email address forgery.

► The Concise Guide to DNS and BIND , by Nicolai Langfeldt (Que Publishing, 2000)— An in-depth discussion of both theoretical and operational aspects of DNS administration.

The Lightweight Directory Access Protocol (LDAP, pronounced ell-dap ) is one of those technologies that, although hidden, forms part of the core infrastructure in enterprise computing. Its job is simple: It stores information about users. However, its power comes from the fact that it can be linked into dozens of other services. LDAP can power login authentication, public key distribution, email routing, and address verification and, more recently, has formed the core of the push toward single sign-on technology.

Most people find the concept of LDAP easier to grasp when they think of it as a highly specialized form of database server. Behind the scenes, Fedora uses a database for storing all its LDAP information; however, LDAP does not offer anything as straightforward as SQL for data manipulation!

OpenLDAP uses Sleepycat Software's Berkeley DB (BDB), and sticking with that default is highly recommended. That said, there are alternatives if you have specific needs.

This chapter looks at a relatively basic installation of an LDAP server, including how to host a companywide directory service that contains the names and email addresses of employees. LDAP is a client/server system, meaning that an LDAP server hosts the data and an LDAP client queries it. Fedora comes with OpenLDAP as its LDAP server, along with several LDAP-enabled email clients, including Evolution and Mozilla Thunderbird. This chapter covers all three of these applications.