Authoritative DNS
As much as I love exploring and learning the newer protocols and technologies like SIP, and Enterprise Virtualization, there is something to be said for those standards and protocols that the internet is built from on and designed around. It is quite refreshing to work with a protocol that is not under constant revision and modification, since the software that runs it is rock solid, stable, and just runs until you tell it not to.
If you haven’t caught on, or are new to my site, I prefer running everything I can on ubuntu server edition. I’ve found it to be stable, fast, reliable, lightweight, and still powerful enough to handle anything from large database back-end systems, to lightweight web hosting systems, and even to, you guessed it, authoritative DNS servers. I won’t suggest an ubuntu server version here, since it is nearly the same procedure on every version I have used (I’ve been using ubuntu server since 2006.)
First, you need a server to run it on. If you have a virtual infrastructure already handy, DNS is ideal as a virtualized system because it uses very, very little system resources, unless you are hosting DNS for some EXTREMELY busy domains. If you don’t have a virtual infrastructure, or any handy hardware, you can comfortably share your DNS services on your web or email server. Just bear in mind that this server will have to be publicly available, so choose a machine that is safe for that purpose.
After several difficult and dissapointing conversations with first level technical support from various ISPs, I decided a few years ago that I would manage my own authoritative DNS solutions. I was pretty much fed up when the last ISP I had hosting my DNS told me that there was no such thing as a TXT Record.
So once you have a server ready to host your DNS, you’ll want to install BIND:
<br /> sudo apt-get install bind9<br />
Once bind is installed, you can immediatly begin to configure it. My standard procedure is to create the directory where I store all of my “zone files”.
<br /> sudo mkdir /etc/bind/zones<br />
A zone file is a file which describes your domain, it’s hosts, and how other users of the internet should use the information you provide. Next we edit the file /etc/bind/named.conf.options. In here, you can specify some of the many, many options of bind. I typically will set up ‘allow-recursion’, and ‘version’ directives here. If you are setting up an internal DNS server, or would like bind to do recursive queries for your internal clients, then you would want to include your internal address range:
<br /> allow-recursion { 192.168.0.0/16 };<br />
If this server will be relying on itself for DNS lookups, then you’ll want to make sure that the localhost can recurse as well:
<br /> allow-recursion { localhost; 192.168.0.0/16; };<br />
There are some other tricks you can find at:
http://www.zytrax.com/books/dns/ch7/queries.html
http://www.zytrax.com/books/dns/ch7/address_match_list.html
Just be careful and put some thought into who you will, and will not allow to do recursive queries.
The version directive is recommended by http://www.cyberciti.biz/faq/hide-bind9-dns-sever-version/ to be set to something generic like “BIND”:
<br /> version "BIND";<br />
Otherwise it is possible for an attacker to obtain your version number, and exploit some yet undiscovered vulnerabilities in your version. Some of the newer versions of BIND instituted a new set of logging directives which I typically set, otherwise your syslog will be littered with tons of error messages from servers in the world that don’t follow the DNS RFC standards properly:
<br /> logging {<br /> category lame-servers { null; };<br /> category edns-disabled { null; };<br />};<br />
Next we have to modify the file /etc/bind/named.conf.local, which holds all of our yet to be configured “zones”. Zones are usually domains, but can be sub-domains, or even in-addr.arpa domains for doing reverse DNS. Once inside the file, add a zone like so:
<br /> zone "myexampledomain.com" {<br /> type master;<br /> file "/etc/bind/zones/db.myexampledomain.com";<br />};<br />
This tells BIND that it is authoritative for the domain “myexampledomain.com”, and that the zone file can be found at “/etc/bind/zones/db.myexampledomain.com”. The zone file name and location is my personal preference, you can store it wherever, and name it whatever you’d like. Once you configure a zone file, you can restart the service (/etc/init.d/bind9 restart) and begin testing your newly created DNS server. I won’t go into detail about zone files, but a simple google search for “bind zone file” will get you going. Here is an example zone file:
<br /> $TTL 86400<br />myexampledomain.com. IN SOA ns1.myexampledomain.com. hostmaster.myexampledomain.com. (<br /> 2007100301 ; Serial<br /> 3600 ; Refresh 3 hours<br /> 3600 ; Retry 1 hour<br /> 604800 ; Expire 1 week<br /> 86400 ); Negative TTL: Minimum 5 minutes</p> <p>@ IN NS ns1.myexampledomain.com.<br />@ IN NS ns2.myexampledomain.com.<br />@ IN A 192.168.0.1 ;web site ip<br />ns1 IN A 192.168.0.2 ;bind server ip<br />www IN CNAME myexampledomain.com.<br />
With the zone file in place, restart your BIND server and we can begin testing. Type nslookup and hit enter. Here you can issue dns queries against your default server or specify a server:
<br /> server localhost<br />
Now query for your domain and you should get the following response:
<br /> > myexampledomain.com<br />Server: localhost<br />Address: 127.0.0.1#53</p> <p>Name: myexampledomain.com<br />Address: 192.168.0.1<br />
If you see something like this, then your configuration is successful. If not, check your logs, and your configuration files, and try again.