axfr-get — perform old-style "zone transfer" database replication.
axfr-get {apex} {data} {tmp}
axfr-get is a UCSPI-TCP/UCSPI-SSL client program that copies DNS data from a content DNS server across the network, using the old-style "zone transfer" mechanism. It sends a "zone transfer" request over the network to the server, reads the results back, and saves them in a database source file, the input that is compiled by tinydns-data(1). It expects to be run via a program such as tcpclient(1) which makes the network connection to the server and sets up UCSPI environment variables.
axfr-get performs a zone transfer for domain apex and updates data atomically.
It writes the results to tmp and renames that replacement into place as data when it has completed the "zone transfer", completely and successfully built the data file, and written it to disc.
tmp and data thus must be on the same filesystem.
axfr-get writes the zone serial number as a comment at the top of the data file.
It skips the zone transfer, leaving data alone, if data already exists, data has a serial number matching the zone serial number, and both serial numbers are nonzero.
Zone transfers often include duplicate records. To eliminate them, you should feed the axfr-get results through sort -u before compiling them.
axfr-get discards all records not at or beneath the domain apex.
It accepts records for domain names in child zones, i.e. for domain names beneath delegation points, but since those delegation points are there tinydns(1) will not report those records except as glue.
If you plan to merge the axfr-get results for a domain and a child of the same domain, creating a single database source file encompassing both zones, make sure to eliminate records in the first output that are within the child zone.
axfr-get will accept arbitrarily large zone transfers. To limit the maximum file size to (for example) 1 megabyte, run axfr-get under softlimit -f 1048576 .
axfr-get handles BIND's RFC-1034-violating multiple-answers zone-transfer format.
There are some side effects of the behaviour of tinydns(1) (q.v.) that mean that what is published from a "zone transfer" replica will not appear as in the original:
BIND's handling of wildcards such as *.example is not precisely simulated.
Under BIND, records for *.example do not apply to y.example or anything.y.example if there is a normal record for x.y.example.
With tinydns(1), the wildcard records apply to y.example and anything.y.example except x.y.example.
BIND's handling of multiple IP addresses for a single name are not precisely simulated if there are more than 8 of them.
The "zone transfer" mechanism is incapable of carrying all of the information that can be contained in a database source file. Do not use it to replicate from one axfrdns(1) server to another. Use an ordinary remote file copying program such as rsync(1).