Configure DNS part1

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
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 DNS lookup 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.
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.
Configuring A Caching Nameserver
The RedHat/Fedora default installation of BIND is configured to convert your Linux box into a caching name server. The only file you have to edit is /etc/resolv.conf; 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
So, your old entry of
nameserver 192.168.1.1
would be replaced by a new entry of
# 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.
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
File Purpose BIND chroot Location Regular BIND Location
named.conf Tells the names of the zone files to be used for each of your website domains. /var/named/chroot/etc /etc
rndc.key
rndc.conf Files used in named authentication /var/named/chroot/etc /etc
zone files Links all the IP addresses in your domain to their corresponding server /var/named/chroot/var/named /var/named
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 A Regular 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
Configuring named.conf
The 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:
• Forward zone file definitions list files to map domains to IP addresses.
• Reverse zone file definitions list files to map IP addresses to domains.
In this example, you'll set up the forward zone for www.my-site.com 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-site.com" {

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

};
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 { 192.168.1.0/24; };
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" {

type master;
notify no;
file "192-168-1.zone";

};
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.3 explains what each field in the record means.

Table 18.3 The SOA Record Format
Field Description
Name The root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particular database file.
Class There are a number of different DNS classes. Home/SOHO will be limited to the IN or Internet class used when defining IP address mapping information for BIND. Other classes exist for non Internet protocols and functions but are very rarely used..
Type The type of DNS resource record. In the example, this is an SOA resource record. Other types of records exist, which I'll cover later.
Name-server Fully qualified name of your primary name server. Must be followed by a period.
Email-address The e-mail address of the name server administrator. The regular @ in the e-mail address must be replaced with a period instead. The e-mail address must also be followed by a period.
Serial-no A serial number for the current configuration. You can use the date format YYYYMMDD with an incremented single digit number tagged to the end. This will allow you to do multiple edits each day with a serial number that both increments and reflects the date on which the change was made.
Refresh Tells the slave DNS server how often it should check the master DNS server. Slaves aren't usually used in home / SOHO environments.
Retry The slave's retry interval to connect the master in the event of a connection failure. Slaves aren't usually used in home / SOHO environments.
Expiry Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. Slaves aren't usually used in home/SOHO environments.
Minimum-TTL There are times when remote clients will make queries for subdomains that don't exist. Your DNS server will respond with a no domain or NXDOMAIN response that the remote client caches. This value defines the caching duration your DNS includes in this response.
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.4 outlines the way they are laid out.
Table 18.4 NS, MX, A, PTR and CNAME Record Formats
Record
Type Field Descriptions
Name Field Class
Field2 Type
Field Data
Field
NS Usually blank1 IN NS IP address or CNAME of the name server
MX Domain to be used for mail. Usually the same as the domain of the zone file itself. IN MX Mail server DNS name
A Name of a server in the domain IN A IP address of server
CNAME Server name alias IN CNAME "A" record name for the server
PTR Last octet of server's IP address IN PTR Fully qualified server name
1. 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.
2. 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.