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, 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.
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.
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.
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) 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.
|
