Using Linux as a Small Business Internet Gateway, Part 2

Listen Print Discuss

Using Linux as a Small Business Internet Gateway, Part 2

by Alexander Prohorenko
12/18/2003

Installing and Configuring DNS

After installing and configuring a Linux Internet Gateway, as described in part one of this series, sometimes workstations inside of the network suffer strange lags while attempting to connect to network resources (printers, common access directories) on other workstations. This happens because in TCP/IP, remote computer names must be converted to and from IP addresses using DNS. Unfortunately, the DNS of your provider knows nothing about the names of computers inside of your network!

Your provider sends the request to other DNS servers. It takes some time. Of course, if the Internet connection isn't up at the moment, DNS isn't available at all. Things will be even worse if network addresses in use within your local network are used by other providers on the global Internet. (This is one good reason to use a non-routable address block.) In this case, you will see hard-to-trace defects and mistakes. For example, your network may stop working after connecting your gateway to the Internet.

We can solve this problem by installing a local DNS service. If we also configure it as caching server, we will be able to minimize our traffic a bit — solving one problem of any dial-up connection.

As before, we need a few packages from the distribution:

# rpm -ihv bind-9.2.1-16.i386.rpm caching-nameserver-7.2-7.noarch.rpm
Prepearing...            ########################################### [100%]
1:bind                   ########################################### [ 50%]
2:caching-nameserver     ########################################### [100%]

The main configuration files are located in two places: /etc/named.conf and database records in /var/named/. Everything is already configured to work as a caching server. We only need two little modifications.

In the options section of /etc/named.conf, add the line:

listen-on { 127.0.0.1; 192.168.0.1; };

This argument causes the server to accept only requests that come from the local interface (the server itself) or the internal network interface. For security reasons, it will not accept requests that come from the Internet.

As usual, the iptables configuration will need a little modification to allow DNS traffic to the gateway and through it to our provider's DNS servers. The new file looks like this:

# Simple firewall for internet gateway
*filter
:INPUT ACCEPT [0:0]

# Deny forward for security reasons
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-FW-INPUT - [0:0]

# Redirect all input-forwarded packets to our special rule
-A INPUT -j RH-FW-INPUT

# Accept all packets for local interface (lo)
-A RH-FW-INPUT -i lo -j ACCEPT

# Define custom rules
# Access to mail services
-A RH-FW-INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -i eth0 -j ACCEPT

# Access to DNS service
-A RH-FW-INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 53 -i eth0 -j ACCEPT
-A RH-FW-INPUT -s 192.168.0.0/24 -p udp -m udp --dport 53 -i eth0 -j ACCEPT

# This part equal to some part from generated by Lokkit utility
-A RH-FW-INPUT -p tcp -m tcp --dport 143             -j ACCEPT
-A RH-FW-INPUT -p tcp -m tcp --dport 0:1023    --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 2049      --syn -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 0:1023          -j REJECT
-A RH-FW-INPUT -p udp -m udp --dport 2049            -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A RH-FW-INPUT -p tcp -m tcp --dport 7100      --syn -j REJECT

# Allow access to external mail/news/DNS
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 25  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 119 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p tcp -m tcp --dport 53  -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -p udp -m udp --dport 53  -j ACCEPT
COMMIT

# Enable masquarading
*nat
:PREROUTING  ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT      ACCEPT [0:0]
-A POSTROUTING -p tcp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
-A POSTROUTING -p udp -s 192.168.0.0/24 -o ppp0 -j SNAT
    --to-source 123.123.123.123
COMMIT

Don't forget to reload iptables:

# service iptables restart

Unfortunately, caching DNS server mode alone isn't enough, because the problem of converting names into IP addresses isn't solved. We'll need to configure the service to support the internal network. As explained in part one of this series, the internal network is 192.168.0.0/255.255.255.0. The gateway address is 192.168.0.1, with a machine name of gateway. The domain name is ourcompany.com. Finally, there are two PCs on the network, named buh and dir, with addresses of 192.168.0.11 and 192.168.0.12, respectively.

We need a few more modifications to configure DNS. First, in /etc/named.conf, describe two zones for direct and reverse conversion:

zone "ourcompany.com" IN {
    type master;
    file "ourcompany.com.zone";
    allow-update {
		none;
	};
    allow-query  {
        192.168.0.0/24;
    };
};
            
zone "0.168.192.in-addr.arpa" IN {
    type master;
    file "named.192.168.0";
    allow-update {
		none;
	};
    allow-query  {
        192.168.0.0/24;
    };
};

The argument type master means that our server is the primary, not secondary, server for this zone. The file argument defines the file name that contains names and addresses for this zone. The allow-update { none; } argument denies base updates from foreign DNS servers. The allow-query { 192.168.0.0/24; } argument allows requests only from our local net clients.

You may find it strange to record zone names for converting addresses to names. The format (0.168.192.in-addr.arpa) comes from the time of a little ARPA network, before the Internet. You just need to remember the syntax.

Next, we will create bases. If there is no full pathname specified, the base directory will be /var/named. This path is defined when the server is compiled and may vary for different Linux distributions. Here's /var/named/ourcompany.com.zone:

$TTL    86400
$ORIGIN ourcompany.com.
@       1D IN SOA       @ root (
            2002092501      ; serial
            3H              ; refresh
            15M             ; retry
            1W              ; expiry
            1D )            ; minimum
                                                                                                    
            1D IN NS        192.168.0.1
            1D IN A         192.168.0.1

gateway     1D IN A         192.168.0.1
buh         1D IN A         192.168.0.11
dir         1D IN A         192.168.0.12

I will not get into details about the file format, describing only the information needed to control services in our little company.

$ORIGIN ourcompany.com. defines the domain name that applies to all subsequent records. For example, the gateway record means gateway.ourcompany.com.. Please notice the dot at the end of the word -- this signifies an absolute value. You shouldn't miss that dot; without it, our record would mean not ourcompany.com, but ourcompany.com..
@ means that this record is of "me." In our case, the name ourcompany.com is in the meaning of hostname, but not the domain name.
IN SOA is the main record and should always be in each DNS database. Please, pay attention especially to serial, the serial number, a date in the format yyyymmddhh. Incrementing this number indicates that the database has changed. If you change the record but do not change this number, your server will not get the command to "re-read database" and it will continue to use old values and records.
IN NS controls the DNS server address in this zone.
IN A defines the name-to-address mapping. Please remember that this record doesn't define the backward meaning. There's another database for that.
1D before IN means that the record is valid for one day. After that, it should be re-read.

In /var/named/named.192.168.0:

$TTL    86400
@     IN    SOA    ourcompany.com. root.ourcompany.com.  (
                   2002092501 ; Serial
                   28800      ; Refresh
                   14400      ; Retry
                   3600000    ; Expire
                   86400 )    ; Minimum

      IN    NS     192.168.0.1
                                                                                
1     IN    PTR    gateway.ourcompany.com.
11    IN    PTR    buh.ourcompany.com.
12    IN    PTR    dir.ourcompany.com.

This database defines the conversions from addresses to names. Its format resembles that of the previous database, with some differences, such as a "new" SOA record type and PTR. It also uses only the last portion of IP addresses within the network.

Pay attention to the final dots. If you miss them, the server will automatically add a domain name to your symbol name (ourcompany.com or 0.168.192.-in-addr.arpa). If the dot is in place, the name will be accepted as is.

It's time to run our server:

# service named start
Starting named:                           [  OK  ]

After startup, please explore the log file /var/messages. You'll find detailed reports there in case of any bugs or errors with your DNS configuration.

Now, let's check how our server works:

$ nslookup -sil
> gateway.ourcompany.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   gateway.ourcompany.com
Address: 192.168.0.1
> 192.168.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

1.0.168.192.in-addr.arpa        name = gateway.ourcompany.com.
> 192.168.0.11
Server:         127.0.0.1
Address:        127.0.0.1#53

11.0.168.192.in-addr.arpa       name = buh.ourcompany.com.
>exit
$

Everything is all right, your server is functioning. If you need to make changes to DNS, you can do it easily any time you like, by modifying database files. Do not forget to update the serial number. The command: