DNS NOTIFY (Zone Change Notification) (DNS and BIND, 4th Edition)

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.

Here's how that works in practice. On our network, terminator.movie.edu is the primary master name server for movie.edu, and wormhole.movie.edu and zardoz.movie.edu are slaves, as shown in Figure 10-1.

Figure 10-1. movie.edu zone transfers

When we edit and reload or dynamically update movie.edu on terminator.movie.edu, terminator.movie.edu sends NOTIFY announcements to wormhole.movie.edu and zardoz.movie.edu. Both slaves respond to terminator.movie.edu, telling it that they've received the notification. They then check to see whether movie.edu's serial number has incremented and, when they find it has, perform a zone transfer. If wormhole.movie.edu and zardoz.movie.edu are running BIND 8.2.3 or BIND 9, after they transfer the new version of the zone, they alsosend NOTIFY announcements to tell each other about the change. But since wormhole.movie.edu isn't zardoz.movie.edu's master name server for movie.edu, and the converse isn't true either, both slaves just ignore each other's NOTIFY announcements.

BIND 8 name servers log information about NOTIFY messages to syslog. Here's what terminator.movie.edulogged after we reloaded movie.edu:

Oct 14 22:56:34 terminator named[18764]: Sent NOTIFY for "movie.edu IN SOA 2000010958" (movie.edu); 2 NS, 2 A
Oct 14 22:56:34 terminator named[18764]: Received NOTIFY answer (AA) from 192.249.249.1 for "movie.edu IN SOA"
Oct 14 22:56:34 terminator named[18764]: Received NOTIFY answer (AA) from 192.249.249.9 for "movie.edu IN SOA"

The first message shows us the NOTIFY announcement that terminator.movie.edu sent, informing the two slaves (2 NS ) that the serial number of movie.edu is now 2000010958. The next two lines show the slave name servers confirming their receipt of the notification. (BIND 9 name servers don't usually log NOTIFY activity.)

Let's also look at a more complicated zone transfer scheme. Here, a is the primary master name server for the zone and b 's master server, but b is c 's master server. Moreover, b has two network interfaces. This setup is shown in Figure 10-2.

Figure 10-2. Complex zone transfer example

In this scenario, a notifies both b and c after the zone is updated. Then, b checks to see whether the zone's serial number has incremented and initiates a zone transfer. However, c ignores a 's NOTIFY announcement because a is not c 's configured master name server (b is). If b is running BIND 8.2.3 or BIND 9 or is explicitly configured to notify c, then after b 's zone transfer completes, it sendsa NOTIFY announcement to c, which prompts c to check the serial number b holds for the zone. If c is also running BIND 8.2.3 or BIND 9, it sends b a NOTIFY announcement after its zone transfer finishes, which b, naturally, ignores.

Note also that if there's any possibility that c will receive a NOTIFY announcement from b 's other network interface, c must be configured with both network interfaces' addresses in the zone's masters substatement, or else c will ignore NOTIFY announcements from the unknown interface.

BIND 4 slave name servers and other name servers that don't support NOTIFY will respond with a Not Implemented (NOTIMP) error. Note that the Microsoft DNS Server does support DNS NOTIFY.

In both BIND 8 and 9, DNS NOTIFY is on by default, but you can turn NOTIFY off globally with the substatement:

options {
	 notify no;
};

You can also turn NOTIFY on or off for a particular zone. For example, say we know that all the slave name servers for our fx.movie.edu zone are running BIND 4 and therefore don't understand NOTIFY announcements. The zone statement:

zone "fx.movie.edu" {
	type master;
	file "db.fx.movie.edu";
	notify no;
};

avoids sending useless NOTIFY announcements to the slaves for fx.movie.edu. A zone-specific NOTIFY setting overrides any global setting for that zone. Unfortunately, neither BIND 8 nor BIND 9 allows you to turn off NOTIFY announcements on a server-by-server basis.

BIND 8 and 9 even have a provision for adding servers besides those in your zone's NS records to your "NOTIFY list." For example, you may have one or more unregistered slave name servers (described in Chapter 8, "Growing Your Domain") and you'd like them to pick up changes to the zone quickly. Or you may have an older BIND 8 slave for the zone that is the master server for another slave and needs to send NOTIFY messages to the slave.

To add a server to your NOTIFY list, use the also-notify substatement of the zone statement:

zone "fx.movie.edu" {
	type slave;
	file "bak.fx.movie.edu";
	notify yes;
	also-notify { 15.255.152.4; }; // This is a BIND 8 slave, which
                                    // must be explicitly configured
                                    // to notify its slave
};

In BIND 8.2.2 and later name servers, you can specify also-notify as an options substatement as well. This will apply to all zones for which NOTIFY is on (and that don't have their own also-notify substatements).

Beginning in BIND 9.1.0, you can specify explicit as an argument to the notify substatement; this suppresses NOTIFY messages to all name servers except those in the also-notify list. You can also use the allow-notify substatement to tell your name server to accept NOTIFY messages from name servers other than just the configured master name servers for a zone:

options {
	allow-notify { 192.249.249.17; }; // let 192.249.249.17 send NOTIFY msgs
};

As an options substatement, allow-notify affects all slave zones. When specified as a zone substatement, allow-notify overrides any global allow-notify for just that zone.