topics that matter; ideas worth sharing

share a tip, submit a link, add something new

DJBDNS: The pieces

July 30, 2002, 12:00 AM —  ITworld — 

DJBDNS has many separate pieces, not all of which you necessarily need.
The separate pieces include:

* dnscache -- This is the recursive caching name server, which
simply looks up the DNS records you request. It consults the
thirteen root DNS servers and winds it's way up to the answer.
You can also associate zones with name servers manually to support
non-official zones, such as internal networks. dnscache listens on
both TCP and UDP port 53.
* tinydns -- This is the DNS server you run to let others resolve
your hostnames and IP addresses. It will only serve the data that
you've given it, so you cannot point to it as your default name
server -- point to a dnscache IP address instead. tinydns listens
on UDP port 53.
* axfrdns -- This server allows authorized BIND secondary DNS
servers to mirror your zone files. The 'official' DJBDNS way to
synchronize zones is to simply rsync the files from the master to
the slaves. However, for compatibility with BIND's zone transfers,
you can run axfrdns. axfrdns listens to TCP port 53.

You may have noticed above that dnscache and tinydns both want to listen
on UDP port 53. That means that you cannot have both of these processes
listening on the same IP address. DJB's official retort is that you
should be using separate machines for this purpose anyway, which is
pretty much true. However, if you want to run both on the same machine,
then you can run each on it's own virtual IP address (eth0:0 vs eth0:1,
etc...) or you could run dnscache on localhost (available only to that
machine) and tinydns on the external interface. The network setup you
pick will depend on your needs.

Each of these servers are run through the supervise/svscan processes we
installed earlier. These processes require a special directory layout to
define the programs to run; however, you can run configuration programs
to handle the grunt work. Let's start off by setting up dnscache:

# dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.5

The arguments are:

* dnscache -- The user the daemon will run as.
* dnslog -- the user the logging component will run as.
* /etc/dnscache -- The directory to set up for supervise.
* 127.0.0.5 -- The IP address dnscache should listen on.

For now I'm setting the IP address to be 127.0.0.5 because it's a
convenient way to test things.[1] If you already have BIND listening on
localhost (127.0.0.1) then using 127.0.0.5 won't conflict and we can
verify all is well before turning off BIND.

This creates the following directories

I like it!
Post a comment
The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
Resources
White Paper

Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.

Webcast

Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.

White Paper

Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.

Free stuff
Featured Sponsor

AISO founders envisioned a Web hosting company that was environmentally friendly. While the company employed energy-efficient innovations like solar panels, its infrastructure produced unacceptable power and cooling requirements. Find out how AISO leveraged AMD technology to overcome their challenge in this case study white paper.

In this whitepaper, Scalar explores the opportunity to change the landscape with respect to mission critical databases built around Oracle. Leveraging technologies such as Linux, high-end commodity processing power and Oracle RAC technology to architect, design, build and maintain database infrastructure that delivers maximum availability, reliability and performance at a fraction of traditional cost.

On a typical day, weather.com, the Web site for The Weather Channel in Atlanta, serves up between 15 million and 20 million page views. But in September 2004, when back-to-back hurricanes ransacked Florida, the peak traffic on one day more than tripled: over 70 million page views by more than 7 million unique visitors. Read the full success story now.

More Resources