Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
org
Welcome to dbjdnsrocks.org, a guide & tutorial for the installation for djbdns. The purpose of this site is to provide a
publicly available installation guide for Dan Bernstein's djbdns DNS software package. This site is not an official
djbdns resource and is not affiliated with with Dan Bernstein or any other organization associated with djbdns. This
installation guide has been tested on all Redhat Linux releases above 7.0, Redhat Enterprise Linux 3, Fedora Core 1
& 2 as well as FreeBSD 4.x and 5.x. However, the installation should be portable to any other Linux/Unix flavors with
minimal fuss. It is my hope that this site will be a useful resource to anyone who is new to djbdns and in need of an
easy-to-follow, step-by-step installation documentary .Please read the disclaimer before proceeding with the djbdns
installation.
Want to know what other people have has to say about this site? Click here.
This site has been viewed 14462 times since its creation.
About djbdnsrocks.org
After creating Qmailrocks.org, my site which documents the installation Qmail, I decided to start playing around with
Dan Bernstein's djbdns DNS server application. Like Qmail, I found djbdns to be simple, yet elegant, and rock solid
in terms of it's reliability and security. It runs our of daemontools, so you know it will never die unless someone
unplugs the damn server. After getting my djbdns wings and spending enough time "command line side" to know
what I was doing, I then looked for a nice web interface that would make the day to day DNS management tasks a
breeze. There are not a whole lot of these out there. Of the few that I did find, I've found Vegadns to be my favorite.
So, after getting everything up and running, I decided to once again publish my work on the Internet so that others
can use it as a resource when they embark on their own djbdns adventures. Have fun, and good luck!
Getting started
Preliminary actions
First, create a directory where the djbdns related software will be downloaded to. To make it easier on yourself,
follow the directory structure that I recommend below:
mkdir /downloads
cd /downloads
Now you must download the djbdnsrocks.org software bundle. You can download it right here, or download it directly
to your system like so:
wget http://www.djbdnsrocks.org/downloads/djbdnsrocks.tar.gz
Before you start installing djbdns, is make sure that your server meets the necessary requirements needed for
djbdns to operate correctly.
Required Items
3. Daemontools - If you've already installed my version of Qmail, you should already have this installed. If not, click
here to install it.
4. UCSPI-TCP - Again, if you've already installed my version of Qmail, you should already have this installed. If not,
click here to install it.
That's all. Once you've got these 3 items covered, you can proceed to the actual installation.
Proceed to Step 1
djbdns Extras
Here you will find helpful tools and utilities that make running your new djbdns server a snap...
The djbdns tools - These useful little built-in command line utilities always come in handy. They already come with
djbdns by default.
more to come...
djbdnsrocks.org FAQ
Check here to find answers to some of the most common questions I receive about this site and djbdns in general.
A: If you're asking this question, you probably should hold off on setting up your own DNS server until you've got a
better understanding of how the whole thing works. That said, I have found a couple resources on the web that do a
good job of explaining how DNS works.
1. http://www.howstuffworks.com/dns.htm - This is very elemenary, but a good start if you're really clueless.
Back to top
A: While I certainly have not tested this installation on every single Unix/Linux distribution out there, I'm failrly certain
that it's portable to just about any Unix/Linux OS. I have successully tested the installation on Redhat, FreeBSD,
Debian, Suse, Slackware and BSDi. Djbdns is more or less platform independent. It should work on just about any
Unix or Linux distro with relatively few problems or modifications.
Back to top
svc -t /service/dnscache
Back to top
Q: I have setup tinydns according to this site and I now have a DNS server called "ns1.mydomain.com". However, I
need to have an "ns2.mydomain.com" as well. How do I do this?
A: Firstly, you need to know the logic behind having an "ns2.mydomain" server in addition to the
"ns1.mydomain.com" server. The answer is simple: Redundancy. The "ns2" server functions as a backup server if
the "ns1" server should be slow to respond or out of service. The same logic applies to why you would have an
"ns3", "ns4" and so on. The more redundancy you have the better. However, 2 DNS servers is usually the bare
minimum you would want to have in order to reliably serve DNS information. As you can probably guess, you would
probably want to the secondary DNS server to be on a different physical server than the primary. It doesn't do much
good to have multiple DNS servers running on the same server because if that server goes down, the primary and all
the backups are down and you're screwed. However, since you are often required to register 2 nameservers in order
to have a registered DNS server and since a lot of people don't have a second server to put the redundant DNS
server on, it is possible to run 2 or more instances of Tinydns on the same machine. To make this happen, all you
need to do is go through the installation on Tinydns again but this time you will want to install it as "tinydns2" and
assign it to a different IP address. In other words, you would have a new directory called "/etc/tinydns2" and this
would fucntion as the location for the secondary server zone files. You would then hook that "tinydns2" into the
daemontools service monitor by creating softlinks to it.
Back to top
Q: What is the purspose of having more than 1 DNS server? For example: ns1.mydomain.com, ns2., ns3., ns4. and
so on. Do I need these?
A: Firstly, you need to know the logic behind having an "ns2.mydomain" server in addition to the
"ns1.mydomain.com" server. The answer is simple: Redundancy. The "ns2" server functions as a backup server if
the "ns1" server should be slow to respond or out of service. The same logic applies to why you would have an
"ns3", "ns4" and so on. The more redundancy you have the better. However, 2 DNS servers is usually the bare
minimum you would want to have in order to reliably serve DNS information.
Back to top
Q: Does the djbdnsrocks installation of djbdns contain any changes to the inner workings of djbdns that I should
know about?
A: No. I didnt' tamper with the inner workings of djbdns at all. The version of djbdns that is used on this site is exactly
the same version that Dan Bernstein makes available on his site. Some of the directory names that are created for
dnscache and tinydns may differ slightly from those of other installation guides, but that is 100% inconsequential.
You can name the dnscache and tinydns directories whatever you want, so long as they are referenced in the
corresponding /service links.
Back to top
Q: When I try to login to Vegadns I get this error: Error: /var/www/vegadns/sessions is not writabale. What's up?
A: This is caused by incorrect permissions or ownership settings on the private Vegadns directory. This can be fixed
by setting the correct permissions and ownership. In the commands below, substitute in the correct patch to the
vegadns_private directory and also change the "apache" user to whatever user your Apache server is runnig as.
Back to top
I've replaced Sql2tinydns with Vegadns in the djbdnsrocks.org intallation guide. I like Vegadns alot better than
Sql2tinydns and it's much easier to install as well.
A .pdf version of this site is now available. The link can be found on the main page of this site.
11/18/2003 - improvements
I released a complete package (djbdnsrocks.tar.gz) that contains all needed software and patches.
In my constant efforts to improve the installation guide, I ran through my installation on a new Redhat 9 server and
took a few notes along the way. I've updated the installation guide with a few typo corrections here and there as well
as some more in depth explanations of certain aspects of the installation. Enjoy.
DNS Links
Dan Bernstein's djbdns site - http://cr.yp.to/djbdns.html
Qmailrocks.org - My installation guide for Qmail. Qmail runs great when coupled with dnscache.
Contact djbdnsrocks.org
Got a question? Wanna drop me a line? Just fill out the form below and submit it. Alternatively, you can e-mail me
directly at the address shown at the bottom of every page of this site.
Name:
E-mail:
Comments/Questions:
Send E-mail
djbdns tools
Djbdns has a set of handy command line utilities that are ready to use once you install it. The following is a list of
some of those commands followed by a brief description.
dnsip fqdn
dnsipq
dnsmx fqdn
dnsname 1.2.3.4
dnsq
dnsqr
dnstrace
dnstracesort
dnstxt
Installing Daemontools
Installing daemontools is quite easy. Daemontools is a software pakage designed by Dan Bernstein which does the
job of making sure designated services are up and running at all times. Once it's installed, you will then hook djbdns
into it to ensure that the DNS server is always up and running.
2. mkdir -p /package
4 . cd /package.
To accomodate for the newer glibc package that comes with RH9, you will need to apply to
following patch before compiling djbdns:
cd /package/admin/daemontools/src
6. cd admin/daemontools-0.76
7. ./package/install
That's it. Daemontools is now installed! If you run a "ps -aux" (or whatever proc list command tickles your fancy) you
should see the "svscan" function now running!
Installing UCSPI-TCP
UCSPI-TCP is also quite easy to install. This little package will run the ever important tcpserver. Anyway, here's how
to install it.
2. cd /path/to/djbdnsrocks
Now install it
4. cd ucspi-tcp-0.88
To accomodate for the newer glibc package that comes with RH9, you will need to apply to
following patch before compiling djbdns:
5. make
Installing djbdns
Now we will install djbdns, the core of our dns server. Once djbdns is installed, we will then setup the 2 services we
wish to run: tinydns (the authoritative name server) and dnscache (the caching nameserver).
3. cd /path/to/djbdnsrocks
5. cd djbdns-1.05
To accomodate for the newer glibc package that comes with RH9, you will need to apply to
following patch before compiling djbdns:
4. make
You will see a bunch of stuff fly by on the screen. This is normal. ;)
./install
./instcheck
Wow, that was easy! A successful installation will install djbdns and all its tools into /usr/local/bin. Now let's setup
tinydns and dnscache.
proceed to Step 2
Setting up tinydns
Now we will setup the tinydns authoritative nameserver. The authoritative nameserver is going to contain zone files for
all domains which you wish to handle. Once the zone entry for a domain in entered into tinydns, you can then point that
domain, via your registrar, toward your nameserver and it will direct requests (web, mx, etc.) wherever you want them
to go!
/downloads/djbdnsrocks/scripts/add_users_rh.script
/downloads/djbdnsrocks/add_users_freebsd.script
No we will create the tinydns config folder. This is where all the zones and other configs will live. You will need to
choose an IP address that you want to use for your nameserver. In the example below, I have put "1.2.3.4" as the IP
address of my server. Don't be a dumbass and actually use 1.2.3.4. Substitute in the actual IP address of your soon-to-
be DNS server.
Wasn't that easy? We'll stop here for now. When we've finished the install and started everything up, I'll show you how
to create your first zone file. Next we'll set up our caching nameserver...
proceed to Step 3
setting up dnscache
In this next step we'll setup dnscache, the caching nameserver. A caching nameserver will provide authorized hosts
with a nameserver through which they can make DNS queries. A common example of the use of a caching
nameserver is in the /etc/resolv.conf file, which is used by a Unix/Linux server to conduct DNS queries for addresses
across the Internet so that services such as mail and web browsing will work.
In setting up our caching nameserver, we're actually going to set up 2 servers: 1 server to listen internally so that our
own server can have a nameserver to make queries against and 1 server to listen on an external IP address so that
external hosts can query against it. Why, you ask? The reason is pretty simple. Often times you may want your local
server to use different DNS information that any external sources. This is especially true if your setting this up in a
small office or home network. Setting up 2 caching nameservers allows you to have maximum control over what
servers receive what DNS information. The internal caching nameserver can be used to route internal network
requests to special internal IPs and destinations, while your external dnscache server can route normal public requests
to public IP addresses and so forth. Do you really need 2 caching namesevers? No, you don't. But it won't hurt. If you
only plan on the caching nameserver being used by the local machine and nobody else, you can just setup the internal
caching server. Likewise, if you don't plan on having any custom internal DNS rules, you can skip the internal server
and just do 1 external server that is used by both your local machine and the outside world. It's up to you but, since it
doesn't hurt, I say just go with both an internal and an external caching nameserver.
Again, for the purposes of this tutorial, I'm going to say that my external IP address is 1.2.3.4, but you will want to
substitute your own IP address instead.
Viola! That's it as far as the internal caching nameserver goes. It's not running yet, but we'll get to that on the next
page.
Important Note: You will want to use a different IP address for you caching nameserver than you used for your DNS
server on the previous page.
That's it! The external dnscache is now configured. However, by default, your external nameserver is not going to
allow any outside hosts to query against it. In order to allow other hosts to query against your nameserver, you have to
give them permission. This is done by creating a zero length file named for the IP address, or range of IP addresses,
that you wish to give query rights to. It's quite easy. Here's how you do it...
OK, we've already established that the IP address of my external nameserver is 1.2.3.4. Now let's say that I have
another server somewhere else and the IP address of that server is 10.20.30.40. I've set up my caching nameserver
and now I want the 10.20.30.40 server to be able to use my 1.2.3.4 nameserver to make it's DNS queries. In other
words, I want to edit the /etc/resolv.conf file on the 10.20.30.40 server and put an entry of "nameserver 1.2.3.4". Well,
that's all fine and dandy, but I have to tell the 1.2.3.4 to accept DNS queries from the 10.20.30.40 server. To do this, I
simple run the following command (as root) on the 1.2.3.4 server:
touch /etc/ext_dnscache/root/ip/10.20.30.40
And viola, that's it. Now the 10.20.30.40 server is allowed to make DNS queries against the 1.2.3.4 nameserver. You
can keep running the above command and add as many authorized hosts as you want. On the other hand, you may
want to allow an entire range of IP addresses. In that case you could do something like this:
touch /etc/ext_dnscache/root/ip/192.168.1
This command will allow any queries from all hosts from 192.168.1.*
So by now you should have tinydns, an internal and an external nameserver established. In the next step, we will start
up all 3 of these services. After that, we'll test the nameservers to make sure they work and we'll add some zone
entries into tinydns!
proceed to Step 4
To do this, all we do is make symlinks to the services in the /service directory. This will daemontools to work its magic
and keep these 2 new services up and running!
ln -s /etc/tinydns /service
ln -s /etc/int_dnscache /service
ln -s /etc/ext_dnscache /service
Now, if you wait a few seconds and then run a "ps -aux" on your box, you should see tinydns and both the internal and
external dnscache servers running! The "ps -aux" output for these 2 services should look similar like this:
root 29522 0.0 0.0 1352 276 ? S 00:11 0:00 supervise tinydns
tinydns 29523 0.0 0.0 1472 280 ? S 00:11 0:00 /usr/local/bin/tinydns
root 29527 0.0 0.0 1356 276 ? S 00:12 0:00 supervise int_dnscache
dnscache 29528 2.0 0.2 2656 1336 ? S 00:12 0:00 /usr/local/bin/dnscache
root 29529 0.0 0.0 1356 276 ? S 00:12 0:00 supervise ext_dnscache
dnscache 29530 2.0 0.2 2656 1336 ? S 00:12 0:00 /usr/local/bin/dnscache
If you've got similar output as above, way to go! You're DNS server and caching nameserver are alive! Now we'll
configure and test them!
proceed to Step 5
Configuring Tinydns
The only thing we need to do with tinydns is to create zone entries for the domains which will be running off of our DNS
server. If you've planned ahead, you should already have a domain pointed to the address of your nameserver. If
you've never registered a nameserver before and you're a bit confused, click here. In my case, I called my DNS server
"ns1.mydomain.com". I then went to my registrar and pointed my testing domain, "testdomain.com", to my
"ns1.mydomain.com" nameserver. With the domain now pointing to my server, all that's left to do is to create a zone
entry so that tinydns will know what to do with the requests for "testdomain.com". I'm going to show you how to
manually create the zone entries via the command line for now, but later on in this installation we will install a nice web
based DNS management tool that will let you add zones via your browser.
cd /etc/tinydns/root
The /etc/tinydns/root directory is going to be where all the zone file magic takes place. Zone entries all get stored in a
single file called "data". We make changes to the "data" file and when we are done, we tell tinydns to write these
changes to the "data.cdb" file which is the file that tinydns will actually read and work from.
Changes to the "data" file can be made either by editing the file directly with your favorite text editor or by running one
of several handy scripts which are included in this same directory.
If you were to view the "data" file on my server, you may see something like this:
+testdomain.com:12.56.89.30:86400
.testdomain.com:12.56.89.20:ns1.mydomain.com
@testdomain.com:12.56.89.30:mail.testdomain.com:10:86400
+www.testdomain.com:12.56.89.30:86400
+*.testdomain.com:12.56.89.30:86400
+otherdomain.com:12.56.89.40:86400
.otherdomain.com:12.56.89.20:ns1.mydomain.com
@otherdomain.com:12.56.89.40:mail.otherdomain.com:10:86400
+www.otherdomain.com:12.56.89.40:86400
+*.otherdomain.com:12.56.89.40:86400
As you can see, the entries for each domain can simply be stacked right on top of each other. Once the "data" file is
compiled, tinydns will parse that info up so that it knows what to do with every valid request. The syntax of these "data"
file entries is pretty easy to understand. Each line of a zone entry is preceded by a symbol and it is this symbol at the
start of each line that tells tinydns what this line is going to denote. Here's a quick overview of some of these symbols:
symbol meaning
"+" A plus sign denotes an A record
"." A period denotes the Name Server for the domain.
An ampersand also denotes a Name Server for the domain, but this is
"&"
usually used when delegating a child server. I usually don't use these
"@" An @ sign denotes an MX record.
An equal sign denotes a Host name. This can also be used to create a
"="
PTR (reverse) record.
So, given this information, let's break down the zone file for "testdomain.com" listed above. I've printed the zone file
again, but numbered each line. Below the zone, you will find explanations of each numbered line.
(1) +testdomain.com:12.56.89.30:86400
(2) .testdomain.com:12.56.89.20:ns1.mydomain.com
(3) @testdomain.com:12.56.89.30:mail.testdomain.com:10:86400
(4) +www.testdomain.com:12.56.89.30:86400
(5) +*.testdomain.com:12.56.89.30:86400
(1) This creates an A record called "testdomain.com" and directs it to the "12.56.89.30" IP address with a TTL of
86400.
(2) This line, since it starts with a ".", tells us the name of the Name Server that controls this domain. i.e. - this should
be the address of whatever nameserver the domain points to at the registrar.
(3) This sets up an MX record for our domain. This line would create an MX record for "testdomain.com" called
"mail.testdomain.com" which points to "12.56.89.30", has an MX preference of "10" and a TTL of 86400. If we wanted
to create a secondary MX, we would create another line similar to this one, but then change the destination address
and also change the preference number to suit our needs.
(4) Another "A" record. This one creates an "A" record called "www" and points it to "12.56.89.30".
(5) This last line is yet another "A" record, but you will note the "*" (asterik) added to this one. The "*" before the
hostname denotes a "wildcard" "A" record. A wildcard "A" record will allow the functionality of any "A" records which
are not already specified. In other words, it's a catchall. This means that I could browse to "whatever.testdomain.com"
and that address would resolve to my site thanks to the wildcard.
Keep in mind that this is just a general overview of the "data" file syntax and that there are a lot of other things you can
do with this file that I'm not mentioning here. If you want a full explanation of the tinydns data file and all the
possibilities, check out Dan Bernstein's page on the subject.
Once you have made all desired changes to the "data" file, you write those changes to the "data.cdb" file simply by
running the "make" command from within the /etc/tinydns/root directory. If there are errrors, you will be notified. If you
don't get any error messages, then the changes were successfully implemented. Once you've updated the cdb file, the
changes take effect instantly.
Configuring DNScache
;; QUESTION SECTION:
;yahoo.com. IN A
;; ANSWER SECTION:
yahoo.com. 1800 IN A 66.218.71.198
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 26 00:00:08 2003
;; MSG SIZE rcvd: 43
If you get an error saying "no servers could be reached" or "operation timed out", you've got problems. Go back an
make sure you've done everything right. Also make sure you don't have any firewall rules that might effect the query.
Now let's test the external nameserver. This is a little more involved, but not too hard.
First, pick some external server that you are going to try to make the query to your nameserver from.
Next, you want to make sure that the IP address of that external server is approved to make queries against your
nameserver.
If you don't see a file named after the IP address of the external server, you need to create one...touch
/etc/ext_dnscache/10.20.30.40 - substitute the IP of the external server here.
ls /etc/ext_dnscache/root/ipNow you should see a file named after the IP of the external server.
Now log onto the external server from which you will be making the DNS query to your nameserver.Now run a test
dig...
dig @1.2.3.4 yahoo.comNote: Obviously, you want to sustitute your external nameservers IP address where I
have 1.2.3.4.
;; QUESTION SECTION:
;yahoo.com. IN A
;; ANSWER SECTION:
yahoo.com. 1800 IN A 66.218.71.198
If you get an error saying "no servers could be reached" or "operation timed out", you've got problems. Go back an
make sure you've done everything right. Also make sure you don't have any firewall rules that might effect the query.
Once you've successfully tested the internal and external nameservers, you can add the nameserver IP addresses to
the /etc/resolv.conf files. On the nameserver itself, you will want to add "nameserver 127.0.0.1" to the resolv.conf file.
On all approved external servers, you'll want to add "nameserver 1.2.3.4", where 1.2.3.4 is the external IP of your
external caching nameserver.
Now let's install and configure Vegadns, a web based dns management tool.
proceed to Step 6
Installing Vegadns
Now that I've shown you how to edit the Tinydns data file manually (which is always good to know), we're going to
install a web based DNS management tool called Vegadns. This tool will make the day to day DNS mangement a bit
easier for you and any assistants you may have.
In addition to having djbdns, daemontools and ucspi-tcp installed, you will also need:
You will want to install Vegadns directly into the public web directory of your server. This folder, for example, may be
/var/www/html. If I'm confusing you at this point, you will need to familiarize yourself with Apache.
cd /path/to/your/server/web/directory
(Example: cd /var/www/html)
mv vegadns-0.8.1 vegadns
Now it's time to create the vegadns database and database user. This database will store all of your dns server's
domain records as well as all vegadns user information.
Enter your mysql server's root password when prompted. Upon authentication, a new database called "vegadns" will
be created.
Now we create a user which will have rights on the vegadns database...
mysql -u root -e "GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER ON vegadns.* TO
vegadns@localhost IDENTIFIED BY 'password'" mysql -p
Enter you mysql server's root password when prompted. Upon authentication, a new user called "vegadns" will be
added to your mysql server and that user will be assigned all needed privileges on the "vegadns" database.
Alright. That's it for the database business. Now it's time to configure Vegadns itself. The first thing we will do is create
series "private" directories. These directories will store template information, config information, caching information
and session information. The location of the folder containing these "private" directories will be located just outisde of
your web server's public directory. This location will vary from system to system, so you will need to know how your
particular server is configured in order to supply the correct information. On Redhat, for example, the public html
directory is usually located at /var/www/html. So, in the case of Redhat, I would place the private folder just outside on
the html directory, at /var/www/vegadns_private. So let's get to it...
mkdir -p /path/to/web/server/root/vegadns_private/templates_c
mkdir /path/to/web/server/root/vegadns_private/configs
mkdir /path/to/web/server/root/vegadns_private/cache
mkdir /path/to/web/server/root/vegadns_private/sessions
Here's an example. Keep in mind that this path may vary. Don't be a dumbass here. Find
out how your web server is configured and make whatever adjustments are needed...
mkdir -p /var/www/vegadns_private/templates_c
mkdir /var/www/vegadns_private/configs
mkdir /var/www/vegadns_private/cache
mkdir /var/www/vegadns_private/sessions
Now we will grant ownership of this new directory to whatever user your Apache server runs as. On Redhat, this is
usually a user called "apache". On FreeBSD, it could be a user called "www" or "nobody". Again, check your Apache
setup to be sure.
OK, that's it for the private directory. Now it's time to edit the master Vegadns config file. Again, the path to
this file will vary, but it will be in the public web directory that you unpacked Vegadns in to begin with. On
Redhat, for example, this would be /var/www/html/vegadns/src/config.php.
vi /path/to/your/server/web/directory/vegadns/src/config.php
Make sure that each of the following variables are set accordingly. As always, I have highlighted in RED the
areas wheere you will need to substitute in the correct information.
$private_dirs = '/path/to/web/server/root/vegadns_private';
// Mysql settings
$mysql_host = 'localhost';
$mysql_user = 'vegadns';
$mysql_pass = 'password';
$mysql_db = 'vegadns';
$vegadns_url = 'http://127.0.0.1/vegadns/';
Note: If you plan to administer your dns server from somewhere besides localhost, you will need to add that IP
address to the $trusted_hosts variable above. Each IP is seperated by a comma.
Now it's time to test Vegadns. We'll log into the web interface, make some changes and create a zone entry or 2. After
that we will make the zone entries active by writing the changes out the actual tinydns data file.
So let's do it...
http://yourdomain.com/vegadns (screenshot)
For our first login, we will use the dfault login account that comes with Vegadns...
Email: test@test.com
Password: test
Once you are logged in, you'll want to start customizing your Vegadns setup and then create some domain entries.
After that, you will then want to write your new domain entries out to the actual tinydns data file. Any and all changes
made in the Vegadns interface are only live once those changes get written to the tinydns data file. We'll go over that
further down the page. I've divided this work into 4 sections:
The first thing you will want to do is to change the login account information. This is done by clicking on "accounts" and
then editing the account info for the "test@test.com" user (screenshot). You will want to do a couple things to that user:
You can also create any other users you may desire in the "accounts" section.
Next, you will want to configure the default template for all domains. A default domain template ensures that every time
you create a new domain entry on your tinydns server, it gets created with certain basic settings and records. The
domain gets created with pre-conifgured A records, MX records, nameservers, TTL settings and more. Then, all you
have to do is make any customizations to the new domain and you're all set. In short, a domain template saves time
and ensures that all domains get created in a standard fashion. So let's do it...
You can edit the default domain settings by clicking on the "Default Records" link in the Vegadns interface. Now it's
simply a matter or setting whatever defaults you want each domain to have.
click to enlarge
Now that you've got a default domain template, you can create a new domain on your tinydns server. This is easily
done by clicking on the "New Domain" link and following the instructions. You will notice that the new domain gets
created with the default settings that you specified in the default domain area. Once the domain has been created, you
can then go in and customize the record for that domain to your liking, if any customizations are needed at all. Pretty
cool, huh?
As I said above, all changes made with Vegadns are not live until you write them out to the actual tinydns data file and
then run "make" on that file. The changes you make ARE instantly written to the vegadns database, but that datebase
DOES NOT control tinydns. It is only when the database contents are written out to tinydns that your changes are
made live.
Fortunately, Vegadns comes equipped with a handy script that writes all changes out to tinydns. This script is located
at path/to/your/server/web/directory/update-data.sh. Again, the path to this script will vary with your server's setup.
So, we'll first want to make sure that the update-data.sh script is configured correctly for your server...
vi update-data.sh
VEGADNS='http://127.0.0.1/vegadns/index.php'
TINYDNSDIR=/etc/tinydns
Note: The TINYDNSDIR variable may vary is you have a customized tinydns setup. It you've installed tinydns
according to this site, however, the above setting will work.
OK, so now that the update-data.sh file is configured correctly, lets execute it...
./update-data.sh
You shouldn' get any errors if all goes well. You can then check to make sure that the script wrote your new domain
entries to tinydns by viewing the /etc/tinydns/root/data file. The domain entries should have been written to that file if all
went well.
With the update-data.sh script now working, we will copy that script to a more universal location...
cp update-data.sh /usr/local/sbin/update-data.sh
And now we will install a cronjob to run this script every 10 minutes. In this way, anytime you update your Vegadns
domain entries, you will only have to wait a maximum of 10 minutes before the changes are automatically written our to
tindns and put into effect.
crontab -e
Alright! You've done it. You now have a fully functioning dns server and a user friendly interface for managing all of
your domains. It doesn't get any easier than this!
Well, let's take a look at the DNS entries for djbdnsrocks.org. It's pretty typical, so here's the exact sytax from my
/etc/tinydns/root/data file:
.djbdnsrocks.org:207.44.231.12:ns4.namegenie.net:3600
.djbdnsrocks.org:64.246.61.178:ns1.namegenie.net:3600
.djbdnsrocks.org:64.246.61.179:ns3.namegenie.net:3600
.djbdnsrocks.org:66.98.186.152:ns2.namegenie.net:3600
+djbdnsrocks.org:64.246.60.29:3600
+www.djbdnsrocks.org:64.246.60.29:3600
+nl.mirror.djbdnsrocks.org:213.84.134.134:3600
@djbdnsrocks.org:64.246.60.29:mail.djbdnsrocks.org:10:3600
As you can see, it's not rocket science. The first 4 lines of the file are preceded by a period ".", which denotes that those
are NS/SOA records. As you can see, I've got 4 authoritative nameservers that handle djbdnsrocks.org's DNS. Next, you
will see 2 lines preceded by a plus sign "+", which indicates that these are "A" records. Quite naturally, I've got an "A"
records for both "djbdnsrocks.org" and "www.djbdnsrocks.org" and you can see that they both resolve to the IP
64.246.60.29. You will also notice an "A" record called "nl.mirror.djbdnsrocks.org", which provides the address for the
djbdnsrocks.org mirror site in Netherlands. Last, but not least, is the MX record, made painfully obvious because the line is
preceded by a "@". The MX record establishes the djbdnsrocks.org, whose IP address is 64.246.60.29, has a target mail
record of "mail.djbdnsrocks.org" with a MX preference of 10. You will also note that all of the records shown have a TTL of
3600 seconds.
Sure. The picture below is a very simplified diagram of what a DNS system might look like:
This system is comprised of 4 DNS servers, 1 master and 3 slaves. So what does that mean? Well, let's break it down.....
We start by installing tinydns of 4 different servers. We then choose one of those 4 servers to be the master DNS server.
On the master DNS server we then install Vegadns, so that we can have an interface for editing DNS entries on that
server. Directly above the "master dns server" you will see a green box labeled "dns interface". If you installed tinydns
according to this site, the green box would be your installation of Vegadns. The dns administrator uses Vegadns to create
and edit domain DNS records. Those changes, when implemented, are written to the /etc/tinydns/root/data file on the
master server (ns1) and then compiled into the /etc/tinydns/root/data.cdb file which is in turn read by tinydns on the master
server. As you've probably guessed, I call ns1 the "master" server because it is the first server to get changes written to it.
In other words, if a change is made to a domain's DNS records, the ns1 server is going to know about it first. Once ns1
knows about the changes, then we have to find some way of letting the other 3 servers (slaves) know about the changes. I
do this with the "rsync" utility coupled with a crontab entry. Basically, every 5 minutes a crontab entry runs which uses the
"rsync" utility to push the new modified /etc/tinydns/root/data.cdb file out to the other 3 servers. Once the other servers
have the latest copy of the data.cdb file, they will instantly know about the changes. In this way, anytime a change is made
to a domain, it takes a maximum of 5 minutes before all 4 servers know about it. Once all 4 servers have the latest DNS
changes, those changes are then available for the rest of the Internet (the big grey oval) to pick up on. The automated
"rsync" connection is made possible by creating special rsync users and using SSH authentication keys. The whole rsync
process is not too complicated, but if your confused you may want to some reading up on using "rsync" and using SSH
public and private keys.
I am a purist and I don't like to use Vegadns. Will this model still work?
If you are a purist and you don't like to use Vegadns, the same model would still apply. The only difference is that you
would manually edit the /etc/tinydns/root/data file on the master DNS server and then run the /etc/tinydns/root/make
command to compile the changes into the /etc/tinydns/root/data.cdb file. Then, sometime in the next 5 minutes, the "rsync"
crontab would run, thus pushing out your changes to the other 3 servers.
Feedback
You've used my site, now give me some feedback. I'm very receptive of suggestions and/or constructive
criticism, so feel free to voice your opinion.
Your Name:
(if you want me to
reply)
Your E-mail:
(if you want me to
reply)
Any comments/suggestions?
Submit Feedback
Home
You are responsible for your own actions. Yes, you. Imagine that. Imagine taking responsibility for your own actions.
I'm not forcing you to install djbdns on your server. This site is NOT an official djbdns guide in any way and this site
is in no way affiliated with Dan Bernstein or any other official djbdns resource. This is a completely independent site
that merely documents my installation of djbdns on my servers. This does not guarantee that it will work on your
server. All servers are different and you will likely need to tweak the install to fit your needs on your particular server.
Do not take this installation guide as a literal bible of how to install djbdns. ALWAYS USE A TEST SERVER when
you first install djbdns or any other software for that matter. Don't be an idiot and install djbdns for the first time on
your big production server that you make a living off of and feed your family with. In other words....
Visitor Feedback
Very cool site! I've been sort of waiting for someone to tell it like it is, and with style
Thanks so much for making this guide available. I love: your get-down-to-it approach, the fact that you include
troubleshooting and test info, the fact that you make a downloadable guide available (though I haven't used it yet).
You think about presenting it all in the right way!
Great job!
Thanks for this djbdns stuff. Amazingly simple, and super to have the RH9 patch. Awesome stuff. I will link to you
guys in the future.