10.3. DNS NOTIFY (Zone Change Notification)
Traditionally, BIND slaves have used a polling scheme to determine when they need a zone transfer. The polling interval is called the refresh interval. Other parameters in the zone's SOA record govern other aspects of the polling mechanism.
But with this polling scheme, it can take up to the refresh interval before a slave detects and transfers new zone data from its master name server. That kind of latency could wreak havoc in a dynamically updated environment. Wouldn't it be nice if the primary master name server could tell its slave servers when the information in the zone changed? After all, the primary master name server knows the data has changed; someone reloaded the data, and the server checked the mtime (the Unix file modification time) of all its zone data files to determine which had been changed,[73] or it received and processed a dynamic update. The primary master could send notification right after processing the reload or update instead of waiting for the refresh interval to pass.
[73]Except in the case of a single-zone reload, when the name server checks the mtime of the data file only of the zone being reloaded.
RFC 1996 proposed a mechanism that would allow primary master name servers to notify their slaves of changes to a zone's data. BIND 8 and 9 implement this scheme, which is called DNS NOTIFY.
DNS NOTIFY works like this: when a primary master name server notices that the serial number of a zone has changed, it sends a special announcement to all of the slave name servers for that zone. The primary master name server determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.
When does the name server notice a change? Restarting a primary master name server causes it to notify all of its slaves of the current serial number of all of its zones because the primary master has no way of knowing whether its zone data files were edited before it started. Reloading one or more zones with new serial numbers causes a name server to notify the slaves of those zones. And a dynamic update that causes a zone's serial number to increment also causes notification.
The special NOTIFY announcement is identified by its opcode in the DNS header. The opcode for most queries is QUERY. NOTIFY messages, including announcements and responses, have a special opcode, NOTIFY (duh). Other than that, NOTIFY messages look very much like queries for the SOA record for a zone: they specify the domain name of the zone whose serial number has changed, its class, and a type of SOA. The authoritative answer bit is also set.
When a slave receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.
Why doesn't the slave simply take the master's word that the zone has changed? It's possible that a miscreant could forge NOTIFY announcements to slaves, causing lots of unnecessary zone transfers and amounting to a denial-of-service attack against a master name server.
If the slave actually transfers the zone, RFC 1996 says that it should issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave name servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master (they use another slave as their master). However, while BIND 8.2.3 and BIND 9 implement this, earlier versions of BIND 8 don't. Older BIND 8 slaves don't send NOTIFY messages unless explicitly configured to do so.