Setting Up Your Own DNS Server

Today I went through the process of setting up my own DNS server. As I’m hosting websites behind DSL I was getting sick of switching /etc/hosts files every time I was within my own network (only Cable prevents the need for this) and originally intended to set up an internal-only DNS server which would fall back to OpenDNS for any records it didn’t know … this would solve the issue.

There are also a few bragging rights in being able to say you host your own DNS server.

Rather than retracing my steps and placing them all here, follow this tutorial for the internal server. However this tutorial omits an important detail: make sure you also add an ‘@’ A record which points to your IP address, or it won’t resolve.

Once I had this all up and running and I had finally got my head around the way BIND9′s config files worked, I decided to take the next step: opening up the server for external use. I followed this tutorial to modify my existing configuration to allow external requests. And here’s the second note: make sure you move the ‘include “/etc/bind/named.conf.default-zones”‘ directive from ‘/etc/bind/named.conf’ into the end of your ‘internal’ view in ‘/etc/bind/named.conf.local’. Why? Because if you’re using views you can’t define a zone outside of a view, and that’s just what ‘named.conf.default-zones’ will do if it’s included from the main file.

Finally, in the above tutorial it talks about including your external zone file in the internal one to prevent modifying so many files every time you update your DNS records, however that means you’re overloading the records which just doesn’t feel right to me. I’ve taken it one step further to make it nice, simple and clean. My folder structure looks like this:

The philosophy here is to put all of the DNS record declarations in the base files except for anything unique to the view. Therefore, ‘base/example.com.db’ would look similar to this:

Here we have a very generic definition. Nothing is unique to being internal or external (don’t worry about line 10, this still resolves internally).

Next, the ‘internal/example.com.db’ file:

Now this is beautiful in its simplicity. We are importing the base definition and then adding on the A records pointing to the web server’s IP so that when you’re within the network you can resolve correctly.

Finally, the ‘external/example.com.db’ file:

Again, extremely simple. Identical in fact, apart from the extra nameserver declarations which aren’t necessary internally. Externally you need a fallback and Xname is as good as any (as referenced in the above tutorial).

So how do you use all of these files? Very simply. All you do is include the ‘file “/etc/bind/zones/internal/example.com.db”‘ declaration (with the obvious modification for the external view) within ‘/etc/bind/named.conf.local’, and those simple files will import the base declaration for you. If you ever need to open up a new subdomain or change an MX record, all you need to do is edit the base declaration (remembering to update the serial number at the top) and the changes will take effect both internally and externally.

See what I mean by Beauty in Simplicity?

Ubuntu + Apache2 + SNI [WORKING]

As you may know, Ubuntu still doesn’t support the Holy Grail of SSL: Server Name Indication – which enables you to run multiple certificates behind the one IP using Virtual hosts – out of the box. It was promised to be included in Karmic Koala but never quite got there. And since you can’t run Lucid Lynx on a production server yet, what are you to do?

Well, you have to compile it yourself. However the tutorials on the net are all about old versions of Apache and patches and such, so I did the research and found the current method of compiling. Enjoy.

1. You need a couple of packages installed before you do any compiling. I will leave the basics of setting up your programming environment (gcc, make, etc) to you, but specifically for this project you need to run:
$ sudo apt-get install zlib1g-dev libssl-dev

1	$ sudo apt-get install zlib1g-dev libssl-dev

2. Download the latest stable versions of OpenSSL and Apache2 from their websites. As of writing they were v1.0.0 for OpenSSL and v2.2.15 for Apache2 … much newer than the versions available in the Karmic repository.
3. Extract both into a working directory inside your home directory.
4. cd into the OpenSSL directory and compile it:
$ ./config --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-mdc2  no-rc5        zlib enable-tlsext no-sslv2 $ make depend $ make $ sudo make install

1 2 3 4 5

$ ./config --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-mdc2  no-rc5        zlib enable-tlsext no-sslv2 $ make depend $ make $ sudo make install

5. cd into your apache directory and configure it:
$ ./configure --enable-layout=Debian -enable-ssl=shared        --enable-mods-shared=all --enable-deflate        --with-ssl=/usr/lib/ssl --with-program-name=apache2 $ make $ sudo make install

1 2 3 4 5

$ ./configure --enable-layout=Debian -enable-ssl=shared        --enable-mods-shared=all --enable-deflate        --with-ssl=/usr/lib/ssl --with-program-name=apache2 $ make $ sudo make install

6. Restart your Apache Server if you haven’t already:
$ sudo /etc/init.d/apache2 restart

1	$ sudo /etc/init.d/apache2 restart

7. Done!

Credit for this is due to a chap called Zeepal who wrote the original set of instructions for Apache2 v2.2.11 (this method required a patch). I found that with the newer versions the patch was no longer needed, but a few extra options listed in the Apache SNI manual were. Here we have a working version.

Did it work for you? I’m interested to hear your feedback!

11/04/2010: I’ve just found that Ubuntu may overwite your compiled version of Apache in it’s next update, so follow the instructions here to make sure it leaves it well alone. Follow the procedure twice, once replacing ‘packageName’ with ‘apache2*’, and secondly with ‘openssl*’. Just remember once the Ubuntu versions catch up with the versions you’ve compiled to do the same but change the option back to ‘install’.