Using BIND to set up a DNS Server compatible with Active Directory

This is one of the simplest set ups you can make on a Linux machine and is usually at the heart of any client-server IP network. This set up will allow you to use this DNS server with Windows Active Directory so you won't need to host DNS on your windows server machine. I will also go onto configure this DNS server to failover to another BIND DNS server.

This has been installed and configured on Centos 6.5 but set up should be similar on other Linux distributions. Make sure that you configure your firewall to allow DNS requests through, this can be done through system-config-firewall

1. Install the BIND packages
   yum install bind bind-utils
2. Edit the /etc/named.conf to look as below// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//


options {
directory "/var/named";
};


acl "windowsadservers" {
192.168.100.3/24;
192.168.100.5/24;
};


zone "." IN {
type hint;
file "named.ca";
};


zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};


zone "network.local" IN {
type master;
file "slaves/network.fwd";
allow-update { "windowsadservers"; };
};


zone "100.168.192,in-addr.arpa" IN {
type master;
file "slaves/network.rev";
allow-update { "windowsadservers"; };
};


include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
The section highlighted in yellow is the context for any files mentioned here, unless explicitly specified otherwise. The section highlighted in blue is the access control list for machines that can update the DNS server. This should only be set if you plan to have something dynamically updating DNS such as AD The section highlighted in green is the FQDN of your network and authoritative zone that your DNS server is responsible for (You may also notice that the ACL list is mentioned here, this specifies what zones the server(s) can update) The section highlighted in red is the network address for your network, typed backward, eg 192.168.100.0 would be 100.168.192 (note the last octet is omitted)
3. Create the /var/named.local file to look exactly as below
   
   $TTL 86400
   @ IN SOA localhost. root.localhost. (
   1997022700
   28800
   14400
   3600000
   86400
   )
   
   
   IN NS localhost.
   1 IN PTR localhost. *NOTE* Do not forget trailing dots (highlighted in yellow) as this is a very common cause for errors. This appear in ALL zone files
4. Create the /var/named/slaves/network.fwd file to look as below. If you are not wanting any dynamic updates to your zone files put them in /var/named as this will mean that all updates will be blocked by SELinux
   

   $TTL 86400

   
   
   

   @ IN SOA linux1.network. root.linux1.network. (

   2008101401

   28800

   14400

   3600000

   86400

   )

   
   
   

   IN NS linux1.network.

   
   
   

   localhost IN A 127.0.0.1

   linux1 IN A 192.168.100.2

   linux2 IN A 192.168.100.3

   The sections highlighted in yellow need to be set as the FQDN of the hosting DNS server. Root is the user "mail" address for messages to be passed onto. DO NOT FORGET THE TRAILING DOTS! The sections highlighted in blue are your zone entries, put as many entries in here as you wish as these will be resolved by the DNS server. In this case if you perform "nslookup linux2" from linux1 it will resolve it to 192.168.100.3
5. Create the /var/named/slaves/network.rev file to look as below.
   
   $TTL 86400
   
   
   @ IN SOA linux1.network. root.linux1.network. (
   2008101401
   28800
   14400
   3600000
   86400
   )
   
   
   IN NS linux1.network.
   3 IN PTR linux2.network. The sections highlighted in yellow need to be set as the FQDN of the hosting DNS server. Root is the user "mail" address for messages to be passed onto. DO NOT FORGET THE TRAILING DOTS! The sections highlighted in blue are your reverse lookup zone entries, these should match your forward look up zone file. The number at the start of the entry is the last octet of the IP address for the machine you adding, for example the bottom entry will mean that linux2.network. is mapped to 192.168.100.3 as we specified the first 3 octets of the network address in the named.conf file.
6. Edit your resolv.conf file to reflect the change of DNS servers to use, or use system-config-network or the network manager (but hey we're on Linux, use the command line wherever possible) Resolv.conf nameserver 192.168.100.2 nameserver 8.8.8.8 The above tells the server to resolve DNS queries first by asking itself then asking 8.8.8.8
7. Restart the named and network services and set BIND to start on system startup service network restart service named restart chkconfig named on
8. Check your configurations by pinging a local machine on your network and then a website. This should resolve the DNS name into an IP address
   
   

We are now going to configure DNS replication and failover so that you can have a power failure or maintenance period on your main DNS server and there should be no interruptions to your DNS service. This process is very simple and could save a lot of trouble.

1. Install the required packages on the DNS slave server
   yum install bind bind-utils
2. Edit the /etc/named.conf file on the slave DNS server to read as below
   
   
   //
   // named.conf for Red Hat caching-nameserver
   //
   options {
   directory "/var/named";
   query-source port 53;
   transfer-source 192.168.100.3;
   };
   
   
   acl "windowsadservers" {
          192.168.100.3/24;
          192.168.100.5/24;
   };
   
   
   zone "0.0.127.in-addr.arpa" IN {
          type slave;
          file "slaves/named.local";
          allow-transfer { 192.168.100.2; };
          masters { 192.168.100.2; };
          allow-update { none; };
   };
   
   
   zone "network.local" IN {
          type slave;
          file "slaves/network.fwd";
          allow-update { "windowsadservers"; };
          allow-transfer { 192.168.100.2; };
          masters { 192.168.100.2; };
   };
   
   
   zone "100.168.192,in-addr.arpa" IN {
          type slave;
          file "slaves/network.rev";
          allow-update { "windowsadservers"; };
          allow-transfer { 192.168.100.2; };
          masters { 192.168.100.2; };
   };
   
   
   
   include "/etc/named.rfc1912.zones";
   include "/etc/named.root.key";
   The section highlighted in yellow is the IP address of this slave server
   Make sure the port specified in blue is opened on any firewalls between this and the main DNS server The IP addresses in green should be the same as the main DNS server. This allows the transfer of any DNS entries received or added while the master is offline. We specify the master of the zone to be the IP addresses in green.
   
3. Edit the /etc/named.conf file on the main DNS server
   
   //
   // named.conf
   //
   // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
   // server as a caching only nameserver (as a localhost DNS resolver only).
   //
   // See /usr/share/doc/bind*/sample/ for example named configuration files.
   //
   
   
   options {
   directory "/var/named";
          allow-transfer { 192.168.100.3; 192.168.100.1; };
   };
   
   
   acl "windowsadservers" {
          192.168.100.3/24;
          192.168.100.5/24;
   };
   
   
   zone "." IN {
   type hint;
          file "named.ca";
   };
   
   
   zone "0.0.127.in-addr.arpa" IN {
          type master;
          file "slaves/named.local";
          allow-update { none; };
   };
   
   
   zone "network.local" IN {
          type master;
          file "slaves/network.fwd";
          allow-update { "windowsadservers"; };
   };
   
   
   zone "100.168.192,in-addr.arpa" IN {
          type master;
          file "slaves/network.rev";
          allow-update { "windowsadservers"; };
   }; The IP address in yellow should be the IP of your slave server. The other IP address is the IP of the virtual network card that all traffic passes through in my home lab, this is a work around I found when I was having permission denied errors when trying to get the 2 servers to talk to each other. I am using virt-manager and KVM to run this network, I am not sure what the outcome on other virtulisation platforms is like (please comment if you find other obscurities with other OSs or hypervisors/virtual machine manager Note the named.local file has moved location so that it can be replicated as well.
4. Create the files on the slave server for the entries to be saved in, the ones specified in the /etc/named.conf
   
   touch /var/named/slaves/network.local
   touch /var/named/slaves/named.fwd
   touch /var/named/slaves/named.rev
5. Restart the BIND service and add it to startup on the slave server
6. Add this new server to your resolv.conf or other network config method

And that is simply it. You are now a master of DNS on linux based operating systems and can get paid to set them up

As any normal, questions, comments etc post in comment, tweet them or put it on the Facebook page

Set Up Routing On A linux Machine

Routing on a Linux machine can be useful if you are running a home lab scenario. This will allow internet access to your virtual machines that may be on a different subnet to your main network connection.

This configuration has been tested in a home environment with a home router provided by Virgin Media

The Linux host I am using is CentOS 6.5

1. Install the routing packages
   yum install quagga
2. Edit the configuration file /etc/quagga/zebra.conf to look like as below
   
   hostname vhost
   password vhost
   enable password vhost
   
   
   interface lo
   multicast
   
   
   interface eth0
   multicast
   
   
   interface virbr0
   multicast
   
   
   interface virbr0-nic
   multicast log file /var/log/quagga/zebra.conf The interfaces highlighted in yellow are my virtual interfaces created by my virtualisation software, in this case it is virt-manager. These are the interfaces that bridge network connectivity between your virtual switch and your physical lab network
3. Edit the configuration file /etc/quagga/ospfd.conf to look like as below
   
   
   hostname vhost
   password vhost
   enable password vhost
   
   
   
   router ospf
   router-id 192.168.0.25
   network 192.168.0.25/24 area 0
   network 192.168. 0100./24 area 0
   
   log file /var/log/quagga/ospfd.log
   
   The IP address in yellow needs to be changed to the IP of your host's network card that is connected to the physical network
   
   The network addresses in blue need to be set to the networks you want to route together. Note, these MUST be network addresses otherwise routing will not work
4. Create the 2 log files and allow for write access to them
   
   sudo touch /var/log/quagga/zebra.conf sudo touch /var/log/quagga/ospfd.conf sudo chmod 777 /var/log/quagga/zebra.conf sudo chmod 777 /var/log/quagga/ospfd.conf 
   Note, the use of 777 should only be used in a testing environment, in a real live environment you may want to filter permissions a bit more as this allows all uses and processes to read, write and execute these files which can lead to a security hole.
5. Edit the line in /etc/sysctl.conf to read net.ipv4.ip_forward = 1
6. Edit the Linux firewall to be trusted on all ports and to allow masquerading on all ports. Add any ports created by the virtualisation host. Use system-config-firewall for this. This can be done from a GUI session or a pure command line session
7. Restart the Zebra, OSPFD and network services service zebra restart service ospfd restart service network restart
8. Make the services start on start-up using chkconfig chkconfig zebra on chkconfig ospfd on
9. Test the configuration by trying to ping an IP such as 8.8.8.8

I hope this article has been helpful for you and expect some more very soon. If there are any questions or queries comment on this post, ask on the Facebook page www.facebook.com/winuxsupport or tweet @winuxsupport All feedback is welcome to improve this blog for everyone