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).