Internet Area P. Vixie DNSIND Working Group Vixie Enterprises 24 March 1995 Updates: RFC 1035 Notify: a mechanism for prompt notification of authority zone changes Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as `work in progress.' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This draft describes a new DNS opcode, NOTIFY, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. 0. Rationale and Scope Slow propagation of new and changed data in a DNS zone can be due to a zone's relatively long refresh times. Longer refresh times are beneficial in that they reduce load on the master servers, but that benefit comes at the cost of having changes not become visible to DNS clients until a sometimes inconvenient interval has elapsed. The Notify DNS message allows master servers to inform slave servers when data have changed, an interrupt as opposed to poll model, which it is hoped will reduce propagation delay while not unduly increasing the masters' load. This document defines a new DNS opcode called NOTIFY whose numeric value is four (4). All fields not otherwise specified must contain Paul Vixie [Page 1] - 2 - 24 March 1995 binary zero, and implementations must ignore any request or response packets where this is not the case. This document intentionally gives more definition to the roles of DNS master and slave servers, their enumeration in NS RRs, and the SOA MNAME field. In that sense, this document can be considered an addendum to RFC 1035. 1. NOTIFY Message When a master has updated one or more RRs in which slave servers may be interested, the master may send the changed RR's name, type, and optionally, new RDATA(s), to each known slave server using a best efforts protocol based on the NOTIFY opcode. NOTIFY is similar to QUERY in that it has an initiator packet with QR ``set'' and a response packet with QR ``clear''. The response packet contains no useful information, but its reception by the master is a hint that the slave has received the NOTIFY and that the master can remove the slave from any retry queue for this NOTIFY event. A master repeatedly sends NOTIFY to a slave until either too many copies have been sent (a ``timeout'') or until a NOTIFY-QR is received from the slave with a matching query ID, QNAME, and IP source address. The interval between retransmissions, and the total number of retransmissions, should be operational parameters specifiable by the name server administrator, perhaps on a per-zone basis. Reasonable defaults are a 60 second interval and 5 attempts. It is also reasonable to use additive or exponential backoff for the retry interval. A NOTIFY packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT=ADCOUNT=0. If ANCOUNT is nonzero, then the answer section represents an unsecure hint at the new RR set for this . A slave receiving such an update is free to treat equivilence of this answer section with its local data as a ``no further work needs to be done'' indication; if ANCOUNT=0 or the answer section is present and differs from the slave's local data, then the slave is required to query its defined masters to retrieve the new data. In no case shall the answer section of a NOTIFY-!QR be used to update a slave's local data, or to indicate that a zone transfer needs to be undertaken, or to change the slave's zone refresh timers. Only a ``data present; data same'' condition can lead a slave to act differently based on a NOTIFY-!QR answer section. In the future, it is expected that this specification will be amended such that AUCOUNT or ADCOUNT may be allowed to be nonzero, to indicate that the new data is signed and secure, and can therefore be Paul Vixie [Page 2] - 3 - 24 March 1995 trusted. Until that work has been completed and a standard has been made, any packet with AUCOUNT<>0 or ADCOUNT<>0 must be ignored by any server receiving it. NOTE There is at this time no specification for incremental updates; the slave servers are NOT free to overlay a previous AXFR's data with data from a non-AXFR QUERY, even if that QUERY occurred as a result of a NOTIFY and the response to the QUERY is authoritative. NOTIFY may be the basis on which incremental updates are specified, but at this time it is only an ``update hint.'' If a slave receives a NOTIFY request from a host which is not listed in the slave's static list of masters for the zone containing the QNAME, it must ignore the request and may log an error in its operations log. Implementations must also ignore NOTIFY requests that come from a UDP port other than the DNS port (53), as these are by definition not from another name server. The only useful hint at this time is that the SOA RR has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the slave should behave as though the zone given in the QNAME had reached its REFRESH interval [see RFC 1035], i.e., it should query the master that sent the NOTIFY request, asking for the same QTYPE and QNAME as were given in the NOTIFY request. If an answer comes, and the SOA RR has a newer serial number than the slave's current copy of the zone, then a zone transfer should be initiated. 2. Some Definitions and Two Requirements Definition: a Master Server is any authoritative server configured to be the source of AXFR from one or more slave servers. It is named in an NS RR for the zone. Definition: a Slave Server is a quasi-authoritative server which uses AXFR to retrieve the zone. All slave servers are named in the NS RRs for the zone. Slaves which use AXFR to retrieve a zone, and which respect the SOA timeouts, but which are not listed in the zone's NS RR set, are ``unregistered''. Unregistered slaves are sometimes used to hot-wire a cache, and are outside the scope of the DNS prototols, but NOTIFY defines optional support for them. Note that a server is not, in the strict RFC 1035 sense of the term, ``authoritative'' for a zones it loads via AXFR, unless it is listed in the zone's NS RR set. The question of whether such servers should set the AA bit on responses they generate from such data, remains open. Paul Vixie [Page 3] - 4 - 24 March 1995 Definition: the Primary Master Server is the master server at the root of the AXFR dependency graph. The primary master is named in the zone's SOA MNAME field and by an NS RR. The source of the primary master's zone data is external to the DNS and is not a formal concern of this document. Requirement: for a zone to make use of the NOTIFY protocol, its servers must be organized into a dependency graph such that there is a primary master, and all other servers must use AXFR either from the primary master or from some slave which is also a master. A slave which is also a master is referred to later in this document as a ``slave-master''. No loops are permitted in the AXFR dependency graph. Requirement: for a zone to make use of the NOTIFY protocol, all servers named in the zone's NS RR set (under the delegation point) must use AXFR to do zone updates, or, if some other protocol is used (e.g., FTP or NFS), it must simulate the retry and refresh semantics of SOA/AXFR. 3. Semantic Details Master servers should maintain a list of slaves which have queried the SOA of the zone within the last SOA REFRESH interval. On a best efforts basis, NOTIFY requests should be sent to each slave server address whose last successful query for the changed RR's name and type was within that interval. Note that queries from UDP ports other than the DNS service port (53) are not subject to this requirement, since they cannot (by definition) be from other name servers. In a deep tree where some slaves AXFR new zones from other slaves, it can happen that some slaves will receive multiple NOTIFYs of the same RR change: one from the primary master, and one from each slave- master from which it has requested this RR's name and type within the last SOA REFRESH interval. The protocol supports this multiplicity by requiring that NOTIFY be sent by a slave-master only AFTER it has updated the RR. With an SOA NOTIFY, the RR can only change after a subsequent AXFR. Thus, barring delivery reordering, the last NOTIFY any slave receives will be the one indicating the latest change. Since a slave always requests SOAs and AXFRs only from its locally designated masters, it will have an opportunity to retry its SOA query after its masters have completed each zone update. If a master server seeks to avoid causing a large number of simultaneous outbound zone transfers, it may delay for an arbitrary length of time before sending a NOTIFY message to any given slave. It is expected that the time will be chosen at random, so that each Paul Vixie [Page 4] - 5 - 24 March 1995 slave will begin its transfer at a unique time, perhaps with some weighting so that pending outbound NOTIFY's are more likely to be sent out whenever a zone transfer completes. The delay shall not in any case be longer than the SOA REFRESH time, and should be a parameter that each primary master name server can specify, perhaps on a per-zone basis. Random delays of between 30 and 60 seconds would seem adequate if the servers share a LAN and the zones are less than a megabyte in size. A slave which receives a valid NOTIFY should defer action on any subsequent NOTIFY with the same until it has completed the transaction begun by the first NOTIFY. This duplicate rejection is necessary to avoid having multiplicitous notifications lead to pummeling the master server. The rest of this section is concerned only with SOA NOTIFY. 3.a. Zone has Updated on Primary Master Primary master sends a NOTIFY request to all servers named in the NS RR, except the one that is also named in the SOA MNAME, and optionally to all name servers which have queried for this SOA within the last SOA REFRESH interval. The NOTIFY has the following characteristics: query ID: (new) op: NOTIFY resp: NOERROR flags: AA qcount: 1 qname: (zone name) qclass: C_IN qtype: T_SOA ancount, aucount, adcount: 0 Note that setting any flag other than AA should cause slave servers to ignore this query. Only AA is defined, the others all must contain binary zero. 3.a.1. Zone has Updated on Slave-Master As above in 3.a, except that only those authoritative name servers (i.e., those listed in the zone's NS RR set) which have queried for this name and type within the SOA REFRESH interval need to be notified. Optionally, the slave-master may send to all servers which have sent such recent queries, without regard to whether they are listed in the zone's NS RR set. Paul Vixie [Page 5] - 6 - 24 March 1995 3.b. Slave Receives a NOTIFY Packet from a Master When a slave server receives a NOTIFY request from one of its locally designated masters for the zone enclosing the given QNAME, with QTYPE=SOA and !QR, it should enter the state it would if the zone's refresh timer had expired. It will also send a NOTIFY response back to the NOTIFY request's source, with the following characteristics: query ID: (same) op: NOTIFY resp: NOERROR flags: QR AA qcount: 1 qname: (zone name) qclass: C_IN qtype: T_SOA ancount, aucount, adcount: 0 Note that this is intentionally identical to the NOTIFY request, except that the QR bit is also set. Note, also, that the query ID must be the same as was received in the NOTIFY request. 3.c. Master Receives a NOTIFY-QR Packet from Slave When a master server receives a NOTIFY packet (with QR), it deletes this query from the retry queue, thus completing the ``notification process'' of ``this'' RR change to ``that'' server. Security Considerations DNS security is being considered overall by the DNSSEC working group. We believe that the NOTIFY operation's only security considerations are (A) that a previous SOA query can optionally cause a master to NOTIFY a false slave, and (B) that a NOTIFY request with a forged IP/UDP source address can cause a slave to send spurious SOA queries to its masters, leading to the possibility of a benign denial of service attack if the forged requests are received very often. Author's Address Paul Vixie Vixie Enterprises Star Route Box 159A Woodside, CA 94062 Phone: +1 415 747 0204 E-Mail: paul@vix.com Paul Vixie [Page 6] - 7 - 24 March 1995 Paul Vixie [Page 7]