axfr-get 1 user commands djbwares 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-data1. It expects to be run via a program such as tcpclient1 which makes the network connection to the server and sets up UCSPI environment variables. The "zone transfer" mechanism is incapable of carrying all of the information that can be contained in a database source file; not all databases comprising "zones" in the first place. Do not use it to replicate from one axfrdns1/tinydns1 server to another. Use an ordinary remote file copying program such as rsync1; which in addition to copying all of the database records, can moreover do compressed transfers, and more reliable skips of updates based upon file modification timestamps, sizes, and hashes. 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. If the content DNS server only updates the serial number at most once per second, this will cause skipped transfers if multiple (non-batched) modifications are made within a single second. This is not usually possible at human speeds. If the content DNS server has the same serial numbers across all "zones" (as axfrdns1 has, for one) this will erroneously skip the transfer if apex is changed. For better results, use a different data for each apex. For best results, see earlier. 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 tinydns1 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 tinydns1 (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 tinydns1, the wildcard records apply to y.example and anything.y.example except x.y.example specifically. axfr-get rejects explicit NS records with wildcards such as *.example. BIND's handling of multiple IP addresses for a single name are not precisely simulated if there are more than 8 of them. axfr-get was originally part of Daniel J. Bernstein's ucspi-tcp toolset in 1999. Original code and documentation by Daniel J. Bernstein. Documentation modernizations by Jonathan de Boyne Pollard.