Archive for Linux Server (RHEL)

SETTING UP DNS SERVER

Domain Name System

The Domain Name System (DNS) is the crucial glue that keeps computer networks in harmony by converting human-friendly hostnames(Domain Names) to the numerical IP addresses computers require to communicate with each other. DNS is one of the largest and most important distributed databases the world depends on by serving billions of DNS requests daily for public IP addresses. Most public DNS servers today are run by larger ISPs and commercial companies but private DNS servers can also be useful for private home networks. This article will explore some advantages of setting up various types of DNS servers in the home network.

Why set up a private DNS server?

This question is valid and the answer may vary depending on your home network environment. Maintaining a host file on each client with IP/hostname mappings in a home network that contains a router and a few machines may be sufficient for most users. If your network contains more than a few machines, then adding a private DNS server may be more attractive and worth the setup effort. Some advantages may include:

  • Maintenance: keeping track of the host file for every client in your network can be tedious. In fact, it may not even be feasible for roaming DHCP laptops or your occasional LAN party guests. Maintaining host information in one central area and allowing DNS to manage host names is more efficient.

  • Cache performance: DNS servers can cache DNS information, allowing your clients to acquire DNS information internally without the need to access public nameservers. This performance improvement can add up for tasks such as web browsing.

  • Prototyping: A private internal DNS server is an excellent first step to eventually setting up a public accessible DNS server to access a web server or other services hosted on your internal network. Learning from mistakes on an internal network can help prevent duplicate errors on a public DNS server that could result in loss of service for external users. Note: Some ISPs require customers to have a static IP or business subscription when hosting services in a home network environment.

  • Cool factor: Ok, I may be stretching it, but the “cool” factor did have some influence when I set up my first home network DNS server. Creating an internal domain that reflects an individual’s personality without paying a domain registrar and issuing hostnames to your clients is cool. The cool factor doubles when your customized hostname glows from your friend’s laptop screen.

Let’s start out simply by setting up a caching-only nameserver to handle client DNS requests. A caching-only nameserver won’t allow references to internal clients by hostname, but it does allow clients to take advantage of frequently requested domains that are cached.

Caching nameserver

Fortunately, setting up a caching nameserver is easy using RHEL (Red Hat Enterprise Linux) or Fedora RPMs. The following RPMs need to be installed on the machine acting as the nameserver (use rpm -q to determine if these packages are installed):

  • bind (includes DNS server, named)
  • bind-utils (utilities for querying DNS servers about host information)
  • bind-libs (libraries used by the bind server and utils package)
  • bind-chroot (tree of files which can be used as a chroot jail for bind)
  • caching-nameserver (config files for a simple caching nameserver)

A caching nameserver forwards queries to an upstream nameserver and caches the results. Open the file /var/named/chroot/etc/named.conf and add the following lines to the global options section:

forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; #IP of upstream ISP nameserver(s) forward only; #rely completely on our upstream nameservers

The block above will cause the caching name server to forward DNS requests it can’t resolve to your ISP nameserver. Save the named.conf file and then assign 644 permissions:
chmod 644 named.conf
Check the syntax using the named-checkconf utility provided by the bind RPM:
named-checkconf named.conf
Correct any syntax errors (watch those semicolons) named-checkconf reports. Monitoring the /var/log/messages file may also be helpful in debugging any errors.
We now need to set the local resolver to point to itself for DNS resolution. Modify the/etc/resolv.conf file to the following:
nameserver 127.0.0.1
If you are running a DHCP server on your router make sure your /etc/resolv.conf file does not get overwritten whenever your DHCP lease is renewed. To prevent this from happening, modify /etc/sysconfig/network-scripts/ifcfg-eth0 (replace eth0 with your network interface if different) and make sure the following settings are set:

BOOTPROTO=dhcp
PEERDNS=no
TYPE=Ethernet

Go ahead and start the nameserver as root and configure to start in runlevels 2-5:
service named start
chkconfig named on

Testing

The bind-utils RPM contains tools we can use to test our caching nameserver. Test your nameserver using host or dig and querying redhat.com:

dig redhat.com
.
.
;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

From the above dig query you can see it took 42 msec to receive the DNS request. Now test out the caching ability of your nameserver by running dig again on the redhat.com domain:

dig redhat.com
.
.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

We dropped from 42 msec to 1 msec after the previous DNS query was cached. Caching is working! Let’s now put the cache to work by configuring the clients to use the new caching nameserver.

Client Configuration

For Linux and Windows clients you may have a couple of options for your resolver configuration depending on your network environment:

  1. If you have a router and your client’s IP address is assigned via DHCP from the router, then you can use the router to assign the primary nameserver during the DHCP lease requested from the client. Log in to your router and make sure your primary nameserver points to your caching nameserver IP address in the router DHCP settings.

  2. For Linux clients, you can set up the resolver in the same procedure as the nameserver by modifying the /etc/resolv.conf file. For Windows clients you will need to set the nameserver IP address in the Control Panel -> Network Connections -> TCP/IP -> Properties -> Use the DNS Server Address option. NOTE: The Windows DNS server option may vary depending on your version.

Test your new client configuration(s) using dig. You can use the nslookup command for Windows clients. Your DNS requests should have similar response times as we saw earlier when testing the nameserver directly.

NOTE: If you are running a firewall on the nameserver system, make sure clients have access to port 53. An example iptables rule for the 192.168.15.0/24 subnet would be:
iptables -A INPUT -s 192.168.15.0/24 -p udp --dport 53 -j ACCEPT
service iptables save

Summary

Your new caching nameserver offers a performance improvement with a minimal amount of set up effort. Clients can now ask the caching nameserver for DNS information, and it only needs to ask the upstream ISP nameserver for cache misses. In the next issue we will setup a master nameserver that is responsible for the authoritative information for our internal client hostnames. An authoritative nameserver also caches by default but additionally allows managing both static and DHCP clients using personalized hostnames set up in zone files. In the meantime, enjoy your new caching nameserver and be thinking about a creative domain and hostname theme for your future authoritative nameserver.

 

Install and configure the BIND DNS server

BIND which is also known as NAMED is the most widely used DNS server software in the world. The Berkeley Internet Name Domain (BIND) is  domain name server software that can run on Linux, Unix, and Windows computer operating systems. 

Steps

1. Make sure you have internet connectivity and install the BIND DNS server.
yum install bind

2. Set your DNS server setting to resolve to your loopback interface by echoing to /etc/resolv,.conf or by editing your your outside interface configuration file (example: ifcfg-eth0) adding the line: DNS1=127.0.0.1, and taking the interface down and up again (ifdown eth0, ifup eth0). The benefit to editing the ifcfg file and then bringing the interface down and up again is that the confguration will be permanent, whereas echoing to resolv.conf is not a saved configuration. Once you set the DNS server setting to 127.0.0.1 you will lose internet connectivity until you restart BIND.
echo “nameserver 127.0.0.1” > /etc/resolv.conf  
or
vim /etc/sysconfig/network-scripts/ifcfg-eth0
add the following line to the configuration file: DNS1=127.0.0.1
ifdown eth0
ifup eth0

3. Check the resolve.conf file to verify that your DNS setting of 127.0.0.1 is available.
cat /etc/resolv.conf

4. Restart the BIND DNS server. The BIND DNS server is referenced by command as “named”  pronounced “name – d”, the name daemon.
service named restart 

5. Now try to see if your DNS server can reach other DNS servers over the internet in order to resolve dns lookups.
nslookup google.com

Troubleshooting – If you get a “server can’t find google.com SERVFAIL” message you can try these troubleshooting scenarios:
1) If you are using VMware virtual machines try shutting down your Windows firewall
2) Make sure your iptables is accepting traffic on the loopback interface. Use the iptables-save command and you should see the following line: -A INPUT -i lo -j ACCEPT . If not, you can add it directly to the iptables configuration file by editing /etc/sysconfig/iptables. Then restart iptables: service iptables restart
3) Also, check that you have the right date set on your system. Use the 
date command to check the date and timestamp. You can fix it with the following command: date -s ‘year-month-date time’ (e.g. 2012-4-23 12:10:00). I experienced DNS server nslookup failure due to incorrect date.
4) If you still have problems and are unable to resolve domain names using nslookup then try looking at your log files: tail /var/log/messages

6. Now put in a chkconfig command to allow BIND (NAMED) to start on system startup.
chkconfig named on

7. Before you begin configuring the DNS server you should know what your hostname. You were asked to create your hostname (computer name) during your CentOS linux installation. Your hostname follows your username and the “@” symbol in your terminal command prompt. For instance, my terminal shows the following prompt [dan@centos-server ~]$, “dan” is the username, “centos-server” is the hostname, ” ~ ” refers to my current directory – which is home, and the “$” prompt means I am in user mode as “dan” (a # would mean I am currently the root user). To verify your hostname type the command hostname in the terminal and hit enter.
hostname

You can temporarily change the hostname by issuing the hostname command. However this will not be permanent upon restart.
hostname <example-server-name>

To permanently change the system hostname even upon reboot, edit the following file in a text editor: /etc/sysconfig/network
nano /etc/sysconfig/network
and add the following line after NETWORKING=”yes”:
HOSTNAME=”example-server-hostname” 

8. Beyond knowing the server hostname, to use the full potential of the DNS server you will also need to know your fully qualified domain name (FQDN). You will probably need to configure your servers FQDN. To do this you will need to edit the configuration file of your outside facing network interface using a text editor, in my example the file is ifcfg-eth0.
nano /etc/sysconfig/network-scripts/ifcfg-eth0

and add your domain name by adding a line to the configuration file:
DOMAIN=”example.com”

then take the interface up and down. Check to see if the change is reflected in the /etc/resolv.conf file, and the run thehostname –fqdn command to see your FQDN. The FQDN should be your server hostname followed by a dot and your domain name (e.g. example-server-hostname.example.com). If your computer does not recognize your fully qualified domain name (fqdn), just keep going, the server should recognize the FQDN by the time you have finished configuring the DNS server conf file and zone files.
ifdown eth0
ifup eth0
cat /etc/resolv.conf
hostname –fqdn

9. Now that your hostname and fully qualified domain name are configured it is time to configure the BIND (NAMED) DNS server.The first file to configure is: /etc/named.conf
nano /etc/named.conf

10. Now you can add master lookup zones to the named.conf file like the entries in my example below. I inserted the two zones right before the line ( zone “.” IN { ). The first zone is for forward lookups and the second zone is for reverse lookups. Forward lookups resolve names to IP addresses and reverse lookups resolve ip addresses to names. Make sure to substitute your own domain name and the network portion of your IP address in reverse (outside interface).

 zone “example.com” IN {
type master;
file “example.com.zone”;
allow-update { none; };
};

zone “1.168.192.in-addr.arpa” IN {
type master;
file “example.com.rr.zone”;
allow-update { none; };
};

11. You can see in the two zones above that the third line in each zone references a file (example.com.zone and example.com.rr.zone). You will need to create two text files, one to match each of those names, and save them in the/var/named/ directory.
touch /var/named/example.com.zone
touch /var/named/example.com.rr.zone

12. Now you will need to edit and save each file with zone configurations. Make sure to substitute your own domain name and IP address (outside interface). First, the forward lookup zone file.
nano /var/named/example.com.zone

$ORIGIN example.com.
$TTL 86400
@    IN    SOA    dns1.example.com.    hostmaster.example.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.example.com.

IN    MX    10    mail.example.com.

IN    A    192.168.1.113

dns1    IN    A    192.168.1.113

example-server-hostname    IN    A    192.168.1.113

ftp    IN    A    192.168.1.113

mail    IN    CNAME    example-server-hostname

www    IN    CNAME    
example-server-hostname
13. Second, the reverse lookup zone file.
nano /var/named/example.com.rr.zone

$ORIGIN 1.168.192.in-addr.arpa.
$TTL 86400
@    IN    SOA    dns1.example.com.    hostmaster.example.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     example-server-hostname.example.com.

1    IN    PTR    example-server-hostname.example.com.

2    IN    PTR    dns1.example.com.

3    IN    PTR    ftp.example.com.

4    IN    PTR    mail.example.com.
14. Now restart your server and try resolving your domain names with nslookup. You should see that they resolve to your server!!!
service named restart
nslookup example.com
nslookup dns1.example.com
nslookup mail.example.com
nslookup ftp.example.com
nslookup www.example.com
nslookup example-server-hostname.example.com