Setting up a local domain

In order for us to host our own local domain, we will be required to create a forward zone file as well as update or create a reverse zone file.

Forward zone file

The forward zone file contains the mappings of host names to IP addresses. Below is an example of a forward zone file.

;
; BIND forward data file for mydomain.local zone
;
$TTL    86400
@	IN	SOA	ns.mydomain.local.	non-existant.mydomain.local. (
				         1	; Serial
				    604800	; Refresh
				     86400	; Retry
				   2419200	; Expire
				     86400 )	; Negative Cache TTL
	IN	NS	ns
	IN	MX 10	mail
;
@		IN	A	192.168.100.10
gw		IN	A	192.168.100.1
myhost		IN	A	192.168.100.10
ns		IN	CNAME	myhost
mail		IN	CNAME	myhost

For the definition above, the value for Serial contains the value of the current definition – when updating the zone file, this value should be updated to ensure that it refreshes across all DNS servers and the correct definition is loaded. The values for Refresh, Retry, Expire and Negative Cache TTL are all values in seconds that specifies the time to perform the operations.

The line IN NS defines the hostname of the DNS server.

The line IN MX defines the hostname of the mail server.

The line @ IN A 192.168.100.10 defines the IP address that would be returned when performing a DNS lookup on the mydomain.local domain.

The line myhost IN A 192.168.100.10 defines the IP address that would be returned when performing a DNS lookup on the myhost.mydomain.local host name. All IN A records define the mappings between the host name and their respective IP addresses.

The line ns IN CNAME myhost defines that the hostname ns is a virtual name for myhost. All IN CNAME records define the mappings between the virtual names and their respective host names.

Reverse zone file

The reverse zone file contains the mappings of IP addresses to host names.

;
; BIND reverse data file for 192.168.100 zone
;
$TTL    86400
@	IN	SOA	localhost.	root.localhost. (
			         1	; Serial
			    604800	; Refresh
			     86400	; Retry
			   2419200	; Expire
			     86400 )	; Negative Cache TTL
	IN	NS	ns.mydomain.local.
;
1	IN	PTR	gw.mydomain.local.
10      IN      PTR     myhost.mydomain.local.

For the definition above, the value for Serial contains the value of the current definition – when updating the zone file, this value should be updated to ensure that it refreshes across all DNS servers and the correct definition is loaded. The values for Refresh, Retry, Expire and Negative Cache TTL are all values in seconds that specifies the time to perform the operations.

The line IN NS defines the hostname of the DNS server.

The line IN PTR defines the mapping between the IP address and the fully qualified host name.

Adding the zone definition

Once the zone files have been created and/or updated, the /etc/bind/zones.local file should be updated to include references to the zone files, as shown below.

zone "100.168.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.168.100"; };
zone "mydomain.local" { type master; file "/etc/bind/zones/db.mydomain.local"; };

Installing Bind on Debian 7.5

I normally setup a DNS server for hosting domains on my internal network making use of Bind 9.x. Do note that exploits do come out from time to time and that your DNS server should be setup properly to avoid anything from denial of service attacks to root compromises.

Once our server is configured, we can host any number of domains – the creation of the domains are covered in my next article.

Installing Bind

We install the Bind software by executing the following command in a “root” shell.

apt-get install bind9 bind9-doc

Once the installation is complete, we can customize the configuration by editing the files in the  /etc/bind directory.

Configuring Bind

The options are defined in the /etc/bind/named.conf.options file.

Queries

We are able to limit the hosts that are allowed to query the DNS server by defining an ACL and then setting the options for allow-query, allow-query-cache and allow-recursion to use the defined ACL.

acl allowquery {
	192.168.100.0/24;
};

options {
	/*
	 * Allow queries from our "allowquery" ACL.
	 */
	allow-query {
		allowquery;
	};

	/*
	 * Allow queries to the cache from our "allowquery" ACL.
	 */
	allow-query-cache {
		allowquery;
	};

	/*
	 * Allow recursive queries from our "allowquery" ACL.
	 */
	allow-recursion {
		allowquery;
	};
}

In the example above, we allow only the 192.168.100.0 network to query our DNS server.

Forwarders

DNS forwarders are DNS servers used to forward DNS queries to for DNS names outside of our network. To define DNS forwarders, we set these as shown below.

options {
	forwarders {
		192.168.0.10;
	};
};

In the example above, DNS queries would be forwarded to 192.168.0.10 for names not defined in our DNS server.

Listening

To limit the IP addresses that Bind would be listening on for DNS requests, we define the listen-on option as shown below.

options {
	listen-on {
		127.0.0.1;
		192.168.100.10;
	};
	listen-on-v6 { none; };
};

In the above example, Bind would be listening on the IPv4 addresses of 127.0.0.1 (or better known as localhost) and 192.168.100.10, which is defined as the primary IP address of our server. We also disabled the option to listen on IPv6, since we’re not using IPv6 on our network.

Once completed with the necessary options, remember to set the IP address of your DNS server in your /etc/resolv.conf file.

Local domains

We also create a container for our zones by executing the following command in a “root” shell.

mkdir -p /etc/bind/zones

Next, we create a definition file for our local zones by executing the following command in a “root” shell.

touch /etc/bind/zones.local

Finally, we edit the /etc/bind/named.conf.local file to contain the list of the zone definition files, as shown below.

include "/etc/bind/zones.rfc1918";
include "/etc/bind/zones.local";

Setting up your own development server in Debian

In this series of articles, we will be setting up a new development environment under Debian 7.5. This will include a base server operating system, GUI Desktop Environment, Network Time Server, DNS server, Mail server, Database server and Web server. We will also be hosting our own Version Control System with integration into a Project Management and Issue and Time Tracking solution. We will also require our own Certificate Authority to request and sign digital certificates to use on our internal network and web server.

Operating System and Desktop Environment

As stated above, we will be making use of Debian 7.5 for our server operating system and either log in remotely to a shell over SSH or directly via a Desktop Environment.

Our Desktop Environment will be LXDE, due to the fact that it is designed to work well with computers on the lower end of the performance spectrum – in my case, I am running my Debian server on a Pentium IV 1.7GHz with 512MB of RAM and 2 drives of 40GB and 160GB each – the latter being used as my data drive and the former to host the operating system. We’ll also be installing Gnome and KDE as well, which are both very common Desktop Environments.

Network Time

For us to be able to broadcast Coordinated Universal Time on our internal network, we will be using NTP.

DNS Server

For us to be able to host domains on our internal network, we will be using Bind.

Mail Server

For us to be able to send and receive email messages on our internal network, we will be using Exim 4 with ClamAV, SpamAssassin and Greylistd enabled.

Data storage

For us to be able to provide data storage for our applications, we will be making use of

  • Relational databases;
  • In-memory object caching; and
  • NoSQL databases.

Relational database

MySQL Server 5.5 will provide our relational database back-end and we will be administering it through a web front-end making use of phpMyAdmin.

Object-caching

Memcached will provide our object-caching back-end and we will be administering it through a web front-end making use of phpMemcachedAdmin.

NoSQL database

MongoDB will provide our NoSQL database back-end and we will be administering it through a web front-end making use of RockMongo.

Web Server

The web front-ends will be hosted on Apache 2.2, with virtual hosts configured for each specific web front-end and SSL certificates securing the communication between the web front-ends and clients.

Java Application Server

Tomcat will provide our Java Application Server functionality.

Zend Framework

Zend Framework 2 is an open source framework for developing web applications and services using PHP 5.3+. Apigility provides the functionality to implement a WebAPI on top of the Zend Framework.

Version Control System

For us to provide our own version control system, we will be using Subversion and Mercurial and also enable access to it over the HTTPS protocol.

Project Management and Issue and Time Tracking

For us to provide our project management solution, we will be using Redmine and configure access to both Subversion and Mercurial as well as enable access to it over the HTTPS protocol.


The articles will be published in the order below and as these become available, I will update the list with the appropriate links.

At the end of this series, we will have a comprehensive development server for internal use. A note on this, we are setting up the server behind an existing firewall making use of the 192.168.100.x range of IP addresses.