UNIX System Administration Handbook - Evi Nemeth [275]
maintain-ixfr-base true ; # in options section
use-ixfr true ; # in server statement
If you want to change the default names for the transaction log and temporary file used by IXFR, do it in the zone statements with:
ixfr-base "filename" ; # in zone statements
ixfr-tmp-file "filename" ; # in zone statements
In BIND 9, IXFR is the default for any zones configured for dynamic update, and named keeps a transaction log whenever possible. The options provide-ixfr and request-ixfr can be set in the server statements for individual peers. provide-ixfr enables or disables IXFR service for zones for which this server is the master. The request-ixfr option requests IXFRs for zones for which this server is a slave.
provide-ixfr yes ; # in server statement
request-ixfr yes ; # in server statement
BIND cannot cope with a zone being both dynamically updated and edited by hand. BIND 9 provides outgoing IXFR for changes that resulted from dynamic updates or from incoming IXFRs, but not for changes that resulted from edits to the master zone files. This feature will likely be added in a later release.
A lot of work has gone into the IXFR mechanism to ensure that a server crash during an update does not leave the zones with trashed data. An IXFR request to a server that does not support it automatically falls back to the standard AXFR zone transfer.
Dynamic updates
The DNS system is built on the premise that name-to-address mappings are relatively stable and do not change frequently. However, a site that uses DHCP to dynamically assign IP addresses as machines boot and join the network breaks this rule constantly. There are two classical solutions: add generic entries to the DNS database or continually edit the DNS files. For many sites, neither solution is satisfactory.
The first solution should be familiar to anyone who has used a dial-up ISP. The DNS configuration looks something like this:
dhcp-host1.domain. IN A 192.168.0.1
dhcp-host2.domain. IN A 192.168.0.2
Although this is a simple solution, it means that hostnames are permanently associated with particular IP addresses and that computers therefore change hostnames whenever they receive a new IP address. Hostname-based logging or security measures become very difficult in this environment.
The dynamic update feature in recent versions of BIND provides an alternative solution. It allows the DHCP daemon to notify BIND of the address assignments it makes, thus updating the contents of the DNS database on the fly. A shell interface is also provided for making dynamic updates by hand.
Dynamic updates can add, delete, or modify resource records. The granularity at which dynamic updates are regulated is the zone. It’s a bit scary to allow dynamic updates to your site’s entire DNS database, so many sites create a subdomain (perhaps dhcp.site) and allow dynamic updates only within that subdomain.
Dynamic updates to a zone are enabled in named.conf with an allow-update clause. Once a zone has been dynamically updated, you cannot edit it by hand without first stopping BIND so that the current copy of the database can be written out to disk. You can then edit the zone file by hand and restart named. Of course, the original formatting of the zone file will be destroyed (the file will look like those maintained by named for slave servers).
Incremental zone transfers are the default for zones that use dynamic updates, but IXFR cannot handle changes that are made to the zone by editing the master file by hand, even when you stop named, edit the zone file, and restart.
16.13 SECURITY ISSUES
DNS started out as an inherently open system, but it has steadily grown more and more secure—or at least, securable. By default, anyone on the Internet can investigate your domain with individual queries from tools like dig, host, or nslookup. In some cases, they can dump your entire DNS database.
To address such vulnerabilities, BIND now supports various types of access control based on host and network addresses or on