Basic BIND HOWTO
From Genunix
Setting Up DNS/BIND on a Home Network
DNS, or the Domain Name Service, is the mechanism by which computers find other computers, whether on the local network, or on the Internet.
Setting up a system as a DNS client is relatively simple, and is usually performed during the initial OS installation. Setting up a system as a DNS server is a little more complicated.
Configuring a System as a DNS Client
This document assumes the system was not configured as a DNS client during the OS installation process.
Ensure that the /etc/nsswitch.conf file contains the following line:
hosts: files dns
Note that a hosts: entry might already exist, and just require modification.
The other major file that is required is /etc/resolv.conf. If the file does not exist, create it. If the file does exist, edit it to look similar to the following:
domain yourdomain.com nameserver 123.456.78.9 search yourdomain.com
If you are strictly a client of an ISP, then yourdomain.com is the name of your ISP's domain. The nameserver line points to your ISP's name server. If your ISP has two name servers (and it should), create the resolv.conf file with two nameserver lines, one line for each name server's IP address.
If you have a small home network, and you have your own domain name and name server, the entries must be configured accordingly.
Configuring a System as a DNS Server
A DNS server cannot be set up during installation of the OS. The daemon that provides this service is "named." For clarity, some of the following text will refer directly to this daemon rather than the more generic terms "DNS" or "BIND."
Setting up a DNS server requires more tasks, and some attention to the entire network being served. A DNS server requires zone files, root servers, and so on. The following is a guide for users who are just setting up a small home network.
If the intent is to provide DNS service for a larger network, or to have the DNS server directly on the Internet serving DNS for a proper domain (like an ISP), then you need to read and understand a great deal more documentation. The O'Reilly "DNS and BIND" book by Paul Albitz and Cricket Liu is a good reference but not for beginners. WARNING: As a former ISP employee and a current systems administrator, I've seen my share of ISP's that can't follow the RFC's, general standards, and so on. Make sure you know what you are doing if you want to provide DNS service beyond your home network.
To begin, your /etc/resolv.conf file will look simpler than that for just a client. As with the DNS client setup, this entire document assumes you are using "mydomain.com" for your home network.
domain mydomain.com nameserver 127.0.0.1
The second line instructs your server to ask itself for DNS requests.
For simplicity, put all of your DNS-specific files in one directory. This directory should be in your /etc directory. In this example, all DNS files will be in a directory whose name makes it clear which daemon or service the files relate to:
# mkdir /etc/namedb # cd /etc/namedb
In this directory, you need to build three files. Two are your zone files, and the third is the named configuration file (named.conf). You need to set up both forward and reverse DNS zone files. The forward DNS zone file contains system names and points to the respective systems' IP addresses. The reverse zone file contains IP addresses and points to the host name. Unless both files are correct, with the proper host pointing to the correct IP and the IP pointing to the correct host name, certain services (like Kerberos, for example) will not function correctly.
Because you are setting up a home network and you're never going to share your DNS service with anyone, any short name THAT IS NOT A REAL DOMAIN will do. Do not use a real domain name, like opensolaris.org, because you will confuse your systems. They won't know how to access the Internet and find the real domain.
# vi mydomain.com.hosts
The mydomain.com.hosts file appears similar to the following:
$TTL 12h
@ IN SOA foo.mydomain.com. myname.mydomain.com. (
2007052500 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum
; Name servers
IN NS foo.mydomain.com.
IN NS ns1.yourisp.com.
IN NS ns2.yourisp.com.
; Mail servers
IN MX 5 foo.mydomain.com.
IN MX 10 mail.yourisp.ca.
IN MX 20 uucp.yourisp.ca.
; Individual servers
bar IN A 192.168.0.1
foo IN A 192.168.0.2
andy IN A 192.168.0.3
gamer IN A 192.168.0.4
printer IN A 192.168.0.5
mailhost IN CNAME foo
www IN CNAME foo
sparc IN CNAME andy
The $TTL entry at the beginning of this example instructs the other systems in your home network how long to cache this table for. The SOA (Start Of Authority) entry states which system is the main DNS server for this domain. The serial number needs to be updated every time you change the file, or your DNS reload does nothing (the command silently fails, assuming no changes have been made). Various personal conventions are used for the serial number. The simplist method is to just count up from 1. Another method is to use the date and two spare numbers to assist in keeping track of when the file was last changed. Tabs are typically used to line up the columns neatly.
Notice the three entries in the Name servers section. The first entry is your DNS server. The next two entries list your ISP's DNS servers. These entries are required to properly resolve Internet addresses. Note also the ";" (semicolon) character at the front of the line that just states "Name servers." This comment character instructs the named service to ignore all of the text that follows. Finally, notice that every server name ends with a ".". Without this, your DNS will not work correctly.
Following the name server entries are the entries for your mail servers. This example assumes you host your own mail. Though probably not be the case, it might be a useful way to have a system in your home network that hosts email strictly internal to your network. This setup might be useful, for example, if you have cron jobs that email you if they fail. Setting up a mail server is beyond the scope of this document.
Next, the file lists the systems on your network. Notice the IP addresses used in the example. The 192.168 subnets are non-routable. That means that if a system on the Internet has an IP address in this range, other systems cannot access it. You'll want to use a non-routable address for your private home network. Read the "DNS and BIND" book for a full discussion of network classes and non-routable addresses. The "A" means "Name to Address" mapping. This is the real name returned when you type the hostname command on that system. The first entry (in this case, "bar") is probably your firewall. The .1 address is usually for firewalls, routers, switches, and similar systems. (This is strictly convention; it is not a hard rule.) A proper firewall between your home network and the Internet is strongly recommended, but beyond the scope of this document.
Finally, the example ends with three CNAME entries. These entries contain aliases for the listed server. In this example, if someone tries to access the alias "mailhost" or "www," the DNS service provides the IP address for "foo" (the Canonical name). Similarly, "sparc" returns the IP address for "andy."
Next, set up the reverse DNS zone file:
#vi 0.168.192.in-addr.arpa
This file appears similar to the following example:
$TTL 24h
; 192.168.0.rev
@ IN SOA omar.mydomain.com domreg@mydomain.com (
2007052500
10800
3600
604800
86400 )
IN NS omar.mydomain.com.
1 IN PTR bar.mydomain.com.
2 IN PTR foo.mydomain.com.
3 IN PTR andy.mydomain.com.
4 IN PTR gamer.mydomain.com.
5 IN PTR printer.mydomain.com.
The reverse DNS zone file is fairly similar to the first file. Notice the serial number. In this example, it's the same as the other file, but that need not be the case. You can change one file without changing the other file. For example, if you delete a CNAME in the other file, no changes need to be made in this file. You only have to remember to change the serial number if you change the file.
In this example, the file only includes your name server. Most of the time, you don't need to know what an external IP address' name is. If you do, there are other ways to access that information.
The list of servers is the same as in the forward zone file. In keeping with the reversed function of this zone file, the servers are listed in the opposite format: IP, then name. The PTR indicates this is an address to name pointer. Again, notice the ending dots after the host names.
These two preceeding files should reflect the host names and IP addresses of your home network. Now, your systems need to know how to access systems on the Internet without needing to query your ISP specifically. The last file configures the named daemon directly, instructing the daemon where the zone files are, providing options, and so on.
Instruct the named service how you've set up your DNS:
# vi named.conf
// Refer to the named(8) man page for details.
options {
directory "/etc/namedb";
pid-file "/tmp/named.pid";
// The following entry tells the DNS server to always ask your ISP's
// DNS servers for IP's, rather than going to the root servers. This
// is a good way to go.
forward only;
// Point the following lines at your ISP's DNS servers.
forwarders {
123.456.78.90;
123.456.78.91;
};
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
zone "." {
type hint;
file "named.root";
};
zone "mydomain.com" {
type master;
file "mydomain.com.hosts";
allow-query{192.168.0.0/24;
127.0.0.1;};
};
zone "0.168.192.in-addr.arpa" {
type master;
file "0.168.192.in-addr.arpa";
allow-query {192.168.0.0/24;
127.0.0.1;};
};
If you want details about this file, read the "DNS and BIND" book. For now, just note the use of "//" for comments and the names of the first two files that were created. NOTE: It is a common mistake to use the wrong comment characters in these files, particularly to use the ";" character in this file. You can name the other two files differently (many conventions exist) but the file names must be accurately reflected in this file. Otherwise, the named service won't be able to find them, and your DNS will fail. Also notice that you need to instruct the named service who to serve answers to. In this case, serve DNS requests to the whole 192.168.0.0 class C network as well as the localhost.
If you want to be extremely cautious, download a named.root file from InterNIC (http://www.internic.net). With the above setup, you shouldn't need it, but with a slightly different configuration, you can bypass your ISP's DNS servers. (This is the {type hint; file "named.root"} entry. This is not strictly "polite," as it adds traffic to the root servers and the Internet as a whole. This may be useful if your ISP's name servers have consistent problems. Unless you have such a need, however, do not enable this option.
Finally, a way to start and stop the named service is required.
First, create a special user/group to run the service. Even though this service is running on a private network, running "public" services as a non-root user is a good practice. Add the following line to your /etc/passwd file:
bind:x:53:53:BIND:/:
Add the bind group to the /etc/group file:
bind::53:
Create a directory where bind can write the pid file. The bind user created does not have permissions to write to the standard /var/run directory.
# mkdir -p /var/named/run # chown -R bind:bind /var/named
Edit /var/svc/manifest/network/dns/server.xml. In the method_credential section, change the user and group entries to 'bind.' Also, explicitly set the exec= line to: exec='/usr/sbin/named -u bind'
Make SMF aware of the new manifest:
# svccfg import /var/svc/manifest/network/dns/server.xml
Enable the new manifest:
# svcadm enable dns/server
This shouldn't require a reboot, but if the named service does not start properly, a reboot might be necessary.
If everything was done correctly, you now have a functioning DNS server.
