The DJBDNS Book
by
of Inter7 Internet Technologies, Inc.
Inhaltsverzeichnis
How to Install 1
Concepts 3
For Companies 5
Registering domain name server hosts 5
public and private dns servers 5
DNS record transfer fights 5
Web Interfaces 7
djbdnsadmin 7
Data file reference 9
Directory Structure and File Contents 11
SVC Reference 13
svscan 13
svc 15
supervise 16
svcstat 20
svok 20
fghack 20
multilog 21
tai64n 28
tai64nlocal 29
setuidgid 30
envuidgid 31
envdir 32
softlimit 33
setlock 34
Rsync and Ssh 37
Server Types 39
dnscache 39
tinydns 43
walldns 45
axferdns 46
Surviveablity of Opertunistic co-operative Servers in a Chaotically Distributed Environment 49
What Does That Mean? 49
Are You Opertunistic? 49
Ethics 49
The first thing to start with is one of the easiest. Let's install djbdns!
Download daemontools from
gunzip daemontools-0.70.tar.gz
tar xvf daemontools-0.70.tar
cd daemontools-0.70
make
make setup check
Done!
Download djbdns from http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
gunzip djbdns-1.05.tar.gz
tar xvf djbdns-1.05.tar.gz
cd djbdns-1.05
make
make setup check
Done!
That's it. Everything is installed on the machine. Now you are ready to go on and setup DNS servers.
If you are an expert in how DNS servers work then skip the next chapter. The next chapter covers the concepts behind DNS servers and how they work. Luckily, djbdns has separate programs for different types of DNS servers. Did you know there are different kinds of DNS servers? Well you will after the next chapter.
A picture is worth a thousand words. So let's start our discussion of Domain Name Server concepts with a picture and let's look at it from a DNS client's point of you. Or in other words, "What has DNS done for me lately?".
Let's start off with a typical user wanting to look at a web site. They are sitting at their computer, bring up their web browswer and type in a web site. For example: www.inter7.com. The first thing their web brower does is contact the dnscache server. This is setup in their computer preferences. In the diagram above, this is arrow labled 1.
In the diagram above, the dnscache server is provided by the users ISP. If the web site they are looking for is very popular another one of the ISP users would have asked for the information. DNS cachging servers "cache" or "save" the information for a while. Hopefully this saved information will be used by another user.
If the dnscacheing server has the information, then it sends it back to the user. In the diagram this is the arrow labeled 6.
If the dnscacheing server doesn't have the information then we are in for a long ride. The first the dnscaching server does is go to the root servers and ask for the IP's of the inter7.com's name servers. This is arrow 2.
The root servers then reply with inter7.com's IP's. This is arrow 3.
The ISP dnscache server then goes to one of the inter7.com domain name server IP's and asks for the IP address of www.inter7.com. This is arrow 4.
The inter7.com name server takes in the request for www.inter7.com and looks it up in it's data. The response is sent back to the ISP's dnscache. This is arrow 5.
Once the ISP's dnscache server receives the information it sends it on to the users browsers. This is arrow 6.
Blah Blah
Blah Blah
Blah Blah
Blah Blah
The svscan program
svscan starts and monitors a collection of services.
Interface
svscan starts one supervise process for each subdirectory of the current directory, up to a limit of 1000 subdirectories. svscan skips subdirectory names
starting with dots. supervise must be in svscan's path.
If a subdirectory sub is sticky, svscan starts a pair of supervise processes, one for sub, one for sub/log, with a pipe between them. svscan needs two free
descriptors for each pipe.
Every five seconds, svscan checks for subdirectories again. If it sees a new subdirectory, it starts a new supervise process. If it sees an old subdirectory
where a supervise process has exited, it restarts the supervise process. In the sticky case it reuses the same pipe so that no data is lost.
svscan is designed to run forever. If it has trouble creating a pipe or running supervise, it prints a message to stderr; it will try again five seconds later.
If svscan is given a command-line argument, it switches to that directory when it starts.
The /service directory
Normally svscan is started at boot time in a new /service directory. To set this up (under version 0.70 or above), first create /service as root:
mkdir /service
chmod 755 /service
Then start svscan from your system's boot scripts:
On Linux and other SVR4-based systems with /etc/inittab, add SV:123456:respawn:env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin
svscan /service </dev/null >/dev/console 2>/dev/console to the end of /etc/inittab, and type kill -HUP 1.
On BSD systems, put env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin csh -cf 'svscan /service &' into /etc/rc.local, and reboot.
Now use ps to check that svscan is running.
To install a new service, make a symbolic link from /service/sub to a directory elsewhere in the filesystem. svscan will spot the link within five seconds and
will start a supervise process, or two supervise processes if sub is sticky. You can then use svc on /service/sub to control the service.
To eliminate a service, remove the symbolic link, and then stop the supervise processes:
cd /service/sub
rm /service/sub
svc -dx . log
Other service-monitoring tools
SVR4-based init programs run daemons listed in /etc/inittab.
Sun's sac program runs ``port monitors'' listed in /etc/saf/_sactab.
The svc program
svc controls services monitored by supervise.
Interface
svc opts services
opts is a series of getopt-style options. services consists of any number of arguments, each argument naming a directory used by supervise.
svc applies all the options to each service in turn. Here are the options:
-u: Up. If the service is not running, start it. If the service stops, restart it.
-d: Down. If the service is running, send it a TERM signal and then a CONT signal. After it stops, do not restart it.
-o: Once. If the service is not running, start it. Do not restart it if it stops.
-p: Pause. Send the service a STOP signal.
-c: Continue. Send the service a CONT signal.
-h: Hangup. Send the service a HUP signal.
-a: Alarm. Send the service an ALRM signal.
-i: Interrupt. Send the service an INT signal.
-t: Terminate. Send the service a TERM signal.
-k: Kill. Send the service a KILL signal.
-x: Exit. supervise will exit as soon as the service is down. If you use this option on a stable system, you're doing something wrong; supervise is
designed to run forever.
The supervise program
supervise starts and monitors a service.
Interface
supervise service
supervise switches to the directory named service and starts ./run. It restarts ./run if ./run exits. It pauses for a second before starting ./run, so that it
does not loop too quickly if ./run exits immediately.
If the file service/down exists, supervise does not start ./run immediately. You can use svc to start ./run and to give other commands to supervise.
supervise maintains status information in a binary format inside the directory service/supervise, which must be writable to supervise. The status
information can be read by svstat.
supervise may exit immediately after startup if it cannot find the files it needs in service or if another copy of supervise is already running in service.
Once supervise is successfully running, it will not exit unless it is killed or specifically asked to exit. You can use svok to check whether supervise is
successfully running. You can use svscan to reliably start a collection of supervise processes.
Starting in version 0.70: supervise pauses for a second after starting ./run.
Advice on creating ./run
Typically ./run is a shell script. For example:
#!/bin/sh
exec clockspeed
The exec here tells sh to replace itself with clockspeed. This lets you use svc to send signals directly to clockspeed.
Note that the service should not run in the background:
#!/bin/sh
# will be repeatedly restarted by supervise
exec clockspeed &
You can use fghack to let supervise monitor (but not control) some programs that put themselves into the background:
#!/bin/sh
exec fghack inetd
If you have root privileges, you can use setuidgid to run a service under another account:
#!/bin/sh
exec \
setuidgid qmaill \
multilog t ./main '-*' '+* status: *' =status
It is generally not a good idea to use shell pipelines:
#!/bin/sh
generate-crucial-data | save-crucial-data
If save-crucial-data fails to start up, any data already written to the pipe by generate-crucial-data will be discarded. You can use svscan to reliably
start a pipeline of supervise processes, with
#!/bin/sh
exec generate-crucial-data
in ./run and
#!/bin/sh
exec save-crucial-data
in ./log/run.
Advice on changing ./run
supervise may restart ./run at any moment if ./run suddenly dies, so it is not safe to edit ./run in place while the service is up. Here are three solutions:
Edit ./run.new and atomically rename ./run.new to ./run. Then use svc -t to send a TERM signal to the service; supervise will start the new
./run after the service exits.
Use svc -d to send a TERM signal to the service and to tell supervise not to restart the service. Edit ./run. Use svc -u to tell supervise to restart
the service.
Use svc -o to tell supervise not to restart the service. Edit ./run. Use svc -tu to send a TERM signal to the service and to tell supervise to
restart the service.
Note that some services, including anything using fghack, cannot be controlled with signals from supervise, and have to be brought down in other ways.
Sometimes data is piped to supervise to be processed by ./run. Beware that many programs will discard unprocessed input data when they receive a TERM
signal. The multilog program is specially designed to process all data it has read before it exits.
The svok program
svok checks whether supervise is running.
Interface
svok service
svok checks whether supervise is successfully running in the directory named service. It silently exits 0 if supervise is successfully running. It silently
exits 100 if supervise is not successfully running.
The fghack program
fghack is an anti-backgrounding tool.
Interface
fghack child
fghack runs child with many extra descriptors writing to a pipe. fghack reads and discards any data written to the pipe. After child has exited and the pipe
has been closed, fghack exits.
fghack is designed to allow supervise to monitor child even if child is a silly daemon that insists on putting itself into the background. Normally fghack will
not exit until all child's descendants have exited, since child's descendants will inherit the open pipe from child. However, fghack will exit early if child
goes out of its way to close extra descriptors. (Some programs close most descriptors but leave stdin open, even though they do not use stdin; so you can try
fghack child <&-
from /bin/sh.)
The multilog program
multilog reads a sequence of lines from stdin and appends selected lines to any number of logs.
Interface
multilog script
script consists of any number of arguments. Each argument specifies one action. The actions are carried out in order for each line of input. Note that actions
may contain shell metacharacters that need to be quoted when multilog is run from a shell.
multilog exits 0 when it sees the end of stdin. If stdin has a partial final line then multilog inserts a final newline.
multilog writes a message to stderr and exits 111, without reading any input, if it runs out of memory or if another multilog process is writing to one of the
same automatically rotated logs.
If multilog has trouble writing to disk after it starts reading input, it writes a message to stderr, pauses, and tries again, without losing any data. Note that
this may block any program feeding input to multilog.
If multilog receives a TERM signal, it will read and process data until the next newline, and then exit, leaving stdin at the first byte of data it has not
processed.
Selecting lines
Each line is initially selected. The action
-pattern
deselects the line if pattern matches the line. The action
+pattern
selects the line if pattern matches the line.
pattern is a string of stars and non-stars. It matches any concatenation of strings matched by all the stars and non-stars in the same order. A non-star
matches itself. A star before the end of pattern matches any string that does not include the next character in pattern. A star at the end of pattern
matches any string.
For example, the action
+hello
selects hello. It does not select hello world.
The action
-named[*]: Cleaned cache *
deselects named[135]: Cleaned cache of 3121 RRs. The first star matches any string that does not include a right bracket.
The action
-*
deselects every line.
To save memory, multilog actually checks pattern against only the first 1000 characters of each line.
Alerts
The action
e
prints (the first 200 bytes of) each selected line to stderr.
Status files
The action
=file
replaces the contents of file with (the first 1000 bytes of) each selected line, padded with newlines to 1001 bytes. There is no protection of file against
power outages.
For example, the sequence of actions
-*
+STAT*
=log/status
maintains log/status as a copy of the most recent line starting with STAT.
Timestamping
The action
t
inserts an @, a precise timestamp, and a space in front of each line, using the same format as tai64n. This is required to be the first action. Patterns apply to
the line after the timestamp is inserted.
You can use tai64nlocal to convert these timestamps to human-readable form.
Automatically rotated logs
If dir starts with a dot or slash then the action
dir
appends each selected line to a log named dir. If dir does not exist, multilog creates it.
The log format is as follows. dir is a directory containing some number of old log files, a log file named current, and other files for multilog to keep track of
its actions. Each old log file has a name beginning with @, continuing with a precise timestamp showing when the file was finished, and ending with one of
the following codes:
.s: This file is completely processed and safely written to disk.
.u: This file was being created at the moment of an outage. It may have been truncated and has not been processed.
Beware that NFS, async filesystems, and softupdates filesystems may discard files that were not safely written to disk before an outage.
While multilog is running, current has mode 644. If multilog sees the end of stdin, it writes current safely to disk, and sets the mode of current to 744.
When it restarts, it sets the mode of current back to 644 and continues writing new lines.
When multilog decides that current is big enough, it writes current safely to disk, sets the mode of current to 744, and renames current as an old log
file.
The action
ssize
sets the maximum file size for subsequent dir actions. multilog will decide that current is big enough if current has size bytes. (multilog will also
decide that current is big enough if it sees a newline within 2000 bytes of the maximum file size; it tries to finish log files at line boundaries.) size must be
between 4096 and 16777215. The default maximum file size is 99999.
The action
nnum
sets the number of log files for subsequent dir actions. After renaming current, if multilog sees num or more old log files, it removes the old log file with
the smallest timestamp. num must be at least 2. The default number of log files is 10.
The action
!processor
sets a processor for subsequent dir actions. multilog will feed current through processor and save the output as an old log file instead of current.
multilog will also save any output that processor writes to descriptor 5, and make that output readable on descriptor 4 when it runs processor on the next
log file. For reliability, processor must exit nonzero if it has any trouble creating its output; multilog will then run it again. Note that running processor may
block any program feeding input to multilog.
The tai64n program
tai64n puts a precise timestamp on each line.
Interface
tai64n reads lines from stdin. For each line, it writes
1.an @,
2.a precise timestamp,
3.a space, and
4.a copy of the input line
to stdout. The timestamp indicates the moment that tai64n read the first character of the line.
tai64n exits 0 when it sees end of input. It exits 111 without an error message if it has trouble reading stdin or writing stdout.
tai64n does not allocate any memory after it starts.
Timestamps
Timestamps used by tai64n are 12-byte TAI64N labels in external TAI64N format, printed as 24 lowercase hexadecimal characters. You can use
tai64nlocal to convert the timestamps to a human-readable format.
For example, the timestamp 4000000037c219bf2ef02e94 refers to the nanosecond beginning exactly 935467455.787492500 seconds after the beginning of
1970 TAI; 37c219bf hexadecimal is 935467455, and 2ef02e94 hexadecimal is 787492500.
The current implementation of tai64n relies on the UNIX gettimeofday library routine to return the current time as the number of TAI seconds since
1970-01-01 00:00:10 TAI. Beware that most gettimeofday implementations are not Y2038-compliant. Furthermore, most clocks are not set accurately.
The tai64nlocal program
tai64nlocal converts precise TAI64N timestamps to a human-readable format.
Interface
tai64nlocal reads lines from stdin. If a line does not begin with @, tai64nlocal writes it to stdout without change. If a line begins with @, tai64nlocal
looks for a timestamp after the @, in the format printed by tai64n, and writes the line to stdout with the timestamp converted to local time in ISO format:
YYYY-MM-DD HH:MM:SS.SSSSSSSSS.
For example, in the US/Pacific time zone, the input line
@4000000037c219bf2ef02e94 mark
should be printed as
1999-08-23 21:03:43.787492500 mark
Beware, however, that the current implementation of tai64nlocal relies on the UNIX localtime library routine to find the local time. Some localtime
implementations use a broken time scale that does not account for leap seconds. On systems that use the Olson tz library (with an up-to-date leap-second
table), you can fix this problem by setting your time zone to, e.g, right/US/Pacific instead of US/Pacific.
Beware also that most localtime implementations are not Y2038-compliant.
tai64nlocal exits 0 when it sees end of input. It exits 111 without an error message if it has trouble reading stdin or writing stdout.
tai64nlocal does not allocate any memory after it starts, except possibly inside localtime.
The setuidgid program
setuidgid runs another program under a specified account's uid and gid.
Interface
setuidgid account child
account is a single argument. child consists of one or more arguments.
setuidgid sets its uid and gid to account's uid and gid, removing all supplementary groups. It then runs child.
setuidgid exits 111 if it cannot find a UNIX account named account, if it cannot setgid, if it cannot setuid, or if it cannot run child. Otherwise its exit code
is the same as that of child.
setuidgid cannot be run by anyone other than root.
The envuidgid program
envuidgid runs another program with environment variables indicating a specified account's uid and gid.
Interface
envuidgid account child
account is a single argument. child consists of one or more arguments.
envuidgid sets $UID to account's uid and $GID to account's gid. It then runs child.
envuidgid exits 111 if it cannot find a UNIX account named account, if it runs out of memory for environment variables, or if it cannot run child. Otherwise
its exit code is the same as that of child.
The envdir program
envdir runs another program with environment modified according to files in a specified directory.
Interface
envdir d child
d is a single argument. child consists of one or more arguments.
envdir sets various environment variables as specified by files in the directory named d. It then runs child.
If d contains a file named s whose first line is t, envdir removes an environment variable named s if one exists, and then adds an environment variable
named s with value t. The name s must not contain =. Spaces and tabs at the end of t are removed. Nulls in t are changed to newlines in the environment
variable.
If the file s is completely empty (0 bytes long), envdir removes an environment variable named s if one exists, without adding a new variable.
envdir exits 111 if it has trouble reading d, if it runs out of memory for environment variables, or if it cannot run child. Otherwise its exit code is the same as
that of child.
The softlimit program
softlimit runs another program with new resource limits.
Interface
softlimit opts child
opts is a series of getopt-style options. child consists of one or more arguments.
softlimit sets soft resource limits as specified by opts. It then runs child.
Options
In each of the following options, n may be =, indicating that the soft limit should be set equal to the hard limit.
Options controlling memory use:
-m n: Same as -d n -s n -l n -a n.
-d n: Limit the data segment per process to n bytes.
-s n: Limit the stack segment per process to n bytes.
-l n: Limit the locked physical pages per process to n bytes. This option has no effect on some operating systems.
-a n: Limit the total of all segments per process to n bytes. This option has no effect on some operating systems.
-o n: Limit the number of open file descriptors per process to n. This option has no effect on some operating systems.
-p n: Limit the number of processes per uid to n.
Options controlling file sizes:
-f n: Limit output file sizes to n bytes.
-c n: Limit core file sizes to n bytes.
Efficiency options:
-r n: Limit the resident set size to n bytes. This limit is not enforced unless physical memory is full.
-t n: Limit the CPU time to n seconds. This limit is not enforced except that the process receives a SIGXCPU signal after n seconds.
The setlock program
setlock runs another program with a file locked.
Interface
setlock opts fn child
opts is a series of getopt-style options. fn is a single argument. child consists of one or more arguments.
setlock opens fn for writing (creating it if it does not exist), obtains an exclusive lock on it, and runs child.
Normally the lock disappears when child exits.
Here's the complete story: child is given a descriptor for a locked ofile pointing to the disk file named fn. The lock disappears when this ofile is
closed by all the processes that have descriptors for it or
explicitly unlocked.
Options
-n: No delay. If fn is locked by another process, setlock gives up.
-N: (Default.) Delay. If fn is locked by another process, setlock waits until it can obtain a new lock.
-x: If fn cannot be opened (or created) or locked, setlock exits zero.
-X: (Default.) If fn cannot be opened (or created) or locked, setlock prints an error message and exits nonzero.
Blah Blah
Blah Blah
Dnscache
The dnscache program
dnscache is a local DNS cache. It accepts recursive DNS queries from local clients such as web browsers and mail transfer agents. It collects responses
from remote DNS servers. It caches the responses to save time later.
This is a reference page. For tutorial information, see the FAQ lists for local and external caches.
Configuration
Normally dnscache is set up by the dnscache-conf program.
dnscache runs chrooted in the directory specified by the $ROOT environment variable, under the uid and gid specified by the $UID and $GID environment
variables.
dnscache listens for incoming UDP packets and TCP connections addressed to port 53 of $IP. Typically $IP is 127.0.0.1, but it can also be an externally
accessible IP address. dnscache accepts a packet or connection from IP address 1.2.3.4 if it sees a file named ip/1.2.3.4 or ip/1.2.3 or ip/1.2 or ip/1.
dnscache sends outgoing packets from high ports of $IPSEND. Typically $IPSEND is 0.0.0.0, meaning the machine's primary IP address.
dnscache reads a seed, up to 128 bytes, from standard input, and passes the seed to dns_random_init.
dnscache reads a list of dotted-decimal root server IP addresses, one address per line, from servers/@. It also scans the servers directory for server IP
addresses for other domains. If there are addresses listed in servers/moon.af.mil, for example, then dnscache will send queries for anything.moon.af.mil
to those addresses, and will not cache records for anything.moon.af.mil from outside servers such as the root servers.
Versions 1.03 and above: If $FORWARDONLY is set, dnscache treats servers/@ as a list of IP addresses for other caches, not root servers. It forwards queries
to those caches. It does not contact the root servers, or any other DNS servers, directly.
Memory use
dnscache uses a fixed-size table, under 256K, to keep track of as many as 200 simultaneous UDP queries and 20 simultaneous TCP connections. It also
dynamically allocates memory, usually just a few bytes but occasionally much more, for each active query. If it runs out of memory handling a query, it
discards that query.
dnscache asks the operating system to reserve a 128K buffer for bursts of incoming UDP queries. In versions 1.03 and above, if a new UDP query arrives
when dnscache is already handling 200 simultaneous UDP queries, dnscache drops the oldest query. If a new TCP connection arrives when dnscache is
already handling 20 simultaneous TCP connections, dnscache drops the oldest connection.
dnscache uses a fixed-size cache, as controlled by the $CACHESIZE environment variable. Roughly 5% of the cache is used for a hash table. The rest is used
for cache entries (including 8-byte Y2038-compliant expiration times):
A sets. 22 bytes plus 4 bytes per address plus the length of the owner name.
NS sets or PTR sets or CNAME sets. 22 bytes plus the length of the owner name and all the data names.
MX sets. 22 bytes plus 2 bytes per MX plus the length of all the names.
Other record sets. 22 bytes plus 2 bytes per record plus the length of all the data strings plus the length of the owner name.
Nonexistent domain or server failure. 22 bytes plus the length of the owner name.
Sets larger than 8192 bytes are not cached.
dnscache does not exit when it runs out of space in its cache; it simply removes the oldest entries to make more space.
Resolution and caching policies
dnscache relies on a configured list of root name servers. In contrast, BIND starts from a ``hint file'' listing name servers, and asks those name servers
where the root name servers are.
dnscache does not cache (or pass along) records outside the server's bailiwick; those records could be poisoned. Records for foo.dom, for example, are
accepted only from the root servers, the dom servers, and the foo.dom servers.
dnscache does not bypass its cache to obtain glue from the additional section of a response. In particular, it will not use glue outside the server's bailiwick, or
glue with TTL 0, or glue that violates other caching policies.
dnscache caches records for at most a week. It interprets TTLs above 2147483647 as 0.
dnscache does not cache SOA records. However, it does use SOA TTLs to determine cache times (up to an hour) for zero-record responses and nonexistent
domains.
Responses to DNS clients
dnscache's responses are generally much smaller than BIND's responses. They do not include authority records (NS records of the source name servers and
SOA records for negative answers) or additional records (A records relevant to NS or MX records). When the answer section is truncated by UDP length
limits, it is eliminated entirely.
dnscache tries to prevent local users from snooping on other local users. It discards non-recursive queries; it discards inverse queries; and it discards
zone-transfer requests. If $HIDETTL is set, dnscache always uses a TTL of 0 in its responses. In versions before 1.03, dnscache always uses a TTL of 0 in
its responses.
According to RFC 1035, the AA bit ``specifies that the responding name server is an authority for the domain name in question section.'' dnscache is not an
authority for any domain names. dnscache never sets the AA bit (except in NXDOMAIN responses, as required by RFC 2308, to work around a common
client bug). In contrast, BIND often sets AA for positive responses even when it is not an authority for the domain name.
Special names
dnscache handles localhost internally, giving it an A record of 127.0.0.1.
dnscache handles 1.0.0.127.in-addr.arpa internally, giving it a PTR record of 127.0.0.1.
dnscache handles dotted-decimal domain names internally, giving (e.g.) the domain name 192.48.96.2 an A record of 192.48.96.2
The tinydns program
tinydns is a DNS server. It accepts iterative DNS queries from hosts around the Internet, and responds with locally configured information.
This is a reference page. For tutorial information, see the FAQ list.
Configuration
Normally tinydns is set up by the tinydns-conf program.
tinydns runs chrooted in the directory specified by the $ROOT environment variable, under the uid and gid specified by the $UID and $GID environment
variables.
tinydns listens for incoming UDP packets addressed to port 53 of $IP. It does not listen for TCP queries.
tinydns answers queries as specified by data.cdb, a binary file created by tinydns-data.
Further details
tinydns rejects zone-transfer requests, inverse queries, non-Internet-class queries, truncated packets, and packets that contain anything other than a
single query.
tinydns, like BIND, includes NS records with answers to most queries. This increases DNS packet sizes, but it draws queries away from parent servers,
and reduces the frequency of long DNS delays. With the default tinydns-data cache times, a client that uses a normal record at least once every day will
always have the corresponding NS records cached and will never have to talk to parent servers.
The walldns program
walldns is a reverse DNS wall. It accepts iterative DNS queries for in-addr.arpa domains from hosts around the Internet, and supplies generic responses
that avoid revealing local host information.
For example, walldns provides a PTR record for 4.3.2.1.in-addr.arpa showing 4.3.2.1.in-addr.arpa as the name of IP address 1.2.3.4, and a matching
A record showing 1.2.3.4 as the IP address of 4.3.2.1.in-addr.arpa.
Configuration
Normally walldns is set up by the walldns-conf program.
walldns runs chrooted in the directory specified by the $ROOT environment variable, under the uid and gid specified by the $UID and $GID environment
variables.
walldns listens for incoming UDP packets addressed to port 53 of $IP. It does not listen for TCP queries.
Further details
walldns rejects inverse queries, non-Internet-class queries, truncated packets, packets that contain anything other than a single question, queries for
domains outside in-addr.arpa, and request types other than A, PTR, and *. walldns does not include NS or SOA records with its responses.
walldns uses TTLs slightly over one week.
The axfrdns program
axfrdns is a DNS zone-transfer server. It reads a zone-transfer request in DNS-over-TCP format from its standard input, and responds with locally
configured information.
Configuration
Normally axfrdns is set up by the axfrdns-conf program.
axfrdns runs chrooted in the directory specified by the $ROOT environment variable, under the uid and gid specified by the $UID and $GID environment
variables.
Normally axfrdns runs under tcpserver to handle TCP connections on port 53 of a local IP address. tcpserver is responsible for rejecting connections from
hosts not authorized to perform zone transfers. axfrdns can also run under secure connection tools offering an UCSPI-compliant interface.
axfrdns looks up zone-transfer results in data.cdb, a binary file created by tinydns-data. It also responds to normal client queries, such as SOA queries,
which usually precede zone-transfer requests.
axfrdns allows zone transfers for any zone listed in the $AXFR environment variable. $AXFR is a slash-separated list of domain names. If $AXFR is not set,
axfrdns allows zone transfers for all zones available in data.cdb.
axfrdns aborts if it runs out of memory, or has trouble reading data.cdb, or receives a request larger than 512 bytes, or receives a truncated request, or
receives a zone-transfer request disallowed by $AXFR, or receives a request not answered by data.cdb, or waits 60 seconds with nothing happening.
Further notes on zone transfers
axfrdns provides every record it can find inside the target domain. This may include records in child zones. Some of these records (such as glue inside a child
zone) are essential; others are not. It is up to the client to decide which out-of-zone records to keep.
axfrdns does not provide glue records outside the target domain.
The zone-transfer protocol does not support timestamps. If a record is scheduled to be created in the future, axfrdns does not send it; after the starting time,
the zone-transfer client will continue claiming that the record doesn't exist, until it contacts axfrdns again. Similarly, if a record is scheduled to die in the
future, axfrdns sends it (with a 2-second TTL); after the ending time, the zone-transfer client will continue providing the old record, until it contacts
axfrdns again.
Zone-transfer clients rely on zone serial numbers changing for every zone modification. tinydns-data uses the modification time of the data file as its serial
number for all zones. Do not make more than one modification per second.
BIND's zone-transfer client, named-xfer, converts zone-transfer data to zone-file format. Beware that zone-file format has no generic mechanism to
express records of arbitrary types; named-xfer chokes if it does not recognize a record type used in data.cdb.
Blah Blah
Stichwortverzeichnis
Stichwortverzeichnis