Make your own free website on Tripod.com

Infrablue atTripod

 

 


Quick Setup Guide for a secure BIND Nameserver Installation
 



This guide describes a fairly simple yet secure nameserver setup using the popular BIND (Berkeley Internet Name Daemon) nameserver version 9.  The setup described herein is one that a typical small business or individual would employ to 1) provide primary DNS for their own domain(s); and 2) provide nameservice for hosts on a private local network.

We want to have our nameserver system be authoritative for domain lookups for the domains we are hosting and to serve as the primary (or it could be a backup) nameserver for all the machines on our local LAN.  For machines not inside our LAN we only want it to anser domain queries for the domains we are hosting.  We do not want other people on the outside to be able to use our nameserver as a generic nameserver since this could lead to large amounts of unwanted traffic and bandwidth consumption.

The key to doing this is to create two different "views".  Views are defined in /etc/bind/named.conf and enable the creation of different profiles.  We are going to create two views named external and internal.  In this example our private LAN is on a 192.168.1.0/24 subnet.  The domain we will be hosting will be called ourdomain.org and also somedomain.org  Our external IP address is 123.45.67.89


// named.conf
// primary configuration file for the BIND DNS server named.

options {
        directory "/var/cache/bind";
};

acl "ourdomain-subnet" { 192.168.1.0/24; };

view "internal" {
        match-clients { "ourdomain-subnet"; };

        forwarders {
                123.12.23.12;
                123.12.23.13;
        };
//  #   auth-nxdomain no;    # conform to RFC1035
       

  // prime the server with knowledge of the root servers
  zone "." in {
        type hint;
        file "/etc/bind/db.root";
  };

  zone "localhost" in {
        type master;
        file "/etc/bind/db.local";
  };

  zone "127.in-addr.arpa" in {
        type master;
        file "/etc/bind/db.127";
  };

  zone "0.in-addr.arpa" in {
        type master;
        file "/etc/bind/db.0";
  };

  zone "255.in-addr.arpa" in {
        type master;
        file "/etc/bind/db.255";
  };

  // add entries for other zones below here

  zone "ourdomain.org" in {
        type master;
        file "db.ourdomain.org";
        allow-transfer {
          200.11.22.33;
          200.11.22.44;
        };
  };

  zone "somedomain.org" in {
        type master;
        file "db.somedomain.org";
        allow-transfer {
          200.11.22.33;
          200.11.22.44;
        };
  };

 
  zone "67.45.123.in-addr.arpa" in {
        type master;
        file "db.123.45.67";
  };

};

view "external" {

  match-clients { any; };
  recursion no;

  zone "67.45.123.in-addr.arpa" in {
        type master;
        file "db.123.45.67";
  };

  zone "ourdomain.org" in {
        type master;
        file "db.ourdomain.org";
        allow-transfer {
          200.11.22.33;
          200.11.22.44;
        };
  };

  zone "somedomain.org" in {
        type master;
        file "db.somedomain.org";
        allow-transfer {
          200.11.22.33;
          200.11.22.44;
        };

  };

};



The allow-transfer stanzas are for allowing zone transfers to our secondary nameservers which are hosted elsewhere.  Another, more secure way to allow zone tranfers to specific hosts is to use TSIG keys.  I leave it the reader to configure TSIG key transfers if he wants.

All the zone files are in /var/cache/bind.  Zone 67.45.123.in-addr.arpa is the reverse-lookup zone for our external IP.  The forwarders stanza near the top contains addresses of external nameservers (usually these are provided by our ISP).  When DNS requests come in from hosts on our internal LAN for which we are neither authoritative nor have a cached record the requests are forwarded out to the external servers.  This speeds up name resolution on our LAN since repeatedly requested records can be answered by our local nameserver and not by external servers.

I am only going to provide one example zone file.  It is left to the reader to set up the other zone files including the reverse zone file.  The reader is urged to read the BIND HOWTO at www.tldp.org and to purchase the excellent O'Reilly volume "DNS and BIND" as further reference.


;
; BIND data file for ourdomain.org
;
$TTL    604800
@       IN SOA  serv1.ourdomain.org. admin.ourdomain.org. (
                             22         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
                        IN      NS      serv1.ourdomain.org.
                        IN      NS      ns1.somewhere.net.
                        IN      NS      ns2.somewhere.net.
                        IN      MX  0   mail.ourdomain.org.
                        IN      A       123.45.67.89
www                     IN      A       123.45.67.89
ns                      IN      A       123.45.67.89
mail                    IN      A       123.45.67.89
clock                   IN      A       123.45.67.89
time                    IN      A       123.45.67.89
;EOF



This is the zone file for ourdomain.org.  It specifies that the server running BIND is serv1.ourdomain.org.  Mail is to be sent to admin@ourdomain.org (make sure he exists in /etc/aliases).  ns1 and ns2.somewhere.net are two secondary servers for our domain.  In addition to ourdomain.org, we have www.ourdomain.org as well as ns , mail, clock, and time.  I like to run my own NTP servers hence clock and time.  Mail is set up so I can have a virtual host under apache running a web mail server at mail.ourdomain.com.  There is also an MX record for mail.domain.com not to be confused with the A record by the same name.  Read further documentation to find out about adding MX records for additional hosts.  Don't forget that the serial number must be incremented by 1 each time the  zone file is changed in order to ensure that the change gets propagated to the secondary servers.