idnits 2.17.1 draft-ietf-dnsind-notify-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 88 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 66 has weird spacing: '... Master maste...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date () is 739377 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1035' on line 290 looks like a reference -- Missing reference section? 'IXFR' on line 294 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie (ISC) 3 INTERNET-DRAFT March, 1996 4 6 Updates: RFC 1035 8 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This draft describes the NOTIFY opcode for DNS, by which a master 31 server advises a set of slave servers that the master's data has been 32 changed and that a query should be initiated to discover the new 33 data. 35 1 - Rationale and Scope 37 1.1. Slow propagation of new and changed data in a DNS zone can be due 38 to a zone's relatively long refresh times. Longer refresh times are 39 beneficial in that they reduce load on the master servers, but that 40 benefit comes at the cost of long intervals of incoherence among 41 authority servers whenever the zone is updated. 43 1.2. The DNS NOTIFY transaction allows master servers to inform slave 44 servers when the zone has changed -- an interrupt as opposed to poll 45 model -- which it is hoped will reduce propagation delay while not 46 unduly increasing the masters' load. This specification only allows 47 slaves to be notified of SOA RR changes, but the architechture of NOTIFY 48 is intended to be extensible to other RR types. 50 1.3. This document intentionally gives more definition to the roles of 51 ``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in NS 52 RRs, and the SOA MNAME field. In that sense, this document can be 53 considered an addendum to [RFC1035]. 55 2 - Definitions and Invariants 57 2.1. The following definitions are used in this document: 59 Slave an authoritative server which uses zone transfer to 60 retrieve the zone. All slave servers are named in 61 the NS RRs for the zone. 63 Master any authoritative server configured to be the source 64 of zone transfer for one or more slave servers. 66 Primary Master master server at the root of the zone transfer 67 dependency graph. The primary master is named in the 68 zone's SOA MNAME field and optionally by an NS RR. 69 There is by definition only one primary master server 70 per zone. 72 Stealth like a slave server except not listed in an NS RR for 73 the zone. A stealth server, unless explicitly 74 configured to do otherwise, will set the AA bit in 75 responses and be capable of acting as a master. A 76 stealth server will only be known by other servers if 77 they are given static configuration data indicating 78 its existence. 80 Notify Set set of servers to be notified of changes to some 81 zone. Default is all servers named in the NS RRset, 82 except for any server also named in the SOA MNAME. 83 Some implementations will permit the name server 84 administrator to override this set or add elements to 85 it (such as, for example, stealth servers). 87 2.2. The zone's servers must be organized into a dependency graph such 88 that there is a primary master, and all other servers must use AXFR or 89 IXFR either from the primary master or from some slave which is also a 90 master. No loops are permitted in the AXFR dependency graph. 92 3 - NOTIFY Message 94 3.1. When a master has updated one or more RRs in which slave servers 95 may be interested, the master may send the changed RR's name, class, 96 type, and optionally, new RDATA(s), to each known slave server using a 97 best efforts protocol based on the NOTIFY opcode. 99 3.2. NOTIFY uses the DNS Message Format, although it uses only a subset 100 of the available fields. Fields not otherwise described herein are to 101 be filled with binary zero (0), and implementations must ignore all 102 messages for which this is not the case. 104 3.3. NOTIFY is similar to QUERY in that it has a request message with 105 the header QR flag ``clear'' and a response message with QR ``set''. 106 The response message contains no useful information, but its reception 107 by the master is an indication that the slave has received the NOTIFY 108 and that the master can remove the slave from any retry queue for this 109 NOTIFY event. 111 3.4. The transport protocol used for a NOTIFY transaction will be UDP 112 unless the master has reason to believe that TCP is necessary; for 113 example, if a firewall has been installed between master and slave, and 114 only TCP has been allowed; or, if the changed RR is too large to fit in 115 a UDP/DNS datagram. 117 3.5. If TCP is used, both master and slave must continue to offer name 118 service during the transaction, even when the TCP transaction is not 119 making progress. The NOTIFY request is sent once, and a ``timeout'' is 120 said to have occurred if no NOTIFY response is received within a 121 reasonable interval. 123 3.6. If UDP is used, a master periodically sends a NOTIFY request to a 124 slave until either too many copies have been sent (a ``timeout''), an 125 ICMP message indicating that the port is unreachable, or until a NOTIFY 126 response is received from the slave with a matching query ID, QNAME, IP 127 source address, and UDP source port number. 129 Note: 130 The interval between transmissions, and the total number of 131 retransmissions, should be operational parameters specifiable by the 132 name server administrator, perhaps on a per-zone basis. Reasonable 133 defaults are a 60 second interval (or timeout if using TCP), and a 134 maximum of 5 retransmissions (for UDP). It is considered reasonable 135 to use additive or exponential backoff for the retry interval. 137 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0. 138 If ANCOUNT>0, then the answer section represents an unsecure hint at the 139 new RRset for this . A slave receiving such a hint 140 is free to treat equivilence of this answer section with its local data 141 as a ``no further work needs to be done'' indication. If ANCOUNT=0, or 142 ANCOUNT>0 and the answer section differs from the slave's local data, 143 then the slave should query its known masters to retrieve the new data. 145 3.8. In no case shall the answer section of a NOTIFY request be used to 146 update a slave's local data, or to indicate that a zone transfer needs 147 to be undertaken, or to change the slave's zone refresh timers. Only a 148 ``data present; data same'' condition can lead a slave to act 149 differently if ANCOUNT>0 than it would if ANCOUNT=0. 151 3.9. This version of the NOTIFY specification makes no use of the 152 authority or additional data sections, and so conforming implementations 153 should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a 154 future revision of this specification may define a backwards compatible 155 use for either or both of these sections, current implementations must 156 ignore these sections, but not the entire message, if AUCOUNT>0 and/or 157 ADCOUNT>0. 159 3.10. If a slave receives a NOTIFY request from a host that is not a 160 known master for the zone containing the QNAME, it should ignore the 161 request and produce an error message in its operations log. 163 Note: 164 This implies that slaves of a multihomed master must either know 165 their master by the ``closest'' of the master's interface addresses, 166 or must know all of the master's interface addresses. Otherwise, a 167 valid NOTIFY request might come from an address that is not on the 168 slave's state list of masters for the zone, which would be an error. 170 3.11. The only defined NOTIFY event at this time is that the SOA RR has 171 changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the 172 slave should behave as though the zone given in the QNAME had reached 173 its REFRESH interval (see [RFC1035]), i.e., it should query its masters 174 for the SOA of the zone given in the NOTIFY QNAME, and check the answer 175 to see if the SOA SERIAL has been incremented since the last time the 176 zone was fetched. If so, a zone transfer (either AXFR or IXFR) should 177 be initiated. 179 Note: 180 Because a deep server dependency graph may have multiple paths from 181 the primary master to any given slave, it is possible that a slave 182 will receive a NOTIFY from one of its known masters even though the 183 rest of its known masters have not yet updated their copies of the 184 zone. Therefore, when issuing a QUERY for the zone's SOA, the query 185 should be directed at the known master who was the source of the 186 NOTIFY event, and not at any of the other known masters. This 187 represents a departure from [RFC1035], which specifies that upon 188 expiry of the SOA REFRESH interval, all known masters should be 189 queried in turn. 191 4 - Details and Examples 193 4.1. Retaining query state information across host reboots is optional, 194 but it is reasonable to simply execute an SOA NOTIFY transaction on each 195 authority zone when a server first starts. 197 4.2. Each slave is likely to receive several copies of the same NOTIFY 198 request: One from the primary master, and one from each other slave as 199 that slave transfers the new zone and notifies its potential peers. The 200 NOTIFY protocol supports this multiplicity by requiring that NOTIFY be 201 sent by a slave/master only AFTER it has updated the SOA RR or has 202 determined that no update is necessary, which in practice means after a 203 successful zone transfer. Thus, barring delivery reordering, the last 204 NOTIFY any slave receives will be the one indicating the latest change. 205 Since a slave always requests SOAs and AXFR/IXFRs only from its known 206 masters, it will have an opportunity to retry its QUERY for the SOA 207 after each of its masters have completed each zone update. 209 4.3. If a master server seeks to avoid causing a large number of 210 simultaneous outbound zone transfers, it may delay for an arbitrary 211 length of time before sending a NOTIFY message to any given slave. It 212 is expected that the time will be chosen at random, so that each slave 213 will begin its transfer at a unique time. The delay shall not in any 214 case be longer than the SOA REFRESH time. 216 Note: 217 This delay should be a parameter that each primary master name server 218 can specify, perhaps on a per-zone basis. Random delays of between 219 30 and 60 seconds would seem adequate if the servers share a LAN and 220 the zones are of moderate size. 222 4.4. A slave which receives a valid NOTIFY should defer action on any 223 subsequent NOTIFY with the same until it has 224 completed the transaction begun by the first NOTIFY. This duplicate 225 rejection is necessary to avoid having multiple notifications lead to 226 pummeling the master server. 228 4.5 - Zone has Updated on Primary Master 230 Primary master sends a NOTIFY request to all servers named in Notify 231 Set. The NOTIFY request has the following characteristics: 233 query ID: (new) 234 op: NOTIFY (4) 235 resp: NOERROR 236 flags: AA 237 qcount: 1 238 qname: (zone name) 239 qclass: (zone class) 240 qtype: T_SOA 242 4.6 - Zone has Updated on a Slave that is also a Master 244 As above in 4.5, except that this server's Notify Set may be different 245 from the Primary Master's due to optional static specification of local 246 stealth servers. 248 4.7 - Slave Receives a NOTIFY Request from a Master 250 When a slave server receives a NOTIFY request from one of its locally 251 designated masters for the zone enclosing the given QNAME, with 252 QTYPE=SOA and QR=0, it should enter the state it would if the zone's 253 refresh timer had expired. It will also send a NOTIFY response back to 254 the NOTIFY request's source, with the following characteristics: 256 query ID: (same) 257 op: NOTIFY (4) 258 resp: NOERROR 259 flags: QR AA 260 qcount: 1 261 qname: (zone name) 262 qclass: (zone class) 263 qtype: T_SOA 265 This is intended to be identical to the NOTIFY request, except that the 266 QR bit is also set. The query ID of the response must be the same as 267 was received in the request. 269 4.8 - Master Receives a NOTIFY Response from Slave 271 When a master server receives a NOTIFY response, it deletes this query 272 from the retry queue, thus completing the ``notification process'' of 273 ``this'' RRset change to ``that'' server. 275 5 - Security Considerations 277 We believe that the NOTIFY operation's only security considerations are: 279 1. That a NOTIFY request with a forged IP/UDP source address can cause a 280 slave to send spurious SOA queries to its masters, leading to a 281 benign denial of service attack if the forged requests are sent very 282 often. 284 2. That TCP spoofing could be used against a slave server given NOTIFY 285 as a means of synchronizing an SOA query and UDP/DNS spoofing as a 286 means of forcing a zone transfer. 288 6 - References 290 [RFC1035] 291 P. Mockapetris, "Domain Names - Implementation and Specification", 292 RFC 1035, USC/Information Sciences Institute, November 1987. 294 [IXFR] 295 M. Ohta, "Incremental Zone Transfer", Internet Draft, February 1996, 296 . 298 7 - Author's Address 300 Paul Vixie 301 Internet Software Consortium 302 Star Route Box 159A 303 Woodside, CA 94062 304 +1 415 747 0204 305