Many institutions that implement a DNS system to serve a communitity of users of moderate size would appreciate the ability to have a fast propagating DNS. However, to have low-latency in updates, one needs to have TTLs set to relatively low values, otherwise at most, a whole TTL period must pass before the change is picked up automatically by secondary DNS servers. This is in fact the main motivation for wanting to provide a NOTIFY protocol. Short TTL values suffer from the problem that all secondary servers must waste considerable amounts of bandwidth and processing time performing regular polls for new data. This can be especially expensive in environments where updates to the database are actually very infrequent, but need to be propagated very quickly and so a short TTL must be used.
The DNS NOTIFY transaction allows master servers to inform slave and secondary servers when the zone has changed. This effectively turns the DNS model into a "push" method rather than an on-demand "pull" model. Through this manner, it is then feasible to specify more moderate TTL values that do not require as much wasted network and cpu activity.
NOTIFY is similar to QUERY in that it has a request message with the header QR flag "clear" and a response message with QR "set". The response message contains no useful information, but its reception by the master is an indication that the slave has received the NOTIFY and that the master can remove the slave from any retry queue for this NOTIFY event.
The transport protocol used for a NOTIFY transaction will be UDP unless the master has reason to believe that TCP is necessary; for example, if a firewall has been installed between master and slave, and only TCP has been allowed; or, if the changed RR is too large to fit in a UDP/DNS datagram.
The only defined NOTIFY event at this time is that the SOA RR has changed.
If a slave receives a NOTIFY request from a host that is not a known master for the zone containing the QNAME, it should ignore the request and produce an error message in its operations log. Upon completion of a NOTIFY transaction, it should query its masters for the SOA of the zone given in the NOTIFY QNAME, and check the answer to see if the SOA SERIAL has been incremented since the last time the zone was fetched. If so, a zone transfer (either AXFR or IXFR) should be initiated.
When a master server receives a NOTIFY response, it deletes this query from the retry queue, thus completing the "notification process" of "this" RRset change to "that" server.
The security considerations for the NOTIFY request are relatively minor impact since they only notify servers of the potential availability of a new update to the domain records. In the worst case, a NOTIFY attack could be used to overwhelm a server into doing an unnecessary number of update checks to the master.
Additionally, although the ability to depend on NOTIFY for enforced update propagation when zone file changes are made, it does not eliminate the need for DNS adminitrators to choose reasonable TTL values. DNS hosts that are not registered secondary machines may continue to cache resolved values to as long as the TTL value specifies, since only the secondary servers will receive the NOTIFY messages and know that a newer update of the zone file is available. External DNS machines still caching results of a lookup will continue to rely on the cached value until the TTL expires.
The primary document describing the DNS Change mechanism is DNS Change Notification (RFC 1996).
Recent versions of BIND 8 include the ability for a primary DNS server to send a change notification to secondary DNS servers indicating that a change to the master's DNS zone file has occurred and that an update should be performed. This method of alerting is enabled when BIND is compiled with a special compile-time option.