10.1 DNS NOTIFY (Zone Change Notification)
Traditionally, slaves have used a polling scheme to determine when they need a zone transfer. The polling interval is called the refresh time . Other parameters in the zone's SOA record govern other aspects of the polling mechanism.
Wouldn't it be nice if the primary master name server could tell its slave servers when the information in a zone changed? After all, the primary master name server knows the data has changed: every time a zone is changed with the DNS console, the DNS console notifies the server, which immediately changes the zone in its memory. The primary's notification can come soon after the actual modification instead of waiting for the refresh interval to expire.
RFC 1996 proposed a mechanism that allowed primary master servers to notify their slaves of changes to a zone's data. The Microsoft DNS Server implements this scheme, called DNS NOTIFY for short.
DNS NOTIFY works like this: when a primary master name server notices a change to data in a zone, it sends a special notification message to all slave servers for that zone. It uses the list of NS records in the zone to build the list of slave servers for the zone. The primary master removes the NS record corresponding to the name server listed in the first field in the zone's SOA record (which by convention lists the name of the primary master name server for the zone), as well as the local host. Removing those name servers prevents the primary master from sending a notification message to itself.
The special NOTIFY request is identified by its opcode in the query header. The opcode for most queries is QUERY. NOTIFY messages have a special opcode, NOTIFY. Other than that, the request looks much like a query for the SOA record for the zone: it specifies the zone's domain name, class, and a type of SOA.
When a slave receives a NOTIFY request for a zone from one of its configured master name servers, it sends a NOTIFY response. The response tells the master that the slave received the NOTIFY request and to stop sending NOTIFY messages for the zone. Then the slave proceeds just as if the refresh timer had expired : it queries the master server for the SOA record for the zone the master claimed had changed. If the serial number is higher, the slave performs the zone transfer.
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 requests to our slaves, causing lots of unnecessary zone transfers that might amount to a denial-of-service attack against our master server.
If the slave actually transfers the zone, RFC 1996 says that it should issue its own NOTIFY requests to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all the slave servers for the zone itself, since it's possible that some slaves can't communicate directly with the primary master and so use another slave as their master. However, the Microsoft DNS Server doesn't implement this, and Microsoft DNS Server slaves don't send NOTIFY messages unless explicitly configured to do so.
Here's how this process works in practice: on our network, terminator.movie.edu is the primary master 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 transfer example
When we update movie.edu on terminator , terminator sends NOTIFY messages to wormhole and zardoz . Both slaves check to see whether movie.edu 's serial number has been incremented and, if they find it has, perform a zone transfer.
Let's also look at a more complicated zone transfer scheme. In Figure 10-2, 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.
Figure 10-2. Complex zone transfer example
In this scenario, a notifies both b and c after the zone is updated. b checks to see whether the zone's serial number has been incremented and initiates a zone transfer. However, c ignores a 's NOTIFY message because a is not c 's configured master name server ( b is). If b is explicitly configured to notify c , after b 's zone transfer completes it sends c a NOTIFY message, which prompts c to check the serial number b holds for the zone.
Older BIND slave name servers, and other name servers that don't support NOTIFY, respond with a "Not Implemented" (NOTIMP) error, wait until their refresh timers expire, and then transfer the zone. The Microsoft DNS Server just ignores the NOTIMP error.
NOTIFY is controlled on a zone-by-zone basis and is enabled by default for every zone. The controls for NOTIFY are somewhat hidden: highlight a zone in DNS console's left pane, select Action Properties , and choose the Zone Transfers tab of the zone properties window, which produces a window like the one shown in Figure 10-3.
Figure 10-3. Zone transfer configuration for movie.edu
Figure 10-4. NOTIFY configuration for movie.edu
Select the Notify... button to open the window shown in Figure 10-4, which illustrates the NOTIFY configuration for the movie.edu zone on the zone's primary, terminator . You have two choices for configuring which servers get NOTIFY messages for a zone. The first is to check Servers listed on the Name Servers tab , which lets the server decide based on the name servers listed in the zone's NS records. (The Name Servers tab of the zone properties window simply shows the name servers listed in the zone's NS records.) The second choice is to specify exactly which slave servers should receive NOTIFY messages. This option is required if you have slave servers not listed in the zone's NS records: such slaves are effectively hidden, and the only way the primary master knows to send NOTIFY messages to them is if you tell it to.