Using bind to establish a DNS server on Linux

Although Linux has not made noticeable progress in the world of desktop computing, it is already a small celebrity as a Web server. Thanks to its excellent reliability, we can safely run all the important service programs that are necessary for today's internet age on Linux. As a result, some of the most common uses of Linux include being used as mail servers, Web servers, and DNS servers.

Here we'll look at how to use bind to establish a DNS server on Red Hat Linux. BIND (Berkeley Internet name domain) is a domain name resolution service package that is implemented on a unix/linux system. We will learn the steps required to build and run a DNS server on Linux, including installation, initial configuration, and system setup.

In this article we use Red Hat as an example, so you might want to use the RPM version of BIND, which can be found by searching www.rpmfind.net, because using the rpm form of the release package is the easiest way to install bind. After you download the bind rpm, such as bind-9.1.0-10.i386.rpm, you need to execute the RPM-IVH bind-9.1.0-10.i386.rpm command as Superuser. When you install bind in RPM, be careful to check for any missing dependencies that can cause the installation to fail.

If you prefer to install from the source package, after downloading files such as bind-9.1.3.tar.gz, you need to run the tar xvfz bind-9.1.3.tar.gz command to extract it as superuser. For this example, a directory named bind-9.1.3 is generated that contains all the files necessary for the installation. Next, go to the newly created directory and execute the./configure command, run make after the script completes all configuration work, and run make install to complete the installation process. Now you should have the basic configuration of BIND installed on your system, and then adjust it as needed.

Configure Bind

Once you've installed the bind in the system, you can configure it in a variety of ways. One of the two most commonly used is the use of ISP type settings, where the DNS server accepts and resolves requests from anyone (or a predefined set of users), and the other is the web host method that only resolves requests for service domain names. When the use of the server changes, you can also change the type of configuration at any time.

The DNS server can be either a master server or a secondary server. Master server is also called as the primary server, is the final source of the decision domain name. The master server is also the source of the zone transfer (zone transfer) that is delivered to the secondary server. The secondary server receives all zone information from the master server. A common mistake is to try to change the zone database file on the secondary server without changing the zone database file (zone file) on the master server. Why two servers? It is a good idea to use redundancy in any configuration, which is a native part of BIND and DNS. Fortunately, adding a second Linux machine to the computer room as a secondary DNS server will not normally affect your budget.

Remember that when there are two types of servers, the master server can also serve as a secondary server for other domains. This can be seen in most ISP environments where customers have their own master DNS servers, while the ISP is treated as a secondary server for backup purposes. This type of configuration and almost all other configuration items in bind are done through the named.conf file. This file holds the server information and the area information in plain text form. As shown in Table A.

named.conf File Example

Options {

Notify-source 10.0.0.2;

Pid-file "/var/run/named.pid";

};

Zone "." {

Type master;

File "Root.db";

};

Zone "example.com" {

Type master;

File "/var/named/sample.com.zone";

};

There are a number of options available for DNS servers, and if you need a particular installation, I recommend that you read through the accompanying documentation. In the example above, Notify-source indicates where the server sends the zone change notification (NOTIFY) message to the secondary server when the master server detects a change in the zone database file. The Pid-file option simply tells the daemon (daemon) server to write the path to the ID information, usually/var/run/named.pid, but if you reset the layout of the directory, you can make changes to it as needed.

The first area registration entry in the example above is used to inform bind where to locate the root server information. The server sends and receives not only your own domain information but also all the domain information on the Internet. Not every server has a registration entry for each domain name, but each server knows how to get information. Of course, because the list is updated regularly, it should be recorded regularly.

The second area entry in the Named.conf sample file is a master field entry, meaning that the DNS server holds valid information for example.com, which all other DNS servers on the Internet will use to reference any information related to this domain. The example.com item references/var/named/sample.com.zone this file. This is a plain text file that tells the DNS server all information about example.com, including serial values, refresh rates, all DNS records, and other items. Table B shows an example of this area database file.

DNS zone Database File example

@ in SOA ns1.sample.com. (

200101111; serial.

14400 Refresh after 4 hours

3600 retry after 1 hour

604800 expire after 1 week

86400); minimum TTL of 1 day

;

; Nameservers

;

In NS ns1.sample.com. ;

In NS ns2.sample.com. ;

;

;D Omain Mail handlers

;

Sample.com. In MX ten Mail

;

; Hosts in order

;

www in A 212.204.219.71

FTP in A 212.204.219.71

Mail in A 212.204.219.71

Pop in CNAME Mail

SOA is the acronym for start of authority, where all the zone files begin with it. The sequential number (serial) enables the server to record the updates that have been made, and it reads the information back into the database as soon as the number has increased since the last time the daemon was started. For example, you can start with 0 and then add a number after each update, or you can use a date item such as 200101111. This is useful because it allows you to see a recent update and see if a day has been updated more than once. The next four lines deal with the refresh and timeout period in seconds, and the server automatically reads the information back if no manual or server-wide refreshes have occurred in the bind database. You do not need to change the values listed here frequently, but you need to change them only because of some reason that the domain changes their information very frequently. Then the domain name is listed, so bind will know who is controlling the entire domain.

The MX record is then listed, which enables the server to know what information should be sent when there is a message request sample.com, in this case, the mail.samle.com priority is 10. You can list multiple MX records as a backup of your mail server. The smaller the number, the higher the priority. It is important to note that a corresponding a record gives the IP address of the mail.sample.com, which is essential so that the DNS server can know how to send the mail request directly to the domain. A a record is simply assigning an IP address to a child domain item, such as WWW, mail, FTP, or NS, which must be entered in the format above and must be associated with an IP address. For example, when a user requests www.sample.com, he will be directed to the IP address of the Web server on which the domain resides 212.104.219.71.

In the example above, there is also a CNAME item, CNAME refers to canonical name, which specifies the alias of the IP address, and when using these aliases, refer back to the already used a record.

After the secondary server section has seen the master server section in name.conf, let's take a look at the secondary server section: zone "sample2.com" {

Type slave;

File "/var/named/sample2.com.zone";

Master {10.0.0.1;};

The main two difference is the type item, which can be either master or slave, and the IP address specifies the master DNS server. Everything else is the same as the master item.

Start bind

The program used to start the DNS service is named, read as "name D". You can run this program by executing the/etc/rc.d/init.d/named start command. If the server is already running, you can use the restart command. This script should be placed in the correct directory at the time of installation, and it will run at startup to initialize the server. You should always check to see if named is running with the PS aux command, which lists the current list of all processes.