Running djbdns client programs

In addition to its server daemons and support processes, djbdns includes client utilities (Table 6-7). These perform the same functions as BIND’s old utilities, nslookup and dig, and are useful for troubleshooting and testing your DNS infrastructure.

Table 6-7. Client programs included in djbdns

Program Syntax Description

dnsip dnsip_[fqdn2...] fqdn1 Print the IP addresses of one or more fully qualified domain names. dnsname dnsname_[ip2...] ip1 Print the first domain name of one or more IP addresses.

dnsmx dnsmx fqdn Print the MX record for fqdn. dnstxt dnstxt fqdn Print the TXT record for fqdn.

dnsq dnsq_server type fqdn Send a nonrecursive query to server for records of type type for fqdn.

dnsqr dnsqr type fqdn Get records of type type for fqdn. This sends a recursive query to the name server specified in /etc/resolv.conf. dnsqr and is similar to the programs dig, host, and nslookup.

dnstrace

dnstrace type fqdn server1

[server2...]

Find all DNS servers that can affect the resolution of records of type type for fqdn starting from one or more root name servers server.

dnsfilter dnsfilterqueries] [ [-n-c lines]

Substitute hostnames at the start of text lines to IP addresses. Reads from standard input and writes to standard output. queries is the maximum number of DNS queries to do in parallel (default is 10). lines is the number of lines to read ahead (default is 1000).

6.5.7 Coexisting with BIND

You may decide to install some components of djbdns on your servers to handle name-service duties. By choice or necessity, you may need to share these duties with an existing BIND installation. This section describes how to exchange zone data between name servers running djbdns and BIND.

6.5.7.1 Installing ucspi-tcp

You first need to install a small external toolkit, also written by Bernstein, called ucspi-tcp. This contains the tcpserver and tcpclient programs. Similar to inetd, they manage external access to TCP-based clients and servers, but they do so more reliably due to better load and resource controls. Follow these steps to install ucspi-tcp:

1. Using wget (or the FTP tool of your choice), download the latest tarball from http://cr.yp.to/ucspi- tcp/install.html: $ wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz 2. Extract: $ tar xvzf ucspi-tcp-0.88.tar.gz 3. Build: 4. $ cd ucspi-tcp.0.88 $ make

5. As root, install under /usr/local/bin: # make setup check

6.5.7.2 Running axfr-get

The axfr-get client requests a zone transfer from a name server via AXFR. The syntax is as follows: axfr-get dom file file.tmp

This requests a zone transfer for domain dom. The data is written to the file file.tmp in tinydns-data format. The first line written to file.tmp is a comment with the zone’s serial number. If the transfer is successful, file.tmp is renamed to file.

Make sure you only request data for zones where your tinydns server is a secondary server. Merge this data with that for which your tinydns server is primary in the tinydns datafile

/service/tinydns/root/data.

A simple solution is this addition to /service/tinydns/root/Makefile. Our tinydns server is a.ns.hackenbush.com, and we are providing secondary name services for the domain

flywheel.com, whose name server is ns.flywheel.com: all: data.cdb

flywheel.data:

a.ns.hackenbush.com \ 53 \ /usr/local/bin/axfr-get \ flywheel.com \ flywheel.data \ flywheel.tmp

data: hackenbush.data flywheel.data cat *.data > data

data.cdb: data

usr/local/bin/tinydns-data Run make as often as necessary to get flywheel’s data.

axfr-get is a client. It does not support NOTIFY (RFC 1996) or IXFR (RFC 1995). It does not automatically send an AXFR request to the primary external name server when the SOA’s refresh timeout expires; you need to ensure that axfr-get is called often enough (such as in an hourly cron job). It will first get the SOA and check its serial number. If it’s larger than the local value, then it will request the zone data via AXFR. It would be nice to have a server version of axfr-get that handles BIND primaries the same as BIND secondaries. Then we would have a complete drop-in replacement for a BIND secondary (unless you’re using DNSSEC or an experimental protocol).

6.5.7.3 Installing axfrdns

axfrdns uses TCP port 53, so it can share an IP with tinydns, which uses UDP port 53. Assuming you’ll use the IP 192.193.194.195, follow these steps:

1. Create the service directory:

2. # axfrdns-conf axfrdns dnslog /etc/axfrdns /etc/tinydns 192.193.194.195

# cd / etc /axfrdns

3. Edit the tcp file to allow zone transfers from 200.201.202.203 for hackenbush.com and its reverse:

200.201.202.203:allow,AXFR="hackenbush.com,194.193.192.in- addr.arpa"

4. Get tcp into a binary format: # make

5. Tell daemontools about the service:

# ln -s /etc/axfrdns /service 6.5.7.4 Running axfrdns

The secondary server will request a zone transfer from axfrdns when the TTL of the zone’s SOA record expires. axfrdns will serve the zone from the same authoritative database used by tinydns: data.cdb. You can also cause the secondary server to request a zone transfer immediately by sending it a notify message. Although not a part of standard djbdns, the Perl script tinydns-notify (available online at

http://www.sericyb.com.au/tinydns-notify) can be used for this.

axfrdns only responds to AXFR requests, and it transfers whole zones. If an external name server like BIND makes an IXFR request to axfrdns, it will fail. RFC 1995 says the requester should then try AXFR (RFC 1995), but a bug in BIND prevents this. The problem is fixed by any of these:

• Patch axfrdns to accept IXFR. A two-line patch has been proposed. • Upgrade BIND to Version 9.2 or higher.

For incremental and secure transfers, Bernstein recommends using rsync and ssh instead of AXFR and IXFR.