Configuring DNS

Configuring DNS

Introduction

Domain Name System (DNS) converts the name of a Web site (www.linuxhomenetworking.com) to an IP address (65.115.71.34). This step is important, because the IP address of a Web site's server, not the Web site's name, is used in routing traffic over the Internet. This chapter will explain how to configure your own DNS server to help guide Web surfers to your site.

Introduction to DNS

Before you dig too deep in DNS, you need to understand a few foundation concepts on which the rest of the chapter will be built.

DNS Domains

Everyone in the world has a first name and a last, or family, name. The same thing is true in the DNS world: A family of Web sites can be loosely described a domain. For example, the domain linuxhomenetworking.com has a number of children, such as www.linuxhomenetworking.com and mail.linuxhomenetworking.com for the Web and mail servers, respectively.

BIND

BIND is an acronym for the Berkeley Internet Name Domain project, which is a group that 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.

DNS Clients

A DNS client doesn't store DNS information; it must always refer to a DNS server to get it. The only DNS configuration file for a DNS client is the /etc/resolv.conf file, which defines the IP address of the DNS server it should use. You shouldn't need to configure any other files. You'll become well acquainted with the /etc/resolv.conf file soon.

Authoritative DNS Servers

Authoritative servers provide the definitive information for your DNS domain, such as the names of servers and Web sites in it. They are the last word in information related to your domain.

How DNS Servers Find Out Your Site Information

There are 13 root authoritative DNS servers (super duper authorities) that all DNS servers query first. These root servers know all the authoritative DNS servers for all the main domains - .com, .net, and the rest. This layer of servers keep track of all the DNS servers that Web site systems administrators have assigned for their sub domains.

For example, when you register your domain my-site.com, you are actually inserting a record on the .com DNS servers that point to the authoritative DNS servers you assigned for your domain. (More on how to register your site later.).

When To Use A DNS Caching Name Server

Most servers don't ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. These servers, through a process called recursion, sequentially query the authoritative servers at the root, main domain and sub domain levels to get eventually get the specific information requested. The most frequently requested information is then stored (or cached) to reduce the lookup overhead of subsequent queries.

If you want to advertise your Web site 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 works whether or not your ISP provides you with a static or dynamic Internet IP address.

After you set up your caching DNS server, you must 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 have to configure your DHCP server to make it aware of the IP address of your new DNS server, so that the DHCP server can advertise the DNS server to its PC clients. Off-the-shelf router/firewall appliances used in most home networks usually can act as both the caching DNS and DHCP server, rendering a separate DNS server is unnecessary.

You can find the configuration steps for a Linux DHCP server in Chapter 8, 'Configuring the DHCP Server'.

When To Use A Static DNS Server

If your ISP provides you with a fixed or static IP address, and you want to host your own Web site, then a regular authoritative DNS server would be the way to go. A caching DNS name server is used as a reference only, regular name servers are used as the authoritative source of information for your Web site's domain.

Note: Regular name servers are also caching name servers by default.

When To Use A Dynamic DNS Server

If your ISP provides your router/firewall with its Internet IP address using DHCP then you must consider dynamic DNS covered in Chapter 19, 'Dynamic DNS'. For now, I'm assuming that you are using static Internet IP addresses.

How To Get Your Own Domain

Whether or not you use static or dynamic DNS, you need to register a domain.

Dynamic DNS providers frequently offer you a subdomain of their own site, such as my-site.dnsprovider.com, in which you register your domain on their site.

If you choose to create your very own domain, such as my-site.com, you have to register with a company specializing in static DNS registration and then point your registration record to the intended authoritative DNS for your domain. Popular domain registrars include VeriSign, Register Free, and Yahoo.

If you want to use a dynamic DNS provider for your own domain, then you have to point your registration record to the DNS servers of your dynamic DNS provider. (More details on domain registration are coming later in the chapter.).

Basic DNS Testing of DNS Resolution

As you know, DNS resolution maps a fully qualified domain name (FQDN), such as www.linuxhomenetworking.com, to an IP address. This is also known as a forward lookup. The reverse is also true: By performing a reverse lookup, DNS can determining the fully qualified domain name associated with an IP address.

Many different Web sites can map to a single IP address, but the reverse isn't true; an IP address can map to only one FQDN. This means that forward and reverse entries frequently don't match. The reverse DNS entries are usually the responsibility of the ISP hosting your site, so it is quite common for the reverse lookup to resolve to the ISP's domain. This isn't an important factor for most small sites, but some e-commerce applications require matching entries to operate correctly. You may have to ask your ISP to make a custom DNS change to correct this.

There are a number of commands you can use do these lookups. Linux uses the host command, for example, but Windows uses nslookup.

The Host Command

The host command accepts arguments that are either the fully qualified domain name or the IP address of the server when providing results. To perform a forward lookup, use the syntax:

[root@bigboy tmp]# host www.linuxhomenetworking.com

www.linuxhomenetworking.com has address 65.115.71.34

[root@bigboy tmp]#

To perform a reverse lookup

[root@bigboy tmp]# host 65.115.71.34

34.71.115.65.in-addr.arpa domain name pointer 65-115-71-34.myisp.net.

[root@bigboy tmp]#

As you can see, the forward and reverse entries don't match. The reverse entry matches the entry of the ISP.

The nslookup Command

The nslookup command provides the same results on Windows PCs. To perform forward lookup, use.

C:> nslookup www.linuxhomenetworking.com

Server: 192-168-1-200.my-site.com

Address: 192.168.1.200

Non-authoritative answer:

Name: www.linuxhomenetworking.com

Address: 65.115.71.34

C:>

To perform a reverse lookup

C:> nslookup 65.115.71.34

Server: 192-168-1-200.my-site.com

Address: 192.168.1.200

Name: 65-115-71-34.my-isp.com

Address: 65.115.71.34

C:>

Downloading and Installing the BIND Packages

Most RedHat and Fedora Linux software products are available in a package format. When searching for the file, remember that the BIND package's filename usually starts with the word "bind" followed by a version number, as in bind-9.2.2.P3-9.i386.rpm. (For more details on downloading RPMs, see Chapter 6, 'Installing Linux Software').

Note: Unless otherwise stated, the sample configurations covered in this chapter will be for Redhat / Fedora distributions. If you use Debian / Ubuntu, don't worry, there will be annotations to make you aware of the differences.

How To Get BIND Started

Setting up your DNS server is easy to do, but the procedure differs between Linux distributions.

Redhat / Fedora

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

[root@bigboy tmp]# chkconfig named on

To start, stop, and restart BIND after booting, use:

[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 configuration file for the changes to take effect on the running process.

Debian / Ubuntu

You can use the sysv-rc-conf command to get BIND configured to start at boot

[root@bigboy tmp]# sysv-rc-conf bind on

To start, stop, and restart BIND after booting, use:

[root@bigboy tmp]# /etc/init.d/bind start

[root@bigboy tmp]# /etc/init.d/bind stop

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

Even though the startup script and installation package name refers to bind, the name of the daemon that runs is named just like it is with Redhat / Fedora. Also remember to restart the BIND process every time you make a change to the configuration file for the changes to take effect on the running process.

The /etc/resolv.conf File

DNS clients (servers not running BIND) use the /etc/resolv.conf file to determine both the location of their DNS server and the domains to which they belong. The file generally has two columns; the first contains a keyword, and the second contains the desired values separated by commas. See Table 18.1 for a list of keywords.

Table 18.1 Keywords In /etc/resolv.conf

Take a look at 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 shorthand references to other servers. Two name servers, 192.168.1.100 and 192.168.1.102, provide DNS name resolution:

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

nameserver 192.168.1.100

nameserver 192.168.1.102

The first domain listed after the search directive must be the home domain of your network, in this case my-site.com. Placing a domain and search entry in the /etc/resolv.conf is redundant, therefore.

Important File Locations

The locations of the BIND configuration files vary by Linux distribution, as you will soon see.

RedHat / Fedora

RedHat / Fedora BIND normally runs as the named process owned by the unprivileged named user.

Sometimes BIND is also installed using Linux's chroot feature to not only run named as user named, but also to limit the files named can see. When installed, named is fooled into thinking that the directory /var/named/chroot is actually the root or directory. Therefore, named files normally found in the /etc directory are found in /var/named/chroot/etc directory instead, and those you'd expect to find in /var/named are actually located in /var/named/chroot/var/named.

The advantage of the chroot feature is that if a hacker enters your system via a BIND exploit, the hacker's access to the rest of your system is isolated to the files under the chroot directory and nothing else. This type of security is also known as a chroot jail.

You can determine whether you have the chroot add-on RPM by using this command, which returns the name of the RPM.

[root@bigboy tmp]# rpm -q bind-chroot

bind-chroot-9.2.3-13

[root@bigboy tmp]#

There can be confusion with the locations: Regular BIND installs its files in the normal locations, and the chroot BIND add-on RPM installs its own versions in their chroot locations. Unfortunately, the chroot versions of some of the files are empty. Before starting Fedora BIND, copy the configuration files to their chroot locations:

[root@bigboy tmp]# cp -f /etc/named.conf /var/named/chroot/etc/

[root@bigboy tmp]# cp -f /etc/rndc.* /var/named/chroot/etc/

Before you go to the next step of configuring a regular name server, it is important to understand exactly where the files are located. Table 18.2 provides a map.

Table 18.2 Differences In Fedora And Redhat DNS File Locations

Note: Fedora Core installs BIND chroot by default. RedHat 9 and earlier don't.

Debian / Ubuntu

With Debian / Ubuntu, all the configuration files, the primary named.conf file and all the DNS zone files reside in the /etc/bind directory.

Unlike in Redhat / Fedora, references to other files within these configuration files should include the full path. The named daemon won't automatically assume they are located in the /etc/bind directory.

Configuring Your Nameserver

For 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.conf

You'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

Creating a named.conf Base Configuration

The /etc/named.conf file contains the main DNS configuration and tells BIND where to find the configuration, or zone files for each domain you own. This file usually has two zone areas:

Forward zone file definitions list files to map domains to IP addresses.

Reverse zone file definitions list files to map IP addresses to domains.

Some versions of BIND will come with a /etc/amed.conf file configured to work as a caching nameserver which can be converted to an authoritative nameserver by adding the correct references to your zone files. Please proceed to the next section if this is the case with your version of BIND.

In other cases the named.conf configuration file may be hard to find. Some versions of Linux install BIND as a default caching nameserver using a file names /etc/named.caching-nameserver.conf for its configuration. In such cases BIND becomes an authoritative nameserver when a correctly configured /etc/named.conf file is created.

Fortunately BIND comes with samples of all the primary files you need. Table 18.3 explains their names and purpose in more detail.

Table 18.3 The Primary BIND Configuration Files

The creation of these files in the correct locations and their subsequent configuration isn't hard. Here's what you need to do:

1. The first task is to locate these files and place them in the correct locations. In the examples that follow we assume a chroot version of BIND and add the appropriate symbolic links to the /etc directory.

[root@bigboy tmp]# locate named.conf

/etc/dbus-1/system.d/named.conf

/usr/share/doc/bind-9.3.3/sample/etc/named.conf

[root@bigboy tmp]# cp /usr/share/doc/bind-9.3.3/sample/etc/named.conf

/var/named/chroot/etc

[root@bigboy tmp]# ln -s /var/named/chroot/etc/named.conf /etc/named.conf

[root@bigboy tmp]# locate named.root.hints

/usr/share/doc/bind-9.3.3/sample/etc/named.root.hints

[root@bigboy tmp]# cp /usr/share/doc/bind-9.3.3/sample/etc/named.root.hints

/var/named/chroot/etc

[root@bigboy tmp]# ln -s /var/named/chroot/etc/named.root.hints /etc/named.root.hints

[root@bigboy tmp]# locate named.root

/usr/share/doc/bind-9.3.3/sample/etc/named.root.hints

/usr/share/doc/bind-9.3.3/sample/var/named/named.root

[root@bigboy tmp]#

[root@bigboy tmp]# cp /usr/share/doc/bind-9.3.3/sample/var/named/named.root

/var/named/chroot/var/named/named.root

[root@bigboy tmp]#

2. Though it is beyond the scope of this book, it is possible to create a master and redundant slave authoritative name servers for your domains. You can configure your master to use a secret identification key when updating its slaves to help ensure the security of the updates. The next step requires you to generate a key for your named.conf file, and this can be done using the dns-keygen or dnskeygen commands.

[root@bigboy tmp]# /usr/sbin/dns-keygen

u8yNvOLHovDstA8lFHRvQl0XnjlxL1q1JCP5OaDHw4sgssgzRxKNkB7kKbON

[root@bigboy tmp]#

Edit your /etc/named.conf file and add your secret key to the ddns_key section. Though it is not required, it is a good practice to configure your DNS server's named.conf file to support BIND views. This will be discussed next.

Configuring BIND Views in named.conf

Our sample scenario assumes that DNS queries will be coming from the Internet and that the zone files will return 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 figures this out using its views feature which allows you 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:

1. If your DNS server is also acting as a caching DNS server, then you'll also need a view for localhost to use. A view called localhost_resolver is a predefined view in Fedora's sample named.conf file and will be explained later.

2. Place your zone statements in the /etc/named.conf file in one of two other view sections. The first section is called internal and lists the zone files to be used by your internal network. The second view called external lists the zone files to be 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. Creating the my-site-home.zone file is fairly easy: Copy it from the my-site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X.

3. You must also tell the DNS server which addresses you feel are internal and external. To do this, you must first define the internal and external networks with access control lists (ACLs) and then refer to these lists within their respective view section with the match-clients statement. Some built-in ACLs can save you time:

localhost: Refers to the DNS server itself

localnets: Refers to all the networks to which the DNS server is directly connected

any: which is self explanatory.

Let's examine BIND views more carefully using a number of sample configuration snippets from 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. I have selected generic names internal, for views given to trusted hosts (home, non-internet or corporate users), and external for the views given to Internet clients, but they can be named whatever you wish.

First let's talk about how we should refer to the zone files in each view.

Zone File References in named.conf

In this section we'll set up the forward zone reference for the my-web-site.org domain by placing entries for it in the named.conf file.

In our example 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 configuration or in /var/named in a regular one. With Debian / Ubuntu, references to the full file path will have to be used. Use the code:

zone "my-web-site.org" ;

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" ;

file "another-site.zone";

Note: The allow-query directive defines the networks that are allowed to query your DNS server for information on any zone. For example, to limit queries to only your 192.168.1.0 network, you could modify the directive to:

allow-query ;

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 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 3 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.192.in-addr.arpa" ;

Your patience will soon be rewarded. It's time to talk about the views! Let's go!

The Caching Nameserver localhost_resolver View

The localhost_resolver view is used for your caching DNS server configuration and should look like this:

view 'localhost_resolver'

match-destinations ;

recursion yes;

/* these are zones that contain definitions for all the localhost

* names and addresses, as recommended in RFC1912 - these names should

* ONLY be served to localhost clients:

*/

include '/etc/named.rfc1912.zones';

/*

* Include zonefiles for internal zones

*/

include '/var/named/zones/internal/internal_zones.conf';

There are some quick facts you should be aware of with your caching name server configuration:

1. Make sure this section only refers to including the /etc/named.rfc1912.zones file. Other include references to files such as named.root.hints could cause errors when starting the named daemon.

2. If you want your server to be only a caching DNS server, then delete all other views in named.conf and restart the named daemon.

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

3. Make all the other machines on your network point to the caching DNS server as their primary DNS server.

4. Remember that all DNS queries done on your DNS server appear to come from localhost. If your server is also an authoritative server for your domain, you will have to include a reference to your domain's zone files in this section for the server's own DNS lookups to work. If not, queries from clients defined by the internal and external ACLs will work correctly, but queries for the domain from the server itself will fail. In this example we have included a reference to the internal_zones.conf zone file which we'll visit again soon. This line can be deleted if your server isn't an authoritative server for your domain.

Note: If you have a localhost only view like this, make sure you don't reference localhost in any of your other views as one view will take precedence over the other for queries from your server. This could lead to unpredictable results.

The Internal View

In this example I included an ACL for network 192.168.17.0 /24 called safe-subnet to help clarify the use of ACLs in more complex environments. Once the ACL was defined, I then inserted a reference to the safe-subnet in the match-clients statement in the internal view. Therefore 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.

// ACL statement

acl "safe-subnet" ;

view "internal" ;

match-destinations ;

recursion yes;

// all views must contain the root hints zone:

include '/etc/named.root.hints';

// These are your 'authoritative' internal zones, and would probably

// also be included in the 'localhost_resolver' view above :

/*

* Include zonefiles for internal zones

*/

include '/var/named/zones/internal/internal_zones.conf';

The question you may have on your mind is, 'Where are the zone file definitions?'. Don't worry, there is an include statement that refers to a file named internal_zones.conf that contains them all as we see here:

// File internal_zones.conf

zone '1.168.192.in-addr.arpa' IN ;

zone 'my-web-site.org' IN ;

I'll discuss how to handle queries from clients outside your trusted networks in the next section where an external view can be used.

The External View

You can also setup an external view that will be used for DNS queries from clients outside your network, such as the Internet. In this case external queries get results from zone files in the /var/named/zones/external directory.

view "external" ;

match-destinations ;

recursion no;

// you'd probably want to deny recursion to external clients, so you don't

// end up providing free DNS service to all takers

// all views must contain the root hints zone:

include '/etc/named.root.hints';

// These are your 'authoritative' external zones, and would probably

// contain entries for just your web and mail servers:

zone '253.158.97.in-addr.arpa' IN ;

};

zone 'my-web-site.org' IN ;

};

Notice that the reverse zone file gives results for public internet addresses, and of course, the forward zone file should only provide responses with Internet accessible addresses.

Note: In the external view, you may be tempted to use an exclamation mark (!) to eliminate networks used in the internal view like this. Be careful, it is best to use 'any;' for your external view as the exclamation mark (!) is not honored with some versions of BIND in views named 'external'.

; !!! CAUTION !!!

match-clients  ;

match-destinations ;

The views listed here are purely to illustrate their use. The sample 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. The sample network won't need the safe-subnet section in the match-clients line either as there is only one subnet in the configuration.

Views are also not just for NAT. If you run an Internet data center, you can set up your DNS server to act as a caching server to servers on all the Internet networks you own and no one else, and then provide authoritative responses to your customers' domains to everyone. Views can be very useful.

Configuring The Zone Files

You need to keep a number of things in mind when configuring DNS zone files:

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.

By default, your zone files are located in the /var/named or /var/named/chroot/var/named or /etc/bind directories depending on your Linux distribution.

Each zone file contains a variety of records (SOA, NS, MX, A, and CNAME) that govern different areas of BIND.

Take a closer look at these entries in the zone file.

Time to Live Value

The 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 Records

The 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 Record

The first resource record is the Start of Authority (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-site.com. hostmaster.my-site.com. (

2004100801  ; serial #

4H  ; refresh

1H  ; retry

1W  ; expiry

1D )  ; minimum

Table 18.4 explains what each field in the record means.

Table 18.4 The SOA Record Format

So in the example, the primary name server is defined as ns1.my-site.com with a contact e-mail address of hostmaster@my-site.com. 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 And CNAME Records

Like the SOA record, the NS, MX, A, PTR and CNAME records each occupy a single line with a very similar general format. Table 18.5 outlines the way they are laid out.

Table 18.5 NS, MX, A, PTR and CNAME Record Formats

If the search key to a DNS resource record is blank it reuses the search key from the previous record which in this case of is the SOA @ sign.

For most home / SOHO scenarios, the Class field will always be IN or Internet. You should also be aware that IN is the default Class, and BIND will assume a record is of this type unless otherwise stated.

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-site.com. This may be acceptable in most cases, but if you forget to put the period after the domain in the MX record for my-site.com, BIND attaches the my-site.com at the end, and you will find your mail server accepting mail only for the domain my-site.com.mysite.com.

TXT Records

There is also a less frequently used DNS TXT record that can be configured to contain additional generic information. The data section of the record typically has the format 'name=value', where 'name' is the name to be given to the type of data, and 'value' is the value assigned to the name as seen in this example.

my-web-site.org. TXT 'v=spf1 -all'

TXT records are increasingly being used to help fight SPAM using the Sender Policy Framework (SPF) method. SPF TXT records are used by systems receiving mail to interrogate the DNS of the domain which appears in the email (the sender) and determine if the originating IP address of the mail (the source) is authorized to send mail for the sender's domain.

Further description of the use of TXT records is beyond the scope of this book, but you should at least be aware that they can be up to 255 characters in length and that this feature is often exploited in distributed denial of service (DDoS) attacks. The section on 'Simple DNS Security' explains how to configure your DNS server to not participate in such an event.

Sample Forward Zone File

Now that you know the key elements of a zone file, it's time to examine a working example for the domain my-site.com.

; Zone file for my-site.com

; The full zone file

$TTL 3D

IN SOA ns1.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

bigboy A 97.158.253.26

mail CNAME bigboy

ns1 CNAME bigboy

www CNAME bigboy

Notice that in this example:

Server ns1.my-site.com is the name server for my-site.com. In corporate environments there may be a separate name server for this purpose. Primary name servers are more commonly called ns1 and secondary name servers ns2.

The minimum TTL value ($TTL) is three days, therefore remote DNS caching servers will store learned DNS information from your zone for three days before flushing it out of their caches.

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

ns1 and mail are actually CNAMEs or aliases for the Web server www. So here you have an example of the name server, 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.

www  A 97.158.253.26

mail A 97.158.253.134

ns  A 97.158.253.125

It is a required practice to increment your serial number whenever you edit your zone file. When DNS is setup 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 File

Now 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-site.com.

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

PTR dhcp-192-168-1-32.my-site.com.

PTR dhcp-192-168-1-33.my-site.com.

PTR dhcp-192-168-1-34.my-site.com.

35 PTR dhcp-192-168-1-35.my-site.com.

PTR dhcp-192-168-1-36.my-site.com.

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.

Loading Your New Configuration Files

Make sure your configuration files are in the correct locations and the serial numbers of the zone files you may have modified have been updated. If all seems correct, restart BIND named daemon for the configuration to become active.

[root@bigboy tmp]# /etc/init.d/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 Updated

Chapter 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 Firewall

The 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', describes how to do the network address translation and allow DNS traffic through to your name server.

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 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 take two steps:

1) Create a new name server 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 name server is called. (This screen prompts you for both the server's IP address and name.)

2) Assign ns.my-site.com to handle your domain. This screen will prompt you for the server name only.

Sometimes, the registrar requires at least two registered name servers per domain. If you only have one, then you could either create a second name server record entry with the same IP address, but different name, or you could 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 name server record entry with the new IP address, and different name.

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.

Troubleshooting BIND

BIND troubleshooting is usually easy to do. The named daemon updates the /var/log/messages file with detailed status messages that are frequently easy to interpret when you suspect a configuration error. The usual troubleshooting steps for network problems are also applicable. Both methodologies will be covered next.

Configuration Troubleshooting Steps

Always check your /var/logs/messages file and console output file for errors. Here are a couple examples you may come across:

The named daemon is started with an unedited version of the sample named.conf file which causes unusual errors on the screen. References to the nonexistent sample zone files create errors. References to both the named.rfc1912.zones and named.root files in the localhost_resolver section cause errors related to duplicate definitions.

[root@bigboy tmp]# service named restart

Starting named:

Error in named configuration:

/etc/named.rfc1912.zones:10: zone '.': already exists previous definition: /etc/named.root.hints:12

zone localdomain/IN: loaded serial 42

zone localhost/IN: loaded serial 42

zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700

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.arpa/IN: loaded serial 1997022700

zone 255.in-addr.arpa/IN: loaded serial 42

zone 0.in-addr.arpa/IN: loaded serial 42

zone my.internal.zone/IN: loading master file my.internal.zone.db: file not found

internal/my.internal.zone/IN: file not found

zone my.ddns.internal.zone/IN: loading master file slaves/my.ddns.internal.zone.db: file not found

internal/my.ddns.internal.zone/IN: file not found

zone my.external.zone/IN: loading master file my.external.zone.db: file not found

external/my.external.zone/IN: file not found

[FAILED]

[root@bigboy tmp]#

The named.conf file refers to an undefined secret key in the ddns_key of named.conf. Use the dns-keygen or dnskeygen commands to create a correct entry.

Feb 25 20:38:49 bigboy named[4593]: /etc/named.conf:99: configuring key 'ddns_key': bad base64 encoding

Feb 25 20:38:49 bigboy named[4593]: loading configuration: bad base64 encoding

The named.root.hints file referred to in named.conf isn't present in the /etc or the chroot /etc directory.

[root@bigboy tmp]# service named start

Starting named:

Error in named configuration:

/etc/named.conf:58: open: /etc/named.root.hints: file not found

[FAILED]

[root@bigboy tmp]#

The named.root file referred to in the named.root.hints file isn't present.

Feb 25 21:33:41 bigboy named[5007]: could not configure root hints from 'named.root': file not found

Feb 25 21:33:41 bigboy named[5007]: loading configuration: file not found

Feb 25 21:33:41 bigboy named[5007]: exiting (due to fatal error)

You are using a chroot version of BIND with a sample rndc.key file located in the /etc directory instead of the /var/named/chroot/etc/ directory. Copy the file to the correct location and restart named to fix the problem.

[root@bigboy tmp]# service named restart

Stopping named: rndc: connect failed: connection refused

[ OK ]

Starting named: [ OK ]

[root@bigboy tmp]#

In your named.conf file you refer to a zone file that doesn't exist. This example includes both errors to the console screen and errors in the /var/log/messages file.

[root@bigboy tmp]# service named start

Starting named:

Error in named configuration:

zone localdomain/IN: loaded serial 42

zone localhost/IN: loaded serial 42

zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700

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.arpa/IN: loaded serial 1997022700

zone 255.in-addr.arpa/IN: loaded serial 42

zone 0.in-addr.arpa/IN: loaded serial 42

zone 2.168.192.in-addr.arpa/IN: loaded serial 2006052301

zone my-web-site.org/IN: loaded serial 2006052302

zone my-web-site.com/IN: loading master file /var/named/zones/internal/my-web-site.com.zone: file not found

internal/my-web-site.com/IN: file not found

zone 1.168.192.in-addr.arpa/IN: loaded serial 2006052301

zone my-web-site.org/IN: loaded serial 2006052302

[FAILED]

[root@bigboy tmp]#

Feb 26 01:47:10 smallfry named: zone my-web-site.com/IN: loading master file /var/named/zones/internal/my-web-site.com.zone: file not found

Feb 26 01:47:10 smallfry named: internal/my-web-site.com/IN: file not found

This is a tricky one that would occur in some early versions of Fedora. BIND would appear to start correctly, but none of the zone files would be loaded. In this scenario could be using a chroot version of BIND with a sample named.conf file located in the /etc directory instead of the /var/named/chroot/etc/ directory. Copy the file to the correct location and restart named to fix the problem. Delete the /etc and create a symbolic link to /var/named/chroot/etc/named.conf from /etc to ensure you always edit the correct file.

Nov 9 17:35:41 bigboy named[1157]: starting BIND 9.2.3 -u named -t /var/named/chroot

Nov 9 17:35:41 bigboy named[1157]: using 1 CPU

Nov 9 17:35:41 bigboy named[1157]: loading configuration from '/etc/named.conf'

Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface lo, 127.0.0.1#53

Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface eth0, 10.41.32.71#53

Nov 9 17:35:41 bigboy named[1157]: command channel listening on 127.0.0.1#953

Nov 9 17:35:41 bigboy named[1157]: command channel listening on ::1#953

Nov 9 17:35:41 bigboy named[1157]: running

If there are no named errors to the screen or /var/log/messages, and your domain doesn't resolve correctly when queried using the host command when you are logged into your new nameserver, then the problem could be due to you forgetting to add a zone file entry for the domain in named.conf; there could be a typographical error in your zone file; or you could have forgotten to update your zone file serial numbers.

This isn't a comprehensive configuration error list, but it covers some common mistakes with a new configuration.

Network Troubleshooting Steps

Once configuration troubleshooting this is completed, you can continue with the following troubleshooting steps:

1) Determine whether your DNS server is accessible on DNS UDP/TCP port 53. Lack of connectivity could be caused by a firewall with incorrect, permit, NAT, or port forwarding rules to your DNS server. Failure could also be caused by the named process being stopped. It is best to test this from both inside your network and from the Internet.

Troubleshooting with TELNET is covered in Chapter 4, 'Simple Network Troubleshooting'.

2) Linux status messages are logged to the file /var/log/messages. Use it to make sure all your zone files are loaded when you start BIND/named. Check your /etc/named.conf file if they fail to do so. (Linux logging is covered in Chapter 5, 'Troubleshooting Linux with syslog'.

Feb 21 09:13:13 bigboy named: named startup succeeded

Feb 21 09:13:13 bigboy named[12026]: loading configuration from '/etc/named.conf'

Feb 21 09:13:13 bigboy named[12026]: no IPv6 interfaces found

Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface lo, 127.0.0.1#53

Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface wlan0, 192.168.1.100#53

Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface eth0, 172.16.1.100#53

Feb 21 09:13:14 bigboy named[12026]: command channel listening on 127.0.0.1#953

Feb 21 09:13:14 bigboy named[12026]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700

Feb 21 09:13:14 bigboy named[12026]: zone 1.16.172.in-addr.arpa/IN: loaded serial 51

Feb 21 09:13:14 bigboy named[12026]: zone 1.168.192.in-addr.arpa/IN: loaded serial 51

Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 2004021401

Feb 21 09:13:14 bigboy named[12026]: zone localhost/IN: loaded serial 42

Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 200301114

Feb 21 09:13:14 bigboy named[12026]: running

3) Use the host (nslookup in Windows) command for both forward and reverse lookups to make sure the zone files were configured correctly.

If this fails, try:

Double check for your updated serial numbers in the modified files and also inspect the individual records within the files for mistakes.

Ensure there isn't a firewall that could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.

Use the dig command to determine whether the name server for your domain is configured correctly.

Here is an example of querying DNS server ns1.my-site.com for the IP address of www.linuxhomenetworking.com. (You can also replace the name server's name with its IP address.)

[root@bigboy tmp]# host www.linuxhomenetworking.com ns1.my-site.com

Using domain server:

Name: ns1.my-site.com

Address: 192.168.1.100#53

Aliases:

www.linuxhomenetworking.com has address 65.115.71.34

[root@bigboy tmp]#

Here is an example of querying your default DNS server for the IP address of www.linuxhomenetworking.com. As you can see, the name of the specific DNS server to query has been left off the end. Failure in this case could be due not only to an error on your BIND configuration or domain registration but also to an error in your DNS client's DNS server entry in your Linux /etc/resolv.conf file or the Windows TCP/IP properties for your NIC.

[root@bigboy tmp]# host www.linuxhomenetworking.com

www.linuxhomenetworking.com has address 65.115.71.34

[root@bigboy tmp]#

4) You can also use the dig command to determine whether known DNS servers on the Internet have received a valid update for your zone. (Remember if you decide to change the DNS servers for your domain that it could take up to four days for it to propagate across the Internet.)

The format for the command is:

dig <domain-name> <name-server> soa

The name server is optional. If you specify a name server, then dig queries that name server instead of the Linux server's default name server. It is sometimes good to query both your name server, as well as a well known name server such as ns1.yahoo.com to make sure your DNS records have propagated properly. The dig command only works with fully qualified domain names only, because it doesn't refer to the /etc/resolv.conf file.

This command uses the local DNS server for the query. It returns the SOA record information and the addresses of the domain's DNS servers in the authority section.

[root@bigboy tmp]# dig linuxhomenetworking.com SOA

;; AUTHORITY SECTION:

linuxhomenetworking.com. 3600 IN NS ns1.myisp.net.

linuxhomenetworking.com. 3600 IN NS ns2.myisp.net.

;; ADDITIONAL SECTION:

ns1.myisp.net. 3600 IN A 65.115.70.68

ns2.myisp.net. 3600 IN A 65.115.70.69

[root@bigboy tmp]#

Here is a successful dig using DNS server ns1.yahoo.com for the query. As before, it returns the SOA record for the zone.

[root@bigboy tmp]# dig ns1.yahoo.com linuxhomenetworking.com SOA

;; AUTHORITY SECTION:

linuxhomenetworking.com. 3600 IN NS ns2.myisp.net.

linuxhomenetworking.com. 3600 IN NS ns1.myisp.net.

;; ADDITIONAL SECTION:

ns1.myisp.net. 3600 IN A 65.115.70.68

ns2.myisp.net. 3600 IN A 65.115.70.69

[root@bigboy tmp]#

Sometimes your SOA dig will fail. This command uses the DNS server ns1.yahoo.com for the query. In this case the authority section doesn't know of the domain and points to the name server for the entire .com domain at VeriSign.

[root@bigboy tmp]# dig ns1.yahoo.com linuxhomeqnetworking.com SOA

;; QUESTION SECTION:

;linuxhomeqnetworking.com. IN SOA

;; AUTHORITY SECTION:

com.  0 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1077341254 1800 900 604800 900

[root@bigboy tmp]#

Possible causes of failure include:

Typographical errors. In this case the misspelling 'linuxhomeqnetworking.com' was entered on the command line.

Incorrect domain registration.

Correct domain registration, but there is a lag in the propagation of the domain information across the Internet. Delays of up to four days are not uncommon.

A firewall could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.

Migrating Your Web Site In-House

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

There is no magic bullet that 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 is 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 one minute. As the TTL is usually set to a number of days, it will take at least three to five days for all remote DNS servers to recognize the change. Once the propagation is complete, it will take only one 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 test server in house. Edit the /etc/hosts file to make www.my-site.com refer to its own IP address, not that of the www.my-site.com site that is currently in production. This file is usually given a higher priority than DNS, therefore the test server will begin to think that www.my-site.com is really hosted on itself. You may also want to add an entry for mail.my-site.com if the new Web server is going to also be your new mail server.

Test your server based applications from the server itself. This should include mail, Web, and so on.

Test the server from a remote client. You can test the server running as www.my-site.com even though DNS hasn't been updated. Just edit your /etc/hosts file on your Web browsing Linux PC to make www.my-site.com map to the IP address of the new server. In the case of Windows, the file would be C:WINDOWSsystem32driversetchosts. You may also want to add an entry for mail.my-site.com if the new Web server is going to also be your new mail server. Your client will usually refer to these files first before checking DNS, hence you can use them to predefine some DNS lookups at the local client level only.

Once testing is completed, coordinate with your Web hosting provider to update your domain registration's DNS records for www.my-site.com to point to your new Web server. As the TTLs were set to one minute previously, you'll be able to see results of the migration within minutes.

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

Fix your /etc/hosts files by deleting the test entries you had before.

You may also want to take over your own DNS. Edit your my-site.com DNS entries with VeriSign, RegisterFree or whoever you bought your domain from to point to your new DNS servers.

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 then migrate these services in-house as your confidence in hosting becomes greater.

Finally, if you have concerns that your service provider won't cooperate, then you could explain to the provider that you want to test its 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 Chapter 8, 'Configuring the DHCP Server'.

Simple DNS Security

DNS can reveal a lot about the nature of your domain. You should take some precautions to conceal some of the information for the sake of security.

Zone Transfer Protection

The host command does one DNS query at a time, but the dig command is much more powerful. When given the right parameters it can download the entire contents of your domain's zone file.

In this example, the AFXR zone transfer parameter is used to get the contents of the my-site.com zone file.

[root@smallfry tmp]# dig my-site.com AXFR

; <<>> DiG 9.2.3 <<>> my-site.com AXFR

;; global options: printcmd

my-site.com. 3600 IN SOA www.my-site.com. hostmaster.my-site.com. 2004110701 3600 3600 3600 3600

my-site.com. 3600 IN NS ns1.my-site.com.

my-site.com. 3600 IN MX 10 mail.my-site.com.

192-168-1-96.my-site.com. 3600 IN A 192.168.1.96

192-168-1-97.my-site.com. 3600 IN A 192.168.1.97

192-168-1-98.my-site.com. 3600 IN A 192.168.1.98

bigboy.my-site.com. 3600 IN A 192.168.1.100

gateway.my-site.com. 3600 IN A 192.168.1.1

localhost.my-site.com. 3600 IN A 127.0.0.1

mail.my-site.com. 3600 IN CNAME www.my-site.com.

ns1.my-site.com. 3600 IN CNAME www.my-site.com.

ntp.my-site.com. 3600 IN CNAME www.my-site.com.

smallfry.my-site.com. 3600 IN A 192.168.1.102

www.my-site.com. 3600 IN A 192.168.1.100

my-site.com. 3600 IN SOA www.my-site.com. hostmaster.my-site.com. 2004110701 3600 3600 3600 3600

;; Query time: 16 msec

;; SERVER: 192.168.1.100#53(192.168.1.100)

;; WHEN: Sun Nov 14 20:21:07 2004

;; XFR size: 16 records

[root@smallfry tmp]#

This may not seem like an important security threat at first glance, but it is. Anyone can use this command to determine all your server's IP addresses and from the names determine what type of server it is and then launch an appropriate cyber attack.

In a simple home network, without master and slave servers, zone transfers should be disabled. You can do this by applying the allow-transfer directive to the global options section of your named.conf file.

options ;

Once applied, your zone transfer test should fail.

[root@smallfry tmp]# dig my-site.com AXFR

 ; <<>> DiG 9.2.3 <<>> my-site.com AXFR

 ;; global options: printcmd

 ; Transfer failed.

[root@smallfry tmp]#

Selectively Disabling Recursion

Your caching DNS server can unknowingly participate in a form of DDoS attack if recursive lookups are globally allowed.

Say for example that for political, religious, competitive or otherwise malicious reasons your web site is targeted for an attack. First, a hacker breaks into the authoritative DNS server for a sub domain, like my-web-site.org, and adds a large TXT record to the sub domain. The hacker then sends thousands of queries to unsecured caching DNS servers requesting the TXT record, but there is a catch. The queries use a false source IP address that corresponds to the IP address of the DNS server for your website. The queries are small, but the responses are amplified by the size of the TXT information, and your DNS server quickly becomes overwhelmed by the flurry of replies. Without DNS, your web site goes off the air. For the administrator of the caching DNS servers, the additional load of the queries can be unnoticeable, but when multiplied by thousands of other poorly configured servers, the attack on your site becomes lethal.

The allow-recursion directive placed in the options section of your named.conf file can be used to restrict the networks to which recursive lookups are allowed. In this example an ACL is also used to limit lookups to localhost and the 192.168.1.0/24 network.

acl 'recursive_subnets' ;

options ;

Note: This does not restrict forward or reverse lookups defined by the zone files on the server. The server will answer all queries for my-web-site.org if it owns that domain, but it won't respond to queries for servers in another domain such as google.com.

Naming Convention Security

Your my-site.com domain will probably have a www and a mail subdomain, and they should remain obvious to all. You may want to adjust your DNS views so that to external users, your MySQL database server doesn't have the letters 'DB' or 'SQL' in the name, or that your firewall doesn't have the letters 'FW' in its name either. This may good for ease of reference within the company, but to the Internet these names provide rapid identifiaction of the types of malicious exploits a hacker could use to break in. Web site security refers to anything that helps to guarantee the availability of the site, this is just one of many methods you can use.

Conclusion

DNS management is a critical part of the maintenance of any Web site. Fortunately, although it can be a little complicated, DNS modifications are usually infrequent, because the IP address of a server is normally fixed or static. This is not always the case. There are situations in which a server's IP address will change unpredictably and frequently, making DNS management extremely difficult. Dynamic DNS was created as a solution to this and is explained in Chapter 19, 'Dynamic DNS'.