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: firstname.lastname@example.org 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).