1 Network Working Group P. Vixie
2 Request for Comments: 1996 ISC
3 Updates: 1035 August 1996
4 Category: Standards Track
5
6
7 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
8
9 Status of this Memo
10
11 This document specifies an Internet standards track protocol for the
12 Internet community, and requests discussion and suggestions for
13 improvements. Please refer to the current edition of the "Internet
14 Official Protocol Standards" (STD 1) for the standardization state
15 and status of this protocol. Distribution of this memo is unlimited.
16
17 Abstract
18
19 This memo describes the NOTIFY opcode for DNS, by which a master
20 server advises a set of slave servers that the master's data has been
21 changed and that a query should be initiated to discover the new
22 data.
23
24 1. Rationale and Scope
25
26 1.1. Slow propagation of new and changed data in a DNS zone can be
27 due to a zone's relatively long refresh times. Longer refresh times
28 are beneficial in that they reduce load on the master servers, but
29 that benefit comes at the cost of long intervals of incoherence among
30 authority servers whenever the zone is updated.
31
32 1.2. The DNS NOTIFY transaction allows master servers to inform slave
33 servers when the zone has changed -- an interrupt as opposed to poll
34 model -- which it is hoped will reduce propagation delay while not
35 unduly increasing the masters' load. This specification only allows
36 slaves to be notified of SOA RR changes, but the architechture of
37 NOTIFY is intended to be extensible to other RR types.
38
39 1.3. This document intentionally gives more definition to the roles
40 of "Master," "Slave" and "Stealth" servers, their enumeration in NS
41 RRs, and the SOA MNAME field. In that sense, this document can be
42 considered an addendum to [RFC1035].
43
44
45
46
47
48
49
50
51
52 Vixie Standards Track [Page 1]
53 RFC 1996 DNS NOTIFY August 1996
54
55
56 2. Definitions and Invariants
57
58 2.1. The following definitions are used in this document:
59
60 Slave an authoritative server which uses zone transfer to
61 retrieve the zone. All slave servers are named in
62 the NS RRs for the zone.
63
64 Master any authoritative server configured to be the source
65 of zone transfer for one or more slave servers.
66
67 Primary Master master server at the root of the zone transfer
68 dependency graph. The primary master is named in the
69 zone's SOA MNAME field and optionally by an NS RR.
70 There is by definition only one primary master server
71 per zone.
72
73 Stealth like a slave server except not listed in an NS RR for
74 the zone. A stealth server, unless explicitly
75 configured to do otherwise, will set the AA bit in
76 responses and be capable of acting as a master. A
77 stealth server will only be known by other servers if
78 they are given static configuration data indicating
79 its existence.
80
81 Notify Set set of servers to be notified of changes to some
82 zone. Default is all servers named in the NS RRset,
83 except for any server also named in the SOA MNAME.
84 Some implementations will permit the name server
85 administrator to override this set or add elements to
86 it (such as, for example, stealth servers).
87
88 2.2. The zone's servers must be organized into a dependency graph
89 such that there is a primary master, and all other servers must use
90 AXFR or IXFR either from the primary master or from some slave which
91 is also a master. No loops are permitted in the AXFR dependency
92 graph.
93
94 3. NOTIFY Message
95
96 3.1. When a master has updated one or more RRs in which slave servers
97 may be interested, the master may send the changed RR's name, class,
98 type, and optionally, new RDATA(s), to each known slave server using
99 a best efforts protocol based on the NOTIFY opcode.
100
101 3.2. NOTIFY uses the DNS Message Format, although it uses only a
102 subset of the available fields. Fields not otherwise described
103 herein are to be filled with binary zero (0), and implementations
104
105
106
107 Vixie Standards Track [Page 2]
108 RFC 1996 DNS NOTIFY August 1996
109
110
111 must ignore all messages for which this is not the case.
112
113 3.3. NOTIFY is similar to QUERY in that it has a request message with
114 the header QR flag "clear" and a response message with QR "set". The
115 response message contains no useful information, but its reception by
116 the master is an indication that the slave has received the NOTIFY
117 and that the master can remove the slave from any retry queue for
118 this NOTIFY event.
119
120 3.4. The transport protocol used for a NOTIFY transaction will be UDP
121 unless the master has reason to believe that TCP is necessary; for
122 example, if a firewall has been installed between master and slave,
123 and only TCP has been allowed; or, if the changed RR is too large to
124 fit in a UDP/DNS datagram.
125
126 3.5. If TCP is used, both master and slave must continue to offer
127 name service during the transaction, even when the TCP transaction is
128 not making progress. The NOTIFY request is sent once, and a
129 "timeout" is said to have occurred if no NOTIFY response is received
130 within a reasonable interval.
131
132 3.6. If UDP is used, a master periodically sends a NOTIFY request to
133 a slave until either too many copies have been sent (a "timeout"), an
134 ICMP message indicating that the port is unreachable, or until a
135 NOTIFY response is received from the slave with a matching query ID,
136 QNAME, IP source address, and UDP source port number.
137
138 Note:
139 The interval between transmissions, and the total number of
140 retransmissions, should be operational parameters specifiable by
141 the name server administrator, perhaps on a per-zone basis.
142 Reasonable defaults are a 60 second interval (or timeout if
143 using TCP), and a maximum of 5 retransmissions (for UDP). It is
144 considered reasonable to use additive or exponential backoff for
145 the retry interval.
146
147 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
148 ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
149 unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
150 slave receiving such a hint is free to treat equivilence of this
151 answer section with its local data as a "no further work needs to be
152 done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
153 differs from the slave's local data, then the slave should query its
154 known masters to retrieve the new data.
155
156 3.8. In no case shall the answer section of a NOTIFY request be used
157 to update a slave's local data, or to indicate that a zone transfer
158 needs to be undertaken, or to change the slave's zone refresh timers.
159
160
161
162 Vixie Standards Track [Page 3]
163 RFC 1996 DNS NOTIFY August 1996
164
165
166 Only a "data present; data same" condition can lead a slave to act
167 differently if ANCOUNT>0 than it would if ANCOUNT=0.
168
169 3.9. This version of the NOTIFY specification makes no use of the
170 authority or additional data sections, and so conforming
171 implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
172 requests. Since a future revision of this specification may define a
173 backwards compatible use for either or both of these sections,
174 current implementations must ignore these sections, but not the
175 entire message, if AUCOUNT>0 and/or ADCOUNT>0.
176
177 3.10. If a slave receives a NOTIFY request from a host that is not a
178 known master for the zone containing the QNAME, it should ignore the
179 request and produce an error message in its operations log.
180
181 Note:
182 This implies that slaves of a multihomed master must either know
183 their master by the "closest" of the master's interface
184 addresses, or must know all of the master's interface addresses.
185 Otherwise, a valid NOTIFY request might come from an address
186 that is not on the slave's state list of masters for the zone,
187 which would be an error.
188
189 3.11. The only defined NOTIFY event at this time is that the SOA RR
190 has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA,
191 the slave should behave as though the zone given in the QNAME had
192 reached its REFRESH interval (see [RFC1035]), i.e., it should query
193 its masters for the SOA of the zone given in the NOTIFY QNAME, and
194 check the answer to see if the SOA SERIAL has been incremented since
195 the last time the zone was fetched. If so, a zone transfer (either
196 AXFR or IXFR) should be initiated.
197
198 Note:
199 Because a deep server dependency graph may have multiple paths
200 from the primary master to any given slave, it is possible that
201 a slave will receive a NOTIFY from one of its known masters even
202 though the rest of its known masters have not yet updated their
203 copies of the zone. Therefore, when issuing a QUERY for the
204 zone's SOA, the query should be directed at the known master who
205 was the source of the NOTIFY event, and not at any of the other
206 known masters. This represents a departure from [RFC1035],
207 which specifies that upon expiry of the SOA REFRESH interval,
208 all known masters should be queried in turn.
209
210 3.12. If a NOTIFY request is received by a slave who does not
211 implement the NOTIFY opcode, it will respond with a NOTIMP
212 (unimplemented feature error) message. A master server who receives
213 such a NOTIMP should consider the NOTIFY transaction complete for
214
215
216
217 Vixie Standards Track [Page 4]
218 RFC 1996 DNS NOTIFY August 1996
219
220
221 that slave.
222
223 4. Details and Examples
224
225 4.1. Retaining query state information across host reboots is
226 optional, but it is reasonable to simply execute an SOA NOTIFY
227 transaction on each authority zone when a server first starts.
228
229 4.2. Each slave is likely to receive several copies of the same
230 NOTIFY request: One from the primary master, and one from each other
231 slave as that slave transfers the new zone and notifies its potential
232 peers. The NOTIFY protocol supports this multiplicity by requiring
233 that NOTIFY be sent by a slave/master only AFTER it has updated the
234 SOA RR or has determined that no update is necessary, which in
235 practice means after a successful zone transfer. Thus, barring
236 delivery reordering, the last NOTIFY any slave receives will be the
237 one indicating the latest change. Since a slave always requests SOAs
238 and AXFR/IXFRs only from its known masters, it will have an
239 opportunity to retry its QUERY for the SOA after each of its masters
240 have completed each zone update.
241
242 4.3. If a master server seeks to avoid causing a large number of
243 simultaneous outbound zone transfers, it may delay for an arbitrary
244 length of time before sending a NOTIFY message to any given slave.
245 It is expected that the time will be chosen at random, so that each
246 slave will begin its transfer at a unique time. The delay shall not
247 in any case be longer than the SOA REFRESH time.
248
249 Note:
250 This delay should be a parameter that each primary master name
251 server can specify, perhaps on a per-zone basis. Random delays
252 of between 30 and 60 seconds would seem adequate if the servers
253 share a LAN and the zones are of moderate size.
254
255 4.4. A slave which receives a valid NOTIFY should defer action on any
256 subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
257 completed the transaction begun by the first NOTIFY. This duplicate
258 rejection is necessary to avoid having multiple notifications lead to
259 pummeling the master server.
260
261
262
263
264
265
266
267
268
269
270
271
272 Vixie Standards Track [Page 5]
273 RFC 1996 DNS NOTIFY August 1996
274
275
276 4.5 Zone has Updated on Primary Master
277
278 Primary master sends a NOTIFY request to all servers named in Notify
279 Set. The NOTIFY request has the following characteristics:
280
281 query ID: (new)
282 op: NOTIFY (4)
283 resp: NOERROR
284 flags: AA
285 qcount: 1
286 qname: (zone name)
287 qclass: (zone class)
288 qtype: T_SOA
289
290 4.6 Zone has Updated on a Slave that is also a Master
291
292 As above in 4.5, except that this server's Notify Set may be
293 different from the Primary Master's due to optional static
294 specification of local stealth servers.
295
296 4.7 Slave Receives a NOTIFY Request from a Master
297
298 When a slave server receives a NOTIFY request from one of its locally
299 designated masters for the zone enclosing the given QNAME, with
300 QTYPE=SOA and QR=0, it should enter the state it would if the zone's
301 refresh timer had expired. It will also send a NOTIFY response back
302 to the NOTIFY request's source, with the following characteristics:
303
304 query ID: (same)
305 op: NOTIFY (4)
306 resp: NOERROR
307 flags: QR AA
308 qcount: 1
309 qname: (zone name)
310 qclass: (zone class)
311 qtype: T_SOA
312
313 This is intended to be identical to the NOTIFY request, except that
314 the QR bit is also set. The query ID of the response must be the
315 same as was received in the request.
316
317 4.8 Master Receives a NOTIFY Response from Slave
318
319 When a master server receives a NOTIFY response, it deletes this
320 query from the retry queue, thus completing the "notification
321 process" of "this" RRset change to "that" server.
322
323
324
325
326
327 Vixie Standards Track [Page 6]
328 RFC 1996 DNS NOTIFY August 1996
329
330
331 5. Security Considerations
332
333 We believe that the NOTIFY operation's only security considerations
334 are:
335
336 1. That a NOTIFY request with a forged IP/UDP source address can
337 cause a slave to send spurious SOA queries to its masters,
338 leading to a benign denial of service attack if the forged
339 requests are sent very often.
340
341 2. That TCP spoofing could be used against a slave server given
342 NOTIFY as a means of synchronizing an SOA query and UDP/DNS
343 spoofing as a means of forcing a zone transfer.
344
345 6. References
346
347 [RFC1035]
348 Mockapetris, P., "Domain Names - Implementation and
349 Specification", STD 13, RFC 1035, November 1987.
350
351 [IXFR]
352 Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
353
354 7. Author's Address
355
356 Paul Vixie
357 Internet Software Consortium
358 Star Route Box 159A
359 Woodside, CA 94062
360
361 Phone: +1 415 747 0204
362 EMail: paul@vix.com
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Vixie Standards Track [Page 7]
383
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).