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 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 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.
► 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.
CHAPTER 24
LDAP
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.
Because LDAP data is usually available over the Internet — or at least your local network — it is imperative that you make every effort to secure your server. This chapter gives specific instruction on password configuration for OpenLDAP, and we recommend you follow our instructions closely.
Configuring the Server
If you have been using LDAP for years, you are aware of its immense power and flexibility. On the other hand, if you are just trying LDAP for the first time, it will seem like the most broken component you could imagine. LDAP has very specific configuration requirements, is vastly lacking in graphical tools, and has a large number of acronyms to remember. On the bright side, all the hard work you put in will be worth it because, when it works, LDAP will hugely improve your networking experience.
The first step in configuring your LDAP server is to install the client and server applications. Select Add/Remove Applications, click the Details button next to Network Servers, and check openldap-servers. Then click the Details button next to System Tools and select openldap-clients. After you have installed them, close the dialog box and bring up a terminal.
Now switch to the root user and edit /etc/openldap/slapd.conf in the text editor of your choice. This is the primary configuration file for slapd, the OpenLDAP server daemon. Scroll down until you see the lines database, suffix, and rootdn.
This is the most basic configuration for your LDAP system. What is the name of your server? The dc stands for domain component, which is the name of your domain as stored in DNS — for example, example.com. For our examples, we used hudzilla.org. LDAP considers each part of a domain name (separated by a period) to be a domain component, so the domain hudzilla.org is made up of a domain component hudzilla and a domain component org.