Chapter 19

Chapter – 19 Berkeley Internet Name Domain (BIND)

Objectives: At the end of this module, you would have gained fair knowledge on: •History of DNS •Type of DNS Servers •Configuring DNS servers

An IP address helps a computer system to identify itself in a network. Referring hosts by their IP address is convenient for computers, but humans have an easier time working with names. Obviously, we need some sort of translation table to convert IP address to hostnames. With millions of computers on the Internet and new ones popping up every day, it would be impossible for everyone to keep this sort of table upto-date. This is where DNS comes in.

The Domain Name Service (DNS) is the system by which each site maintains its own mapping of IP addresses to machine names. Each site puts this mapping into a publicly accessible database, so anyone can fine the IP address corresponding to a hostname in the site simply by querying the site’s database.

The hosts.txt File In the early days of the Internet there were only a few hundred of computers connected to the Internet, every computer had a file called hosts.txt. This file contains all the information about every host on the network, including the name-toaddress mapping. With so few computers, the file was small and could be maintained easily. There was centralized authority to maintained this hosts.txt file. When administrators wanted a change to the hosts.txt file, they e-mailed the request to this centralized authority and, which incorporated the request.

This meant that the administrator also had to periodically compare their hosts.txt file against the centralized authorities hosts.txt file and, if the files were different, the administrator had to ftp a new copy of the file. When the number of hosts in Internet is increased from few hundred to few thousands and then to millions, it is become practically impossible to maintain a hosts.txt file each and every machines. So in September 1984 a new system known as the Domain Name System (DNS) was introduced. It has been the standard method for publishing and retrieving hostname information on the Internet ever since.

Zones On the Internet, the FQDN of a host can be broken down into different sections, and these sections are organized in a hierarchy much like a tree, with a main trunk, primary branches, secondary branches, and so forth. Consider the following FQDN: aita.sales.domain.com When looking at how a FQDN is resolved to find the IP address that relates to a particular system, you must read the name from right to left, with each level of the hierarchy divided by dots (.). In this example, the com defines the top level domain for this FQDN. The domain name is a subdomain under com, with sales as a sub-domain under domain. The name furthest left in a FQDN is the hostname, identifying a particular machine.

Zones are defined on authoritative nameservers through the use of zone files, which describe the namespace of that zone, the mail servers to be used for a particular domain or sub-domain, and much more. Zone files are stored on primary nameservers (also called master nameservers), which are truly authoritative and where changes are made to the files, and secondary nameservers, which receive their zone files from the primary nameservers. Any nameserver can be a primary and secondary nameserver for different zones at the same time, and they may also be considered authoritative for multiple zones. It all depends on the nameserver's particular configuration..

Types of Nameservers There are four primary nameserver configuration types: 1. master — Stores original and authoritative zone records for a certain namespace, answering questions from other nameservers searching for answers concerning that namespace. 2. slave — Also answers queries from other nameservers concerning namespaces for which it is considered an authority. However, slave nameservers get their namespace information from master nameservers via a zone transfer, 3. caching-only — Offers name to IP resolution services but is not authoritative for any zones. Answers for all resolutions are usually cached in a database stored in memory for a fixed period of time, usually specified by the retrieved zone record, for quicker resolution for other DNS clients after the first resolution. 4. forwarding — Forwards requests to a specific list of nameservers to be resolved. If none of the specified nameservers can perform the resolution, the process stops and the resolution fails.

BIND as a Nameserver Red Hat Linux includes BIND, which is a very popular, powerful, open source nameserver. BIND uses the named daemon to provide its name resolution services. All configuration information for BIND is kept in the /etc/named.conf file and its zone files are in the /var/named directory. BIND version 9 includes a utility called rndc to allow the administration of the running named daemon.

BIND Configuration Files The BIND nameserver named server uses the /etc/named.conf file for configuration. All zone files are placed in the /var/named directory. The /etc/named.conf file must be free of errors in order for named to start. While some erroneous options used in with some statements are not considered critical enough to stop the server, any errors in the statements themselves will prevent named from starting.

/etc/named.conf The /etc/named.conf file is a collection of statements using nested options placed in ellipses { }. A sample /etc/named.conf file is organized as follows <statement-1> ["<statement-1-name>"] [<statement-1-class>] { ; ; ; }; <statement-2> ["<statement-2-name>"] [<statement-2-class>] { ; ; ; };

Sample Zone Statements Most changes to the /etc/named.conf file of a master or slave nameserver concerns adding, modifying, or deleting zone statements. While these zone statements can contain many options, most nameservers use few of them. The following zone statements are very basic examples that may be used in a master-slave nameserver relationship. A zone statement on a primary nameserver hosting the domain domain.com may look like given below zone "domain.com" IN { type master; file "domain.com.zone"; allow-update { none; }; };

A slave server's zone statement for domain.com might look like below zone "domain.com" { type slave; file "domain.com.zone"; masters { 192.168.0.1; }; }; This zone statement tells named on the slave server to look to the 192.168.0.1 master server to find out the configuration information for the zone called domain.com. The information the slave server receives from the master server is saved in the /var/named/domain.com.zone file.

Zone Files Zone files, which contain information about a particular namespace, are stored in the named working directory. By default, this is /var/named. Each zone file is named according to the file option data in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone. Each zone file may contain directives and resource records. Directives tell the nameserver to do a certain thing or apply a special setting to the zone. Resource records define the parameters of the zone, assigning an identity within the zone's namespace to particular systems. Directives are optional, but resource records are required to provide nameservice to that zone

Zone File Resource Records 1. A — Address record, which specifies an IP address to assign to a name. IN A If the value is omitted, then an A record points to a default IP address for the top of the namespace. This system will be the target of all non-FQDN requests. Consider the following A record examples for the domain.com zone file: IN A 10.0.1.3 server1 IN A 10.0.1.5 Requests for domain.com are pointed to 10.0.1.3, while requests for server1.domain.com are pointed to 10.0.1.5.

Zone File Resource Records 2. CNAME — Canonical name record, which tells the nameserver that one name is also known as another.

IN

CNAME



In the above statement, any requests sent to the will point to the host named . CNAME records are most commonly used to point services that use a common naming scheme to the correct host. Consider this example, where an A record sets a particular hostname to an IP address and a CNAME record points the commonly used www hostname to it. server1 www

IN IN

A 10.0.1.5 CNAME server1

Zone File Resource Records 3. MX — Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go. IN MX <preference-value> <email-server-name> In the above entry, the <preference-value> allows you to numerically rank the email servers you would prefer to receive email for this namespace, giving preference to some email systems over others. The <email-server-name> may be a hostname or FQDN, as long as it points to the correct system. IN MX 10 mail.domain.com. IN MX 20 mail2.domain.com.

Zone File Resource Records 4. NS — NameServer record, which announces the authoritative nameservers for a particular zone. IN

NS



The should be a FQDN. In the below example, two nameservers are listed as authoritative for a domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.

5. PTR — PoinTeR record, designed to point to another part of the namespace. PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. See the section called Reverse Name Resolution Zone Files for more examples of PTR records in use. 6. SOA — Start Of Authority record, proclaiming important authoritative information about the namespace to the nameserver. Located after the directives, an SOA record is the first resource record in a zone file. @ IN SOA <primary-name-server> ( <serial-number> <minimum-TTL> )

A very basic zone file is shown below $ORIGIN domain.com $TTL 86400 @ IN SOA dns1.domain.com. hostmaster.domain.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.domain.com. IN NS dns2.domain.com. IN MX 10 mail.domain.com. IN MX 20 mail2.domain.com. IN A 10.0.1.5 server1 IN A 10.0.1.5 server2 IN A 10.0.1.7 dns1 IN A 10.0.1.2 dns2 IN A 10.0.1.3 ftp IN CNAME server1 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server2

Reverse Name Resolution Zone Files A reverse name resolution zone file is used to translate an IP address in a particular namespace into a FQDN. It looks very similar to a standard zone file, except that PTR resource records are used to link the IP addresses to a certain system's name. A PTR record is written in a manner similar to below example

IN

PTR



The relates to the last number in an IP address that should point to a particular system's FQDN. In the example given below, IP addresses 10.0.1.20 through 10.0.1.25 are pointed to corresponding FQDNs. $ORIGIN 1.0.10.in-addr.arpa $TTL 86400 @ IN SOA dns1.domain.com. hostmaster.domain.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.domain.com. IN NS dns2.domain.com. 20 IN PTR alice.domain.com. 21 IN PTR betty.domain.com. 22 IN PTR charlie.domain.com.

This zone file would be called into service with a zone statement in the /etc/named.conf file that looks like below zone "1.0.10.in-addr.arpa" IN { type master; file "domain.com.rr.zone"; allow-update { none; }; }; There is very little difference between this example an a standard zone statement, except for how the zone is named. Note that a reverse name resolution zone requires the first three blocks of the IP address to be reversed and ".inaddr.arpa" to be included after them. This allows the single block of IP numbers used in the reverse name resolution zone file to be correctly attached with this zone.