Tuesday, January 22, 2008

Linux|Create your own Domain Name Server (DNS) - ossPro

Linux: Create your own Domain Name Server (DNS) - ossPro

Linux: Create your own Domain Name Server (DNS)

One vital step to hosting your own domain is to set up a domain name server. One nice solution is to use Linux and the Berkeley Internet Name Domain(BIND) software. The primary job of a domain name server is to allow you and your users to associate your domains and subdomains with IP addresses. Oddly enough, even though the software is called BIND the daemon that you run is called named.

Generally speaking, you will need to have two servers (or at least two ip addresses) to act as nameservers. One will be the master nameserver where you set up all your settings and make all your changes and one will be the slave that will act as redundancy and will gather information from the master. Once you have set up your two name servers correctly you would associate them as your domain's nameservers with the domain registrar (example: GoDaddy) that you used to register the domain.

For our purposes, I will be using the tools and syntax available on Redhat based Linux Distributions ( Redhat, Fedora, CentOS, etc). The basic ideas and set up process would be similar if not the same on any other Linux Distribution.

Installation

# yum install bind bind-chroot

As you can see here we not only installed bind but we also installed a package called bind-chroot. This second package sets things up so that named runs in a chrooted environment (like a prison within a subdirectory so that it does not have access to anything but the contents of that subdirectory). You can install and use bind without the chrooted environment if you wish but I would not recommend it. With it you can minimize the damage if a cracker were to actually find and exploit a bug in named.

Configuring the Master Nameserver

Let's say that we own the domain example.com and have 4 servers we plan to use for that domain; a webserver at 192.168.1.1 , our master nameserver at 192.168.1.2, our slave nameserver at 192.168.1.3, and an email server at 192.168.1.4. It is entirely possible (and quite common) to have one server act as a webserver, email server, and a nameserver. However, for this example we'll separate them to avoid confusion.


/var/named/chroot/etc/named.confDownload This File

options{         directory       "/var/named/"; };
The only option we set (for now) is the directory for the zone files. Even though we set it to /var/named the files will actually be located in /var/named/chroot/var/named since named is chrooted to /var/named/chroot.
zone "example.com" {         type    master;         file    "example.com.zone";         allow-transfer { 192.168.1.3; }; };
This is our domain's zone definition. We point to the zone file that will hold the details and allow transfer to what will be our slave nameserver.
zone "1.168.192.in-addr.arpa" {         type master;         file "1.168.192.in-addr.arpa.zone"; };
This is the zone for reverse lookups to any of our IP addrsses that start with 192.168.1. A reverse lookup allows us to translate from ip address to domain name instead of just domain to IP.



Now let's create the two zone files we defined in named.conf.


/var/named/chroot/var/named/example.com.zoneDownload This File

$TTL 900                                        ; Default time to cache negative responses for this zone.
In the first line of the zone file we define the default TTL (Time to LIve) for this zone. As Murray has pointed out in the comments below, as of BIND 9 this value is now how many seconds to cache negative answers.
@               SOA     example.com. (          ; example.com is the primary server for this zone                         webmaster               ; contact email is webmaster@example.com                         2007112800              ; Serial ID in reverse date format                         21600                   ; Refresh interval for slave servers                         1800                    ; Retry interval for slave servers                         604800                  ; Expire limit for cached info on slave servers                         900 )                   ; Minimum Cache TTL in zone records
Here we have the SOA (Start of Authority) section of the zone file. This is where we define various information and time limits (in seconds). One thing to note here is the Serial ID which is basically just an integer that let's the slave servers know whether this file has changed or not. 2007112800 would be the first revision on 11/28/2007 whereas 2008010101 would be the second revision on 01/01/2008
@               NS      ns1                     ; ns1.example.com is a nameserver for example.com  @               NS      ns2                     ; ns2.example.com is a nameserver for example.com
Here we define the authoritative nameservers for this domain. A non-authoritative nameserver (or dns response) would be from your ISP's dns for example.
@               MX      10 mail.example.com.    ; mail.example.com is the mail server for this zone 
The MX (Mail Exchange) record defines this domain/zone's email server (mail.example.com in this case).
@               A       192.168.1.1             ; example.com's ip address is   192.168.1.1 ns1             A       192.168.1.2             ; ns1.example.com's ip address is  192.168.1.2 ns2             A       192.168.1.3             ; ns2.example.com's ip address is  192.168.1.3 mail            A       192.168.1.4             ; mail.example.com's ip address is  192.168.1.4
An A (Address) record defines the domain or subdomain's IP address. As you might have noticed already the @ stands for the zone file's domain (example.com in this case). Additionally, if you do not end your name with a period (.) then it will append the domain to it. For example, ns1 becomes ns1.example.com whereas ns1.example.com would become ns1.example.com.example.com.
www             CNAME   example.com.            ; www.example.com is the same as   example.com
A CNAME (Canonical Name) directly associates one name with another. Therefore www.example.com is the same as example.com .



/var/named/chroot/var/named/1.168.192.in-addr.arpa.zoneDownload This File

$TTL 86400 @               SOA     example.com. ( webmaster 2007112800 21600 1800 604800 900 )
Up until this point it is the same as our other zone file just with less whitespace and commenting.
You are required to enter at least one nameserver.
1       IN      PTR     example.com. 2       IN      PTR     ns1.example.com. 3       IN      PTR     ns2.example.com. 4       IN      PTR     mail.example.com.
We use PTR (pointer) records to define the domain names for each of our known ip addresses on 192.168.1.*. For example, 192.168.1.4 will now resolve as mail.example.com



Let's start the server and then make sure it comes up after a reboot.

# service named start
# chkconfig named on

If you got an error while starting named go back and make sure you have a semi-colon in all the right spots in your named.conf



Now let's test our nameserver to make sure it is working correctly.

# dig @localhost +short A example.com
192.168.1.1


# dig @localhost +short MX example.com
10 mail.example.com.


# dig @localhost +short NS example.com
ns2.example.com.
ns1.example.com.


# dig @localhost +short mail.example.com
192.168.1.4


# dig @localhost +short ns1.example.com
192.168.1.2


# dig @localhost +short ns2.example.com
192.168.1.3


# dig @localhost +short -x 192.168.1.1
example.com.


# dig @localhost +short -x 192.168.1.2
ns1.example.com.


# dig @localhost +short -x 192.168.1.3
ns2.example.com.


# dig @localhost +short -x 192.168.1.4
mail.example.com.


Configuring the Slave Nameserver

Configuring the slave nameserver is fairly simple once you have your master nameserver set up correctly.


/var/named/chroot/etc/named.confDownload This File

options{         directory       "/var/named/"; };   zone "example.com" IN {         type    slave;         masters { 192.168.1.2; };         file    "slaves/example.com.zone"; };
As you can see all we did was set up our example.com zone as type slave and pointed to the master server and where we want to store the zone files (we don't manually create them).



Now start the service and make sure it comes up on a reboot.

# service named start
# chkconfig named on



Soon you will see the zone file(s) created in /var/named/chroot/var/named/slaves/.
If they do not you can check your /var/log/messages file for errors.

No comments: