TinyDNS

All posts tagged TinyDNS

TinyDNS: Sample data file with easy to understand comments.

Posted by phatdee on November 26, 2011
Posted in: DNS. Tagged: , , , . Leave a Comment

I tested this in my TinyDNS setup and worked great.

# verbose tinydns data file

#
# REVERSE ZONE
#
# (reverse) dns servers: primary and secondary
Z45.168.192.in-addr.arpa:ns.example.net:hostmaster.example.net::::::::

# NS records
&45.168.192.in-addr.arpa::ns.example.net:::
&45.168.192.in-addr.arpa::ns2.example.net:::

# MX handlers
@45.168.192.in-addr.arpa::relay.example.net:10
@45.168.192.in-addr.arpa::relay2.example.net:20

#
# FORWARD ZONE:
#
# SOA record: primary nameserver is ns.example.net and hostmaster
# mail address is hostmaster@example.net
# (the ‘Z’ configuration line is the only one that
# allows specifying the hostmaster mail address)
Zexample.net:ns.example.net:hostmaster.example.net::::::::

# NS records: primary and secondary nameservers
&example.net::ns.example.net:::
&example.net::ns2.example.net:::

# MX records: relay.example.net, distance = 10
# relay2.example.net, distance = 20
@example.net::relay.example.net:10
@example.net::relay2.example.net:20

# A records: ns.example.net, ns2.example.net
=ns.example.net:192.168.45.1:::
=ns2.example.net:192.168.45.2:::

# PTR records: relays are in the same hosts as dns servers
+relay.example.net:192.168.45.1:::
+relay2.example.net:192.168.45.2:::

# more A records: gateway.example.net
=gateway.example.net:192.168.45.254:::

# CNAME record: nscache.example.net is alias to gateway.example.net
Cnscache.example.net:gateway.example.net:::

#
# SUB DOMAIN DELEGATION
#

# NS record
&dmz.example.net::ns.dmz.example.net:::

# A/PTR record for nameserver
=ns.dmz.example.net:192.168.90.1:::

TinyDNS and LogWatch

Posted by phatdee on October 18, 2011
Posted in: DNS. Tagged: , , . Leave a Comment

tinydns and logwatch

There are no translations available.

 

This page is written to explain how to integrate logwatch and tinydns, a component of djbdns.

First, download the logwatch script to your server:

cd /usr/share/logwatch/scripts/services/
wget http://www.cypress-systems.net/scripts/tinydns
chmod 755 tinydns

Second, edit the script to tell logwatch where the logfile is looking for

vim /usr/share/logwatch/default.conf/services/tinydns.conf

Title = “tinydns”
LogFile = tinydns
# vi: shiftwidth=3 tabstop=3 et

 

Third, tell logwatch where the logs are exactly stored

vim /usr/share/logwatch/default.conf/logfiles/tinydns.conf

LogFile = /service/tinydns/log/main/@*.s
LogFile = /service/tinydns/log/main/current
# Keep only the lines in the proper date range…
*applytaidate
# vi: shiftwidth=3 tabstop=3 et

 

Four, run a test to see if there is any output

logwatch –service tinydns –range today –detail 10 –output stdout

djbdns (TinyDNS/DNScache) install guide

Posted by phatdee on August 13, 2011
Posted in: TinyDNS djbdns. Tagged: , , , , . Leave a Comment

I know there are others, but this is mine.   I always forget how-to change the default installation path with his software, until of course it’s too late and then I get to re-do it.

Need daemontools, ucspi-tcp, and djbdns source code.

 

Create a working directory

$ mkdir ~/working  && cd ~/working

Grab src code

$ wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz

$ wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
$ wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz

1).  First install daemontools, now if you have never installed anything from David Bernstein, his approach, may seem a little different than what you are normally used to with ./configure; make; make install.  There might be a easy approach to moving this somewhere else but I have found that when I do..it sometimes comes back to bite me.  So for daemontools, I leave it defaulted even thought it still drives me nuts everytime..

Create a /package directory:

TinyDNS vs Bind

Posted by phatdee on August 12, 2011
Posted in: TinyDNS djbdns. Tagged: , , , . Leave a Comment

We use TinyDNS at work.  I will admit when I started working at this company, I didn’t much care for TinyDNS.  However, the more I read up on it, and the more I actually witness the performance of this daemon.  I am always walking away with the same thought…”Wow, the creator of TinyDNS is just brilliant”  in reference to David J Bernstein. (djbdns).

 

Ease of use: BIND versus djbdns

Problem: Set up an external cache on 1.2.3.4 for clients in the 1.2.3.* network. BIND solution:

  1. Create a localhost zone file, with an SOA record, an NS record, and an A record.
  2. Create a 0.0.127.in-addr.arpa zone file, with an SOA record, an NS record, and a PTR record.
  3. Create a root.hints zone file with the root server IP addresses.
  4. Create a named.conf file: zone "localhost" in { type master; file "localhost"; }; zone "0.0.127.in-addr.arpa" in { type master; file "0.0.127.in-addr.arpa"; }; zone "." in { type hint; file "root.hints"; }; options { interface-interval 0; listen-on { 1.2.3.4; }; allow-query { 1.2.3/24; }; };
  5. Start named.
  6. Make sure that your boot scripts start named.
 djbdns solution:

  1. Create Gdnscache and Gdnslog accounts.
  2. dnscache-conf Gdnscache Gdnslog /etc/dnscache 1.2.3.4
  3. ln -s /etc/dnscache /service
  4. cd /service/dnscache
  5. touch root/ip/1.2.3
Problem: Also allow queries from clients in the 1.5.* network. BIND solution:

  1. Edit named.conf.
  2. Add 1.5/16 to the allow-query section.
  3. Send a HUP signal to named.
  4. Look for errors in your system’s logs. The DNS and BIND” book says, correctly, that you have to do this, because otherwise you might never notice” syntax errors in the configuration files.
 djbdns solution:

  1. cd /service/dnscache
  2. touch root/ip/1.5
Problem: Run the cache non-root and chrooted. BIND solution:

  1. Create a Gbindin account.
  2. mkdir /etc/bindin
  3. Copy various system-dependent files, which are not thoroughly described in the BIND manual, into /etc/bindin.
  4. Kill named.
  5. Start named -u Gbindin -t /etc/bindin.
  6. Change the named line in your boot scripts accordingly.
 djbdns solution: Relax. It’s already non-root and chrooted.
Problem: Arrange for the cache to be restarted if someone accidentally kills it. BIND solution: Write a script that looks for the named process, restarts named if it is not running, pauses for a second, and repeats. Start that script. djbdns solution: Relax. The cache is already monitored.
Problem: Tell the cache to consult an internal server at IP address 10.1.2.5 for information about moon.x.mil. BIND solution:

  1. Edit named.conf.
  2. Add a forwarding zone: zone "moon.x.mil" in { type forward; forward only; forwarders { 10.1.2.5; }; };
  3. Send a HUP signal to named.
  4. Look for errors in your system’s logs.
 djbdns solution:

  1. cd /service/dnscache
  2. echo 10.1.2.5 > root/servers/moon.x.mil
  3. svc -t .
Problem: Tell the cache to follow a new delegation from the internal server to 10.1.2.6 for d.moon.x.mil. BIND solution:

  1. Edit named.conf.
  2. Add another forwarding zone: zone "d.moon.x.mil" in { type forward; forward only; forwarders { 10.1.2.6; }; };
  3. Send a HUP signal to named.
  4. Look for errors in your system’s logs.
 djbdns solution: Relax. The cache follows delegations.
Problem: Set up a server on 1.2.3.5 to publish information about x.mil and 1.2.3.*. BIND solution:

  1. Create an x.mil zone file, with an SOA record and an NS record.
  2. Create a 3.2.1.in-addr.arpa zone file, with an SOA record and an NS record.
  3. Create a named.conf file: zone "x.mil" in { type master; file "x.mil"; }; zone "3.2.1.in-addr.arpa" in { type master; file "3.2.1.in-addr.arpa"; }; options { interface-interval 0; listen-on { 1.2.3.5; }; recursion no; fetch-glue no; allow-transfer { none; }; };
  4. Start named.
  5. Make sure that your boot scripts start named.
 djbdns solution:

  1. Create Gtinydns and Gdnslog accounts.
  2. tinydns-conf Gtinydns Gdnslog /etc/tinydns 1.2.3.5
  3. ln -s /etc/tinydns /service
  4. cd /service/tinydns/root
  5. ./add-ns x.mil 1.2.3.5
  6. ./add-ns 3.2.1.in-addr.arpa 1.2.3.5
  7. make
Problem: Run the server non-root and chrooted. BIND solution:

  1. Create a Gbindout account.
  2. mkdir /etc/bindout
  3. Copy various system-dependent files, which are not thoroughly described in the BIND manual, into /etc/bindout.
  4. Kill named.
  5. Start named -u Gbindout -t /etc/bindout.
  6. Change the named line in your boot scripts accordingly.
 djbdns solution: Relax. The server, like the cache, is already non-root and chrooted.
Problem: Add a host, lion.x.mil, with address 1.2.3.4. BIND solution:

  1. Edit the x.mil zone.
  2. Add lion A 1.2.3.4.
  3. Change the serial number in the SOA record.
  4. Edit the 3.2.1.in-addr.arpa zone.
  5. Add 4 PTR lion.x.mil.
  6. Change the serial number in the SOA record.
  7. Send a HUP signal to named.
  8. Look for errors in your system’s logs. As noted above: The DNS and BIND” book says, correctly, that you have to do this, because otherwise you might never notice” syntax errors in the configuration files.

Oops! Did I forget the dot on lion.x.mil? As the DNS and BIND” book says: It’s very easy to leave off trailing dots.”

 djbdns solution:

  1. cd /service/tinydns/root
  2. ./add-host lion.x.mil 1.2.3.4
  3. make

You don’t have to check your system’s logs: if there are any syntax errors, disk-write errors, etc., they’ll appear on your screen in response to make. Anyway, the add-host program never introduces any syntax errors.
Problem: Avoid accidentally reusing a previous host name, or reusing a previous host IP address. BIND solution: Manually search the zone file for the new host name and the new IP address. You won’t have to look far if you sort your forward zones by name and sort your reverse zones by address. djbdns solution: Relax. add-host handles this automatically. (If you want to reuse a name or address, use add-alias.)
Problem: Avoid destroying a zone if there’s trouble saving new data: e.g., not enough disk space, or a sudden power outage. BIND solution:

  1. Copy the zone file.
  2. Edit the copy.
  3. Sync the copy to disk.
  4. Rename the copy.
 djbdns solution: Relax. add-host handles this automatically.
Problem: Make sure there are no syntax errors in new data added by hand. BIND solution: Watch your system’s logs for error messages. Some messages mean that named is no longer providing information about that zone, and users will begin seeing failures in a matter of seconds; in this case, panic. djbdns solution: If there is a syntax error, make will print an error message immediately, and tinydns will continue providing the old data.
Problem: Send incoming mail for x.mil to a mail server at 1.2.3.4. BIND solution:

  1. Edit the x.mil zone.
  2. Add @ MX 0 lion.
  3. Change the serial number in the SOA record.
  4. Send a HUP signal to named.
  5. Look for errors in your system’s logs.
 djbdns solution:

  1. cd /service/tinydns/root
  2. ./add-mx x.mil 1.2.3.4
  3. make
Problem: Delegate elysium.x.mil to a DNS server at 1.2.3.144. BIND solution:

  1. Edit the x.mil zone.
  2. Add elysium NS a.ns.elysium.
  3. Add a.ns.elysium A 1.2.3.144.
  4. Change the serial number in the SOA record.
  5. Send a HUP signal to named.
  6. Look for errors in your system’s logs.
 djbdns solution:

  1. cd /service/tinydns/root
  2. ./add-childns elysium.x.mil 1.2.3.144
  3. make
Problem: Replicate DNS service from 1.2.3.5 to 1.2.3.6. BIND solution: On 1.2.3.5:

  1. Edit named.conf.
  2. Insert 1.2.3.6; into the allow-transfer section.
  3. Edit the x.mil zone file.
  4. Add an NS record pointing to 1.2.3.6.
  5. Edit the 3.2.1.in-addr.arpa zone file.
  6. Add an NS record pointing to 1.2.3.6.
  7. Send a HUP signal to named.
  8. Look for errors in your system’s logs.

On 1.2.3.6:

  1. Create a named.conf file: zone "x.mil" in { type slave; file "x.mil"; masters { 1.2.3.5; }; }; zone "3.2.1.in-addr.arpa" in { type slave; file "3.2.1.in-addr.arpa"; masters { 1.2.3.5; }; }; options { interface-interval 0; listen-on { 1.2.3.5; }; recursion no; fetch-glue no; allow-transfer { none; }; };
  2. Start named.
  3. Make sure that your boot scripts start named.
 djbdns solution: On 1.2.3.6:

  1. Create Gtinydns and Gdnslog accounts.
  2. tinydns-conf Gtinydns Gdnslog /etc/tinydns 1.2.3.6
  3. ln -s /etc/tinydns /service

On 1.2.3.5:

  1. cd /service/tinydns/root
  2. At the top of Makefile, add a target remote: data.cdb, with command rsync -az -e ssh data.cdb 1.2.3.6:/ service/ tinydns/ root/ data.cdb. (No spaces after the slashes.)
  3. ./add-ns x.mil 1.2.3.6
  4. ./add-ns 3.2.1.in-addr.arpa 1.2.3.6
  5. make
Problem: Replicate a newly created zone. BIND solution:

  1. Edit named.conf.
  2. Add a new type slave line.
  3. Send a HUP signal to named.
  4. Look for errors in your system’s logs.
 djbdns solution: Relax. New zones are automatically replicated.

Startup script for TinyDNS

Posted by phatdee on August 10, 2011
Posted in: TinyDNS djbdns. Tagged: , , , . 1 comment

# cat /etc/init.d/tinydns
#!/bin/sh
#
# tinydns Authoritative DNS server
#
# chkconfig: 345 11 89
# description: Dan Bernstein (DJB) authoritative dns server
#

# See how we were called.
case “$1” in
start)

echo -n “Starting: ”
env – PATH=”/var/qmail/bin:/usr/local/bin” IP=192.168.2.226 \
ROOT=/var/tinydns/root envuidgid tinydns softlimit -d300000 \
/usr/local/bin/tinydns 2>&1 | /usr/local/bin/multilog t /var/tinydns/log/226 &
# ROOT=/var/tinydns/root envuidgid tinydns softlimit -d300000 \
# /usr/local/bin/tinydns 2> /dev/null &
env – PATH=”/var/qmail/bin:/usr/local/bin” IP=192.168.2.227 \
ROOT=/var/tinydns/root envuidgid tinydns softlimit -d300000 \
/usr/local/bin/tinydns 2>&1 | /usr/local/bin/multilog t /var/tinydns/log/227 &
# ROOT=/var/tinydns/root envuidgid tinydns softlimit -d300000 \
# /usr/local/bin/tinydns 2> /dev/null &

echo “tinydns”
;;
stop)
killall tinydns
;;
restart)
$0 stop
$0 start
;;
*)
echo “Usage: tinydns {start|stop|restart}”
exit 1
esac

exit 0