How to update zone files ?

Update Zone files

The initial design of DNS allowed for changes to be propagated using Zone Transfer (AXFR) but the world of the Internet was simpler and more sedate in those days (1987). The desire to speed up the process of zone update propagation while minimising resources used has resulted in a mumber of changes to this aspect of DNS design and implementation from simple - but effective - tinkering such as Incremental Zone Transfer (IXFR) and Notify messages to the concept of Dynamic Updates which have significant security consequences if not properly implemented.
Warning: While zone transfers are generally essential for the operation of DNS systems they are also a source of threat. A slave DNS can become poisoned if it accepts zone updates from a malicious source. Care should be taken during configuration to ensure that, as a minimum, the 'slave' will only accept transfers from known sources. The example configurations provide these minimum precautions. Security Overview outlines some of the potential threats involved.

---

Full Zone Update (AXFR)
The original DNS specifications (RFC 1034 & RFC 1035) envisaged that slave (or secondary) DNS servers would 'poll' the 'master'. The time between such 'polling' is determined by the REFRESH value on the domain's SOA Resource Record.
The polling process is accomplished by the 'slave' sending a query to the 'master' and requesting the latest SOA record. If the SERIAL number of this record is different from the current one maintained by the 'slave' a zone transfer (AXFR) is requested. This is why it is vital to very disciplined about updating the SOA serial number every time anything changes in ANY of the zone records.
Zone transfers are always carried out using TCP on port 53 whereas normal DNS query operations use UDP on port 53.

Incremental Zone Update (IXFR)

Transferring very large zone files can take a long time and waste bandwidth and other resources. This is especially wasteful if only a single record has been changed! RFC 1995 introduced Incremental Zone Transfers (IXFR) which as the name suggests allows the 'slave' and 'master' to transfer only those records that have changed.
The process works as for AXFR. The 'slave' sends a query for the domain's SOA Resource Record every REFRESH interval. If the SERIAL value of the SOA record has changed the 'slave' requests a Zone Transfer and indicates whether or not it is capable of accepting an Incremental Transfer (IXFR). If both 'master' and 'slave' support the feature an Incremental Transfer (IXFR) takes place otherwise a Full Zone Transfer (AXFR) takes place. Incremental Zone transfers use TCP on port 53 whereas normal DNS queries operations use UDP on port 53.
The default mode for BIND when acting as a 'slave' is to use IXFR unless it is configured not to using the request-ixfr parameter in the server or options section of the named.conf file.
The default mode for BIND when acting as a 'master' is to use IXFR only when the zone is dynamic.The use of IXFR is controlled using the provide-ixfr parameter in the server or options section of the named.conf file.

Notify (NOTIFY)

RFC 1912 recommends a REFRESH interval of up to 12 hours on the REFRESH interval of an SOA Resource Record. This means that changes to the 'master' DNS may not be visible at the 'slave' DNS for up to 12 hours. In a dynamic environment this may be unacceptable.
RFC 1996 introduced a scheme whereby the master will send a NOTIFY message to the slave DNS systems that a change MAY have occurred in the domain records. The 'slave' on receipt of the NOTIFY will request the latest SOA Resource Record and if the SERIAL value is different will attempt a Zone Transfer using either a full Zone Transfer (AXFR) or an Incremental Transfer (IXFR).
NOTIFY behaviour in BIND is controlled by notify, also-notify and notify-source parameters in the zone or options statements of the named.conf file.

Dynamic Update

The classic method of updating Zone Resource Records is to manually edit the zone file and then stop and start the name server to propagate the changes. When the volume of changes reaches a certain level this can become operationally unacceptable - especially considering that in organisations which handle large numbers of Zone Files, such as service providers, BIND itself can take a long time to restart at it plows through very large numbers of zone statements.
The 'holy grail' of DNS is to provide a method of dynamically changing the DNS records while DNS continues to service requests.
There are two architectural approaches to solving this problem:

1. Allow 'run-time' updating of the Zone Records from an external source/application.
   
2. Directly feed the DNS from a database which can be dynamically updated. BIND provides two APIs to enable this, other DNS implemenations provide embedded database access.
   

RFC 2136 takes the first approach and defines a process where zone records can be updated from an external source. The key limitation in this specification is that a new domain cannot be added dynamically. All other records within an existing zone can be added, changed or deleted. This limitation is also true for both of BIND's APIs as well.
As part of RFC 2136 the term Primary Master was coined to describe the Name Server defined in the SOA Resource Record for the zone. The significance of this term is that when dynamically updating records it is essential to update only one server even though there may be multiple master servers for the zone. In order to solve this problem a 'boss' server must be selected, this 'boss' server (the Primary Master) has no special characteristics other than it is defined as the Name Server in the SOA record and may appear in an allow-update clause to control the update process.
DDNS is normally associated with Secure DNS features such as TSIG – RFC 2845 & TKEY – RFC 2930. Dynamic DNS (DDNS) does not REQUIRE TSIG/TKEY. However by enabling Dynamic DNS you are also opening up the possibility of master zone file corruption or poisoning. Simple IP address protection (acl) can be configured into BIND but this provides - at best - limited protection. For that reason, serious users of Dynamic DNS will always use TSIG/TKEY procedures to authenticate incoming update requests.
In BIND DDNS is defaulted to deny from all hosts. Control of Dynamic Update is provided by the BIND allow-update usable with and without TSIG/TKEY) and update-policy (only usable with TSIG/TKEY) clauses in the zone or options statements of the named.conf file.
There are a number of Open Source tools which will initiate Dynamic DNS updates these include dnsupdate (not the same as DNSUpdate) and nsupdate which is distributed with bind-utils.

Alternative Dynamic DNS Approaches

As noted above the major limitation in the standard Dynamic DNS (RFC 2136) approach is that new domains cannot be created dynamically.
BIND-DLZ takes a much more radical approach and, using a serious patch to BIND, allows replacement of all zone files with a single zone file which defines a database entry. The database support, which includes most of the major databases (MySQL, PostgreSQL, BDB and LDAP among others) allows the addition of new domains as well as changes to pre-existing domains without the need to stop and start BIND. As with all things in life there is a trade-off and performance can drop precipitously. Current work being carried (early 2004) out with a High performance Berkeley DB (BDB) is showing excellent results approaching raw BIND performance.
PowerDNS an authoritative only name server takes a similar approach with its own (non-BIND) code base by referring all queries to the database back-end and thereby allow new domains to be added dynamically.