Please note that many people use confusing terminology because of BIND,
which integrates a caching DNS resolver and a DNS server into one
package, making people say "DNS server" when they are really talking
about a "DNS resolver".

djbdns separates the resolver and the server, which provides enhanced
security and flexibility but when people try to run both on the same IP
address (as is default mode of operation for BIND), it will fail silently.

Well, you don't. You run dnscache on your ethernet IP and tinydns on
127.0.0.1 and then tell dnscache to ask tinydns.

You may run both dnscache and tinydns on the same IP and port, because
they are UDP servers. Your operating system will then forward each DNS
query to one of them, and you should not assume a pattern to the
selection. tinydns will just drop queries it can't answer, so every
query that is forwarded to tinydns will be dropped.

The client will ask the same query again after a few seconds, so to the
user this will look like the network is slow. If the next query is by
chance again forwarded to tinydns, the timeout will appear longer. If
you try to resolve data from tinydns but reach dnscache, you will get a
server failure.

You have to decide now: do you need the caching resolver to be
accessible by other computers? If so, bind dnscache to your external IP and
tinydns to 127.0.0.1 and tell dnscache to
consult tinydns for the relevant addresses. See also Split
Horizon.

This setup has the drawback that dnscache will never return
authoritative answers (this is a bit in DNS answer packets). This won't
matter for most clients, but technically it is not correct. For
example, your domain registry might complain about this. (Thanks to
Brian Kifiak for pointing this out) DON'T DO THIS ON PRODUCTION NAME
SERVERS! Proper resolvers (i.e. dnscache) will not accept
non-authoritative answers.

The best solution is to use IP aliases, for example on Linux you can
simply assign IPs to "lo:1", "lo:2" and so on.

Many people are intimidated by the daemontools setup instructions and
are thus afraid to try out djbdns. DJ Bernstein does not
advocate this, but you can use the different DNS servers and dnscache
without svscan and supervise. This FAQ entry only says how to avoid running
"svscan", i.e. you still have to install the daemontools package for the
envuidgid and softlimit programs which are generally useful and used by
the djbdns invocation scripts.

Just follow the setup instructions and you will have a shell script
/service/tinydns/run. This shell script will start the service
(but it does not fork into the background, so for a System V style init
script you would use something like this:

Split horizon DNS means that you have one machine that answers internal
and external DNS queries, i.e. internal hosts can look up hosts in the
Internet and external hosts can look up your DNS zone.

The catch is that

external hosts should only see part of your DNS

external hosts should talk to tinydns, not dnscache (i.e. don't
answer DNS queries for other people)

For split horizon DNS, you normally have two network interfaces in your
host. Let's call them eth0 and eth1. eth0 is the external interface
and has the IP 204.71.200.33, eth1 is the internal interface and has the
IP 10.1.2.3. Your domain is called yahoo.com.

Now, to get the desired functionality, you need to run two copies of
tinydns. One will serve the public version of your zone to the world,
so obviously you use your external IP 204.71.200.33 for it.

# tinydns-conf tinydns dnslog /var/tinydns-public 204.71.200.33

To offer a caching DNS resolver to your LAN, you install a copy of
dnscache to use your internal IP 10.1.2.3.

# dnscache-conf dnscache dnslog /var/dnscache 10.1.2.3

dnscache will only answer queries from 127.0.0.1 by default, so you will
have to tell it otherwise:

# touch /var/dnscache/root/ip/10

This will allow dnscache queries from 10.* IPs. Since this network
interface is in your LAN, outsiders should not be able to send queries
to it (if you have a firewall and your setup is kosher).

The second copy of tinydns will serve the internal data of your zone to
your LAN, and since both IPs are already taken, you tell it to use the
loopback IP 127.0.0.1.

# tinydns-conf tinydns dnslog /var/tinydns-private 127.0.0.1

Now, all you have to do is to tell your dnscache that it should consult
your local tinydns when it is asked to resolve your internal yahoo.com
addresses. That's quite easy:

The second line makes sure that reverse lookups will also be forwarded
to your internal tinydns.

Please note that you should not do split horizon DNS on one machine for
security reasons, because an attacker who breaks into your DNS machine
will have access to your LAN via the eth1. It is a better idea to
configure a tinydns on a bastion host in your firewall perimeter network
and have a dnscache/tinydns combo on another host in your LAN.

[Benett Todd mailed this description of split
horizon DNS to the mailing list. You might find it easier to
understand.]

For security reasons you should not use split horizon DNS with only one
network interface. If you want it nonetheless, you need to bring up a
second network interface, which is called "dummy interface" or "alias
interface", depending on your operating system terminology. Please
consult your OS documentation. Then simply use the same configuration
as above.

If you plan to do this regularly, you might want to install axfr-get on
the BIND machine locally and use rsync over ssh to copy the converted
zones to the tinydns secondary. That improves security and performance
greatly.

There are several unofficial ones from several sources (usually
linked to from tinydns.org).
However, running a name server is only for seasoned
administrators.

Compiling djbdns yourself is trivial. If you feel you are not up to it,
please reconsider if you should be administrating a name server. An
incorrectly setup name server can do bad things to many people.