As explained on the introduction to networking concepts chapter, the Domain Name System (DNS) is the way in which a URL or domain like www.linuxhomenetworking.com is converted to an IP address.

What Is BIND?

BIND is an acronym for the "Berkeley Internet Name Domain" project which maintains the DNS related software suite that runs under Linux. The most well known program in BIND is "named", the daemon that responds to DNS queries from remote machines.

When To Use A DNS Caching Nameserver

DNS caching servers should be used by the machines on your network to provide DNS information that it has learned from the authoritative DNS servers of the Internet. Caching DNS servers then store (or cache), the most frequently requested information to reduce the lookup overhead of subsequent queries. If you want to advertise your website www.my-site.com to the rest of the world, then a regular DNS server is what you require. Setting up a caching DNS server is fairly straightforward and will work whether or not your ISP provides you with a static or dynamic Internet IP address.

Once you have set up your caching DNS server you will then have to configure each of your home network PCs to use it as their DNS server. If your home PCs get their IP addresses using DHCP, then you will have to configure your DHCP server to make it aware of the IP address of your new DNS server. Off the shelf router/firewall appliances used in most home networks will usually act as both the caching DNS and DHCP server. In this case a separate DNS server is unnecessary.

When To Use A Regular DNS Server

If you host your own website at home with full control of all the web domains and your ISP provides you with a “fixed” or “static” IP address, then a regular DNS server would be the way to go. A caching DNS nameserver is only used as a reference, regular nameservers are used as the authoritative source of information.

Note: Regular nameservers are also caching nameservers by default.

When To Use Dynamic DNS

Your DSL ISP will assign IP addresses to your home either with an unchanging, “fixed” or “static” IP address or via a changing “DHCP” method. If your router/firewall is getting its Internet IP address using DHCP then you must consider dynamic DNS. This chapter assumes that you are using “static” Internet IP addresses.

How To Download and Install The BIND Packages

Most RedHat Linux software products are available in the RPM format. Downloading and installing RPMs isn’t hard. If you need a refresher, the chapter on RPMs covers how to do this in detail.

As of this writing the latest version of the BIND suite for RedHat 8.0 was version 9.2.1-9. It comes standard with the RedHat installation CDs.

[root@bigboy tmp]# rpm -Uvh bind-9.2.1-9.i386.rpm

How To Get BIND Started

· You can use the chkconfig command to get BIND configured to start at boot:

[root@bigboy tmp]# chkconfig --level 35 named on

· To start/stop/restart BIND after booting

[root@bigboy tmp]# /etc/init.d/named start
[root@bigboy tmp]# /etc/init.d/named stop
[root@bigboy tmp]# /etc/init.d/named restart

· Remember to restart the BIND process every time you make a change to the conf file for the changes to take effect on the running process.

The /etc/resolv.conf File

This file is used by DNS clients (servers not running BIND) to determine both the location of their DNS server and the domains to which they belong. It generally has two columns, the first contains a keyword and the second contains the desired value(s) separated by commas. Here is a list of keywords:

Keyword	Value
Nameserver	· IP address of your DNS nameserver. There should be only one entry per “nameserver” keyword. If there is more than one nameserver, you’ll need to have multiple “nameserver” lines.
Domain	· The local domain name to be used by default. If the server is bigboy.my-site.com, then the entry would just be my-site.com
Search	· If you refer to another server just by its name without the domain added on, DNS on your client will append the server name to each domain in this list and do an nslookup on each to get the remote servers’ IP address. This is a handy time saving feature to have so that you can refer to servers in the same domain by only their servername without having to specify the domain. The domains in this list must separated by spaces.

Here is a sample configuration in which:

· The client server’s main domain is my-site.com, but it also is a member of domains my-site.net and my-site.org which should be searched for short hand references to other servers.

· Two nameservers, 192.168.1.100 and 192.168.1.102 provide DNS name resolution.

domain my-site.com

search my-site.com net my-site.net my-site.org

nameserver 192.168.1.100

nameserver 192.168.1.102

Configuring A Caching Nameserver

The RedHat default installation of BIND is configured to convert your Linux box into a caching nameserver. The only file you have to edit is /etc/resolv.conf in which you’ll have to comment out the reference to your previous DNS server (most likely your router) with a "#" or make it point to the server itself using the universal localhost IP address of 127.0.0.1

Old Entry

nameserver 192.168.1.1

New Entry

# nameserver 192.168.1.1

or:

nameserver 127.0.0.1

The next step is to make all the other machines on your network point to the caching DNS server as their primary DNS server.

Configuring A Regular Nameserver

For the purposes of this tutorial, the subnet that has been assigned to you by your ISP is 97.158.253.24 with a subnet mask of 255.255.255.248 (/29).

Configuring named.conf

o The main DNS configuration is kept in the file /etc/named.conf which is used to tell BIND where to find the configuration files for each domain you own. There are usually two zone areas in this file:

v Forward zone file definitions which list files to map domains to IP addresses

v Reverse zone file definitions which list files to map IP addresses to domains

o In this example the forward zone for www.my-site.com is being set up by placing the following entries at the bottom of the /etc/named.conf file. The zone file is named my-site.zone and, though not explicitly stated, the file my-site.zone should be located in the default directory of /var/named.

zone "my-site.com" {

type master;
notify no;

allow-query { any; };
file "my-site.zone";

};

You can also insert additional entries in the /etc/named.conf file to reference other web domains you host. Here is an example for my-other-site.com using a zone file named my-other-site.zone.

zone "my-other-site.com" {

type master;
notify no;

allow-query { any; };
file "my-other-site.zone";

};

o The reverse zone definition below is optional for a home / SOHO DSL based web site. It just makes you able to do an nslookup query on the 97.158.253.x IP address and get back the true name of the server assigned that IP address. This is rarely done for home based sites. It is especially difficult to do this with your DSL ISP if you have less than 256 static IP addresses (also known as a "Class C" block of addresses).

Note: the reverse order of the IP address in the zone section is important.

zone "253.158.97.in-addr.arpa" {

type master;
notify no;
file "253.158.97";

};

Configuring The Zone Files

o In all zone files, you can place a comment at the end of any line by inserting a semi-colon “;” character then typing in the text of your comment.

o By default, your zone files are located in the directory /var/named.

o Each zone file contains a variety of records (eg. SOA, NS, MX, A and CNAME) which govern different areas of BIND. I’ll explain of them below and then follow it all up with an example.

The SOA Record

The very first record is the Start of Authority (SOA) record which contains general administrative and control information about the domain. Though you would normally think a record would be a single line, the SOA format spans several. It is the most counter-intuitive of them all, the rest of the records are relatively straight forward.

SOA Record Format

Line #	Column #	Name	Description
1	1, 2, 3	@ IN SOA	· Signifies that the SOA record is about to begin
	4	Nameserver	· Fully qualified name of your primary nameserver. · Must be followed by a "."
	5	Email	· The email address of the nameserver administrator. · The regular "@" in the e-mail address must be replaced with a "." instead. · The email address must also be followed by a "."
	6	“ ( “	· Signifies that we’re about to define some performance related variables.
2	1	Serial	· A serial number for the current configuration. · Usually in the date format YYYYMMDD with single digit incremented number tagged to the end.
3	1	Refresh	· Tells the slave DNS server how often it should check the master DNS server. Slaves aren't really used in home / SOHO environments.
4	1	Retry	· The slave's retry interval to connect the master in the event of a connection failure. Slaves aren't really used in home / SOHO environments.
5	1	Expire	· Total amount of time a slave will retry to contact the master before expiring the data it contains. Slaves aren't really used in home / SOHO environments.
6	1	Minimum TTL	· The amount of time external caching DNS servers should keep your DNS information before flushing the data from the cache. · As of BIND version 9 this value is overridden by the $TTL command at the very top of the configuration file.
	2	“ ) “	· Signifies that we’re all finished with the variables.

NS, MX, A And CNAME Records

Unlike the SOA record, the NS, MX, A and CNAME records each occupy a single line and the records each have a very similar layout.

NS, MX, A and CNAME Record Formats

Record	Description	First Column	Second Column	Third Column	Fourth Column
NS	Lists the name of the nameserver for the domain	Blank	"NS"	IP address or CNAME of the nameserver	N/A
MX	Lists the mail servers for your domain such as my-site.com	Domain, followed by a "."	"MX"	Mail server priority	CNAME of mail server or the mailserver's FQDN** followed by a "."
A	Maps an IP address to each server in your domain. There must always be an entry for localhost 127.0.0.1	Server name	"A"	IP address of server	N/A
CNAME	Provides additional alternate "alias" names for servers listed in the "A" records.	"alias" or "nickname" for server	"CNAME"	"A" record name for server	N/A

**The Fully Qualified Domain Name (FQDN) is the full DNS name of the server such as mail.my-site.com

o Note: If you don't put a "." at the end of a host name in a SOA, NS, A or CNAME record, BIND will automatically tack on the domain name. So an "A" record with "www" will be assumed to refer to www.my-site.com. This may be OK in most cases, but if you forget to put the "." after the domain in the MX record for my-site.com, BIND will attach the my-site.com at the end, and you will find your mail server only accepting mail for the domain my-site.com.mysite.com.

Sample Forward Zone File

Here is a working example of the zone file for my-site.com.

;

; Zone file for my-site.com

;

; The full zone file

;

$TTL 3D

@ IN SOA www.my-site.com. hostmaster.my-site.com. (

200211152 ; serial#

3600 ; refresh, seconds

3600 ; retry, seconds

3600 ; expire, seconds

3600 ) ; minimum, seconds

;

NS www ; Inet Address of nameserver

my-site.com. MX 10 mail ; Primary Mail Exchanger

;

localhost A 127.0.0.1

www A 97.158.253.26

mail CNAME www

Notice that in this example:

o Server www.my-site.com is nameserver for my-site.com. In corporate environments there may be a separate nameserver for this purpose. Primary nameservers are more commonly called “ns1” and secondary nameservers “ns2”, but in the home / SOHO environment it is not necessary to differentiate.

o The minimum TTL is set to 3600 seconds, but the overriding $TTL value is 3 days. So remote DNS caching servers will store learned DNS information from your zone for 3 days before flushing it out of their caches.

o The MX record for my-site.com points to the server named mail.my-site.com

o "mail" is actually a CNAME or "alias" for the web server "www". So here we have an example of the nameserver, mail server and web server being the same machine. If they were all different machines, then you’d have an "A" record entry for each like the example below.

www A 97.158.253.26

mail A 97.158.253.134

ns A 97.158.253.125

o The serial number is extremely important. You MUST increment it after editing the file or else BIND will not apply the changes you made when you restart "named".

Sample Reverse Zone File

Now we need to make sure that we can do an nslookup query on all our home network’s PCs and get their correct IP addresses. This is very important if you are running a mail server on your network as sendmail typically will only relay mail from hosts whose IP addresses resolve correctly in DNS. Here is a sample reverse zone file for our network.

;

; Filename: 192-168-1.zone

;

; Zone file for 192.168.1.x

;

$TTL 3D

@ IN SOA www.my-site.com. hostmaster.my-site.com. (

200303301 ; serial number

8H ; refresh, seconds

2H ; retry, seconds

4W ; expire, seconds

1D ) ; minimum, seconds

;

NS www ; Nameserver Address

;

100 PTR bigboy.my-site.com.

103 PTR smallfry.my-site.com.

102 PTR ochorios.my-site.com.

105 PTR reggae.my-site.com.

32 PTR dhcp-32.my-site.com.

33 PTR dhcp-33.my-site.com.

34 PTR dhcp-34.my-site.com.

35 PTR dhcp-35.my-site.com.

36 PTR dhcp-36.my-site.com.

Note: I have included entries for addresses 192.168.1.32 to 192.168.1.36 which are the addresses our 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 ISP’s 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 DNS

The above 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 webserver.

What do the PCs on your home network need to see? They need to see DNS references to the real IP address of the webserver, 192.168.1.100. This is 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 webserver.

Don’t worry. BIND has a way around this called “views”. The views feature allows you to force BIND to use pre-defined 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:

o Place your zone statements in the /etc/named.conf file in one of two “views” sections. The first section will be called “internal” and will list the zone files to be used by your internal network. The second view called “external” will list the zone files to used for Internet users.

For example; you could have a reference to a zone file called my-site.zone for lookups related to the 97.158.253.X network which Internet users would see. This /etc/named.conf entry would be inserted in the “external” section. You could also have a file called my-site-home.zone for lookups by home users on the 192.168.1.0 network. This entry would be inserted in the “internal” section. The creation of the my-site-home.zone file is fairly easy. Just copy it form the my-site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X

o You must also tell the DNS server which addresses you feel are “internal” and “external”. This is done by first defining access control lists (ACLs) and then referring to these lists within each view section with the match-clients statement. There are some built-in ACLs:

v “localhost” which refers to the DNS server itself;

v “localnets” which refers to all the networks to which the DNS server is directly connected;

v “any” which is self explanatory.

Note: You must place your “localhost”, “0.0.127.in-addr.arpa” and "." zone statements in the “internal” views section. Remember to increment your serial numbers!

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/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; };

};

zone "1.168.192.in-addr.arpa" IN {

type master;

file "192-168-1.zone";

allow-update { none; };

};

zone "my-site.com" {

type master;

notify no;

file "my-site-home.zone";

allow-query { any; };

};

zone "my-other-site.com" {

type master;

notify no;

file "my-other-site-home.zone";

allow-query { any; };

};

view "external" { // What the Internet will see

match-clients { any; };

recursion no;

zone "my-site.com" {

type master;

notify no;

file "my-site.zone";

allow-query { any; };

};

zone "my-other-site.com" {

type master;

notify no;

file "my-other-site.zone";

allow-query { any; };

};

Note: In the above 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 will get DNS data from the zone files in the “internal” view. Remember, this is purely an example. The home network we have been using doesn’t need to have the ACL statement at all as the built in ACLs “localnets” and “localhost” are sufficient. Our network won’t need the “trusted-subnet” section in the match-clients line either.

Loading Your New Configuration Files

o Make sure your file permissions and ownership are OK in /var/named

[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]#

o The configuration files above will not be loaded until you issue the following command to restart the named process that controls DNS (Make sure to increment your configuration file serial number before doing this):

[root@bigboy tmp]# /etc/init.d/named restart

Make Sure Your /etc/hosts File Is Correctly Updated

The chapter covering Linux networking topics explains how to do this. Some programs such as sendmail require a correctly configured /etc/hosts file even though DNS is correctly configured.

Configure Your Firewall

The sample network we're using assumes that the BIND nameserver 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 employ NAT in order for Internet users to be able to gain access to the server via the Public IP address we chose, namely 97.158.253.26. If your firewall is a Linux box, you may want to consider taking a look on the iptables chapter on how to do the NAT and allow DNS traffic trough to your nameserver.

Fix Your Domain Registration

Remember to edit your domain registration for "my-site.com", or whatever it is, so that at least one of the nameservers is your new nameserver. ( 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 do the following two steps:

o First, you'll have to create a new nameserver record entry for the IP address 97.158.253.26 to map to ns.my-site.com or www.my-site.com or whatever your nameserver is called. (This screen will prompt you for both the server's IP address and name)

o Then you'll have to assign ns.my-site.com to handle your domain. (This screen will prompt you for the server name only)

Sometimes, the registrar will require at least two registered nameservers per domain. If you only have one, then you could either:

o Create a second nameserver record entry with the same IP address, but different name.

o Give your web server a second IP address using an IP alias, create a second NAT entry on your firewall and then create the second nameserver record entry with the new IP address, and different name.

It normally takes about 3-4 days for your updated DNS information to be propagated to all 13 of the world’s root (“super duper”) nameservers. You’ll therefore have to wait about this amount of time before you’ll start noticing people hitting your new website site.

How To Migrate Your Website In-House

It is important to have a detailed migration plan if you currently use an external company to host your website and wish to move the site to a server at home or in your office. At the very least it should include the following steps:

· There is no magic bullet which will allow you to tell all the caching DNS servers in the world to flush their caches of your zone file entries. Your best alternative will be to request your existing service provider to set the TTL on my-site.com in the DNS zone file to a very low value, say 1 minute. As the TTL is usually set to 3 days, it will take at least 3-5 days for all remote DNS servers to recognize the change. Once the propagation is complete, it will take only 1 minute to see the results of the final DNS configuration switch to your new server. If anything goes wrong, you can then revert to the old configuration, knowing it will rapidly recover within minutes rather than days.

· Set up your server in house using a different domain, for example www.my-site-test.com. Also set the TTL on this domain to 1 minute.

· Ask your existing web hosting provider to add a DNS entry for your new server in the my-site.com domain. Now your server will be a part of both my-site.com and my-site-test.com.

· Test your applications using server.my-site.com

· Test mail to users @my-site-test.com

· Test web traffic to www.my-site-test.com

· Once testing is completed, convert all the server configuration files to reference my-site.com and not my-site-test.com Restart all the relevant applications.

· Coordinate with your web hosting provider to simultaneously update you domain registration’s DNS records to point to your new DNS server.

· As both TTLs were set to 1 minute previously, you'll be able to see results of the migration within minutes.

· Once complete, you can set the TTL back to 3 days to help reduce the volume of DNS query traffic hitting your DNS server.

Remember, you don't have to host DNS or mail in-house, this could be left in the hands of your service provider. You can migrate these services in-house later as your confidence in hosting becomes greater.

Finally, if you have concerns that your service provider won’t co-operate then you could explain to them that you want to test their failover capabilities to a duplicate server that you host in-house. You can then decide whether the change will be permanent once you have failed over back and forth a few times.

DHCP Considerations For DNS

If you have a DHCP server on your network, you'll need to make it assign the IP address of the Linux box as the DNS server it tells the DHCP clients to use. If your Linux box is the DHCP server, then you may need to refer to the DHCP server chapter.