Jan. 13, 2010, 11:04 p.m.
posted by whitehat
Configuring a Regular Name ServerFor the purposes of this tutorial, assume your ISP assigned you the subnet 97.158.253.24 with a subnet mask of 255.255.255.248 (/29). Configuring resolv.confYou'll have to make your DNS server refer to itself for all DNS queries by configuring the /etc/resolv.conf file to reference localhost only.
nameserver 127.0.0.1
Configuring named.confThe named.conf file contains the main DNS configuration and tells BIND where to find the configuration files for each domain you own. This file usually has two zone areas:
In this example, you'll set up the forward zone for www.my-web-site.org by placing entries at the bottom of the named.conf file. The zone file is named my-site.zone, and, although not explicitly stated, the file my-site.zone should be located in the default directory of /var/named/chroot/var/named in a chroot or in /var/named in a regular one. Use the code:
zone "my-web-site.org" {
type master;
notify no;
allow-query { any; };
file "my-site.zone";
};
In addition, you can insert additional entries in the named.conf file to reference other Web domains you host. Here is an example for another-site.com using a zone file named another-site.zone:
zone "another-site.com" {
type master;
notify no;
allow-query { any; };
file "another-site.zone";
};
Next, you have to format entries to handle the reverse lookups for your IP addresses. In most cases, your ISP handles the reverse zone entries for your public IP addresses, but you will have to create reverse zone entries for your SOHO/home environment using the 192.168.1.0/24 address space. This isn't important for the Windows clients on your network, but some Linux applications require valid forward and reverse entries to operate correctly. The forward domain lookup process for mysite.com scans the FQDN from right to left to get increasingly more specific information about the authoritative servers to use. Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about an address. The similarity in both methods is that increasingly specific information is sought, but the noticeable difference is that for forward lookups the scan is from right to left, and for reverse lookups the scan is from left to right. This difference can be seen in the formatting of the zone statement for a reverse zone in /etc/named.conf file where the main in-addr.arpa domain, to which all IP addresses belong, is followed by the first three octets of the IP address in reverse order. This order is important to remember or else the configuration will fail. This reverse zone definition for named.conf uses a reverse zone file named 192-168-1.zone for the 192.168.1.0/24 network:
zone "1.168.196.in-addr.arpa" {
type master;
notify no;
file "192-168-1.zone";
};
Configuring the Zone FilesYou need to keep a number of things in mind when configuring DNS zone files:
Time to Live ValueThe very first entry in the zone file is usually the zone's time to live (TTL) value. Caching DNS servers cache the responses to their queries from authoritative DNS servers. The authoritative servers not only provide the DNS answer but also provide the information's time to live, which is the period for which it's valid. The purpose of a TTL is to reduce the number of DNS queries the authoritative DNS server has to answer. If the TTL is set to three days, then caching servers use the original stored response for three days before making the query again:
$TTL 3D
BIND recognizes several suffixes for time-related values. A D signifies days, a W signifies weeks, and an H signifies hours. In the absence of a suffix, BIND assumes the value is in seconds. DNS Resource RecordsThe rest of the records in a zone file are usually BIND resource records. They define the nature of the DNS information in your zone files that's presented to querying DNS clients. They all have the general format:
Name Class Type Data
There are different types of records for mail (MX), forward lookups (A), reverse lookups (PTR), aliases (CNAME) and overall zone definitions, Start of Authority (SOA). The data portion is formatted according to the record type and may consist of several values separated by spaces. Similarly, the name is also subject to interpretation based on this factor. The SOA RecordThe first resource record is the SOA record, which contains general administrative and control information about the domain. It has the format:
Name Class Type Name-Server Email-Address Serial-No Refresh Retry
Expiry Minimum-TTL
The record can be long, and will sometimes wrap around on your screen. For the sake of formatting, you can insert new line characters between the fields as long as you insert parenthesis at the beginning and end of the insertion to alert BIND that part of the record will straddle multiple lines. You can also add comments to the end of each new line separated by a semicolon when you do this. Here is an example:
@ IN SOA ns1.my-web-site.org. hostmaster.my-web-site.org. (
2004100801 ; serial #
4H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
Figure explains what each field in the record means. So in the example, the primary name server is defined as ns1.my-web-site.org with a contact e-mail address of hostmaster@my-web-site.org. The serial number is 2004100801 with refresh, retry, expiry, and minimum values of 4 hours, 1 hour, 1 week, and 1 day, respectively. NS, MX, A, PTR, and CNAME RecordsLike the SOA record, the NS, MX, A, PTR, and CNAME records each occupy a single line with a very similar general format. Figure outlines the way they are laid out.
If you don't put a period at the end of a host name in a SOA, NS, A, or CNAME record, BIND will automatically tack on the zone file's domain name to the name of the host. So, BIND assumes an A record with www refers to www.my-web-site.org. This may be acceptable in most cases, but if you forget to put the period after the domain in the MX record for my-web-site.org, BIND attaches the my-web-site.org at the end, and you will find your mail server accepting mail only for the domain my-web-site.org.mysite.com. Sample Forward Zone FileNow that you know the key elements of a zone file, it's time to examine a working example for the domain my-web-site.org:
;
; Zone file for my-web-site.org
;
; The full zone file
;
$TTL 3D
@ IN SOA ns1.my-web-site.org. hostmaster.my-web-
site.org. (
200211152 ; serial#
3600 ; refresh, seconds
3600 ; retry, seconds
3600 ; expire, seconds
3600 ) ; minimum, seconds
;
NS www ; Inet Address of nameserver
my-web-site.org. MX 10 mail ; Primary Mail Exchanger
;
localhost A 127.0.0.1
bigboy A 97.158.253.26
mail CNAME bigboy
ns1 CNAME bigboy
www CNAME bigboy
Notice that in this example:
It is a required practice to increment your serial number whenever you edit your zone file. When DNS is set up in a redundant configuration, the slave DNS servers periodically poll the master server for updated zone file information, and use the serial number to determine whether the data on the master has been updated. Failing to increment the serial number, even though the contents of the zone file have been modified, could cause your slaves to have outdated information. Sample Reverse Zone FileNow you need to make sure that you can do a host query on all your home network's PCs and get their correct IP addresses. This is very important if you are running a mail server on your network, because sendmail typically relays mail only from hosts whose IP addresses resolve correctly in DNS. NFS, which is used in network-based file access, also requires valid reverse lookup capabilities. This is an example of a zone file for the 192.168.1.x network. All the entries in the first column refer to the last octet of the IP address for the network, so the IP address 192.168.1.100 points to the name bigboy.my-web-site.org. Notice how the main difference between forward and reverse zone files is that the reverse zone file only has PTR and NS records. Also the PTR records cannot have CNAME aliases.
;
; Filename: 192-168-1.zone
;
; Zone file for 192.168.1.x
;
$TTL 3D
@ IN SOA www.my-web-site.org. hostmaster.my-web-
site.org. (
200303301 ; serial number
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
NS www ; Nameserver Address
;
100 PTR bigboy.my-web-site.org.
103 PTR smallfry.my-web-site.org.
102 PTR ochorios.my-web-site.org.
105 PTR reggae.my-web-site.org.
32 PTR dhcp-192-168-1-32.my-web-site.org.
33 PTR dhcp-192-168-1-33.my-web-site.org.
34 PTR dhcp-192-168-1-34.my-web-site.org.
35 PTR dhcp-192-168-1-35.my-web-site.org.
36 PTR dhcp-192-168-1-36.my-web-site.org.
I included entries for addresses 192.168.1.32 to 192.168.1.36, which are the addresses the DHCP server issues. SMTP mail relay wouldn't work for PCs that get their IP addresses via DHCP if these lines weren't included. You may also want to create a reverse zone file for the public NAT IP addresses for your home network. Unfortunately, ISPs won't usually delegate this ability for anyone with less than a Class C block of 256 IP addresses. Most home DSL sites wouldn't qualify. What You Need to Know About NAT and DNSThe previous examples assume that the queries will be coming from the Internet with the zone files returning information related to the external 97.158.253.26 address of the Web server. What do the PCs on your home network need to see? They need to see DNS references to the real IP address of the Web server, 192.168.1.100, because NAT won't work properly if a PC on your home network attempts to connect to the external 97.158.253.26 NAT IP address of your Web server. Don't worry. BIND has a way around this called views. The views feature allows you to force BIND to use predefined zone files for queries from certain subnets. This means it's possible to use one set of zone files for queries from the Internet and another set for queries from your home network. Here's a summary of how it's done:
Here is a sample configuration snippet for the /etc/named.conf file I use for my home network. All the statements below were inserted after the options and controls sections in the file.
// ACL statement
acl "trusted-subnet" { 192.168.17.0/24; };
view "internal" { // What the home network will see
match-clients { localnets; localhost; "trusted-subnet"; };
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
// IPv6 Support
zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arp
a" IN {
type master;
file "named.ip6.local";
allow-update { none; };
};
// Prevents lookups for broadcast addresses ending in ".255"
zone "255.in-addr.arpa" IN {
type master;
file "named.broadcast";
allow-update { none; };
};
// Prevents lookups for network addresses ending in ".0"
zone "0.in-addr.arpa" IN {
type master;
file "named.zero";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "192-168-1.zone";
allow-update { none; };
};
zone "my-web-site.org" {
type master;
notify no;
file "my-site-home.zone";
allow-query { any; };
};
zone "another-site.com" {
type master;
notify no;
file "another-site-home.zone";
allow-query { any; };
};
};
view "external" { // What the Internet will see
match-clients { any; };
recursion no;
zone "my-web-site.org" {
type master;
notify no;
file "my-site.zone";
allow-query { any; };
};
zone "another-site.com" {
type master;
notify no;
file "another-site.zone";
allow-query { any; };
};
};
In this example, I included an ACL for network 192.168.17.0 /24 called trusted-subnet to help clarify the use of ACLs in more complex environments. Once the ACL was defined, I then inserted a reference to the TRusted-subnet in the match-clients statement in the internal view. So in this case the local network (192.168.1.0 /24), the other trusted network (192.168.17.0), and localhost get DNS data from the zone files in the internal view. Remember, this is purely an example. The example home network doesn't need to have the ACL statement at all as the built in ACLs localnets and localhost are sufficient. The network won't need the trusted-subnet section in the match-clients line either. Loading Your New Configuration FilesTo load your new configuration files, first make sure your file permissions and ownership are okay in the /var/named directory:
[root@bigboy tmp]# cd /var/named
[root@bigboy named]# ll
total 6
-rw-r--r-- 1 named named 195 Jul 3 2001 localhost.zone
-rw-r--r-- 1 named named 2769 Jul 3 2001 named.ca
-rw-r--r-- 1 named named 433 Jul 3 2001 named.local
-rw-r--r-- 1 root root 763 Oct 2 16:23 my-site.zone
[root@bigboy named]# chown named *
[root@bigboy named]# chgrp named *
[root@bigboy named]# ll
total 6
-rw-r--r-- 1 named named 195 Jul 3 2001 localhost.zone
-rw-r--r-- 1 named named 2769 Jul 3 2001 named.ca
-rw-r--r-- 1 named named 433 Jul 3 2001 named.local
-rw-r--r-- 1 named named 763 Oct 2 16:23 my-site.zone
[root@bigboy named]#
The configuration files above will not be loaded until you issue the proper command to restart the named process that controls DNS, but be sure to increment your configuration file serial number before doing this:
[root@bigboy tmp]# service named restart
Take a look at the end of your /var/log/messages file to make sure there are no errors. Make Sure Your /etc/hosts File is Correctly UpdatedChapter 3, "Linux Networking," explains how to correctly configure your /etc/hosts file. Some programs, such as sendmail, require a correctly configured /etc/hosts file even though DNS is correctly configured. Configure Your FirewallThe sample network assumes that the BIND name server and Apache Web server software run on the same machine protected by a router/firewall. The actual IP address of the server is 192.168.1.100, which is a private IP address. You'll have to use NAT for Internet users to be able to gain access to the server via the chosen public IP address, namely 97.158.253.26. If your firewall is a Linux box, you may want to consider taking a look at Chapter 14, "Linux Firewalls Using iptables," which describes how to do the network address translation and allow DNS traffic through to your name server. Fix Your Domain RegistrationRemember to edit your domain registration for my-web-site.org, or whatever it is, so that at least one of the name servers is your new name server (97.158.253.26 in this case). Domain registrars, such as VeriSign and RegisterFree, usually provide a Web interface to help you manage your domain. Once you've logged in with the registrar's username and password, you'll have to take two steps: It normally takes about three to four days for your updated DNS information to be propagated to all 13 of the world's root name servers. You'll therefore have to wait about this amount of time before starting to notice people hitting your new Web site. You can use the chapter's troubleshooting section to test specific DNS servers for the information they have on your site. You'll most likely want to test your new DNS server, which should be up to date, plus a few well-known ones, which should have delayed values.  | ||||||||||||||||||||||||||||||||||||
- Comment