DNSIND Working Group Paul Vixie (ISC) INTERNET-DRAFT October, 1995 <draft-ietf-dnsind-notify-04.txt> Updates: RFC 1035 DNS NOTIFY: a mechanism for prompt notification of zone changes Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial 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 the NOTIFY opcode for DNS, 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.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 benefi- cial in that they reduce load on the master servers, but that benefit comes at the cost of long intervals of incoherence among authority servers whenever the zone is updated. Expires May, 1996 [Page 1]
INTERNET-DRAFT DNS NOTIFY October 1995 The DNS NOTIFY transaction allows master servers to inform slave servers when the zone has 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 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 ``Mas- ter,'' ``Slave'' and ``Stealth'' servers, their enumeration in NS RRs, and the SOA MNAME field. In that sense, this document can be considered an addendum to [RFC1035]. 1.0 - 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, class, type, and optionally, new RDATA(s), to each known slave server using a best efforts protocol based on the NOTIFY opcode. NOTIFY borrows its packet data format from QUERY, although it uses only a subset of the fields present. Fields not otherwise described herein are to be filled with binary zero (0), and implementations must ignore all packets for which this is not the case. 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 an indication 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-!QR to a slave until either too many copies have been sent (a ``timeout''), an ICMP message indicating that the port, host, or net is unreachable, 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 retrans- missions, 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. Expires May, 1996 [Page 2]
INTERNET-DRAFT DNS NOTIFY October 1995 A NOTIFY-!QR packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0. If ANCOUNT is nonzero, then the answer section represents an unsecure hint at the new RR set for this <QNAME,QCLASS,QTYPE>. A slave receiving such a hint 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 should query its known 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 if ANCOUNT>0 than it would if ANCOUNT==0. This version of the NOTIFY specification makes no use of the authority or additional data sections, and so conforming implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a future revision of this specification may define a backwards compatible use for either or both of these sections, current implementations must ignore these sections, but not the entire packet, if AUCOUNT>0 and/or ADCOUNT>0. If a slave receives a NOTIFY request from a host that is not a known master for the zone containing the QNAME, it should ignore the request and produce an error message in its operations log. Note: This implies that slaves of a multihomed master must either know their master by the ``closest'' of the master's interface addresses, or must know all of the master's interface addresses. Otherwise, a valid NOTIFY-!QR might come from an address that is not on the slave's state list of masters for the zone, which would be an artifi- cial error. The only defined NOTIFY event 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 [RFC1035]), i.e., it should query its masters for the SOA of the zone given in the NOTIFY QNAME, and check the answer to see if the SOA SERIAL has been incremented since the last time the zone was fetched. If so, a zone transfer (either AXFR or IXFR) should be initiated. (See [IXFR] for more information about incremental zone transfers.) Expires May, 1996 [Page 3]
INTERNET-DRAFT DNS NOTIFY October 1995 Note: Because a deep server dependency graph may have multiple paths from the primary master to any given slave, it is possible that a slave will receive a NOTIFY from one of its known masters even though the rest of its known masters have not yet updated their copies of the zone. Therefore, when issuing a QUERY for the zone's SOA, the query should be directed at the known master who was the source of the NOTIFY event, and not at any of the other known masters. This repre- sents a departure from [RFC1035], which specifies that upon expiry of the SOA REFRESH interval, all known masters should be queried in turn. 2.0 - Definitions and Invariants The following definitions are used in this document: Slave an authoritative server which uses zone transfer to retrieve the zone. All slave servers are named in the NS RRs for the zone. Master any authoritative server configured to be the source of zone transfer for one or more slave servers. All slave servers are named in the NS RRs for the zone. Primary Master master server at the root of the zone transfer depen- dency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone. Stealth like a slave server except not listed in an NS RR for the zone. A stealth server, unless explicitly con- figured to do otherwise, will set the AA bit in responses and be capable of acting as a master. A stealth server will only be recognized by other servers if it sends queries from the DNS service port (UDP 53). The zone's servers must be organized into a dependency graph such that there is a primary master, and all other servers must use AXFR or IXFR either from the primary master or from some slave which is also a mas- ter. No loops are permitted in the AXFR dependency graph. Expires May, 1996 [Page 4]
INTERNET-DRAFT DNS NOTIFY October 1995 3.0 - Semantic Details Master servers should maintain a list of stealth servers 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 RRset's <name,class,type> was within that interval. (Retaining this state information across host reboots is optional, but it is reasonable to simply execute an SOA NOTIFY transaction on each authority zone when a server first starts.) In a deep tree where some slaves fetch 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 other slave from which it has requested this RRset's <name,class,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 SOA RR or has determined that no update is necessary, which in practice means after a successful zone transfer. 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 AXFR/IXFRs only from its known masters, it will have an opportunity to retry its QUERY for the SOA after each of 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 slave will begin its transfer at a unique time. 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 of moderate size. A slave which receives a valid NOTIFY should defer action on any subse- quent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has completed the transaction begun by the first NOTIFY. This duplicate rejection is necessary to avoid having multiple notifications lead to pummeling the master server. Expires May, 1996 [Page 5]
INTERNET-DRAFT DNS NOTIFY October 1995 3.1 - Zone has Updated on Primary Master Primary master sends a NOTIFY-!QR 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: (zone class) qtype: T_SOA 3.1.1 - Zone has Updated on a Slave that is also a Master As above in 3.1, except that only those authoritative name servers (i.e., those listed in the zone's NS RRset) 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 RRset. 3.2 - Slave Receives a NOTIFY-!QR 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: (zone class) qtype: T_SOA This is intended to be identical to the NOTIFY-!QR, except that the QR bit is also set, and the query ID must be the same as was received in the NOTIFY-!QR request. Expires May, 1996 [Page 6]
INTERNET-DRAFT DNS NOTIFY October 1995 3.2 - Master Receives a NOTIFY-QR Packet from Slave When a master server receives a NOTIFY-QR packet, it deletes this query from the retry queue, thus completing the ``notification process'' of ``this'' RRset change to ``that'' server. Security Considerations We believe that the NOTIFY operation's only security considerations are: 1. That a previous SOA query can optionally cause a master to NOTIFY a false slave. 2. 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 a benign denial of service attack if the forged requests are sent very often. 3. That TCP spoofing could be used against a slave server given NOTIFY as a means of synchronizing an SOA query and UDP/DNS spoofing as a means of forcing a zone transfer. References [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, USC/Information Sciences Institute, November 1987. [IXFR] M. Ohta, "Incremental Zone Transfer", Internet Draft, July 1995, <draft-ietf-dnsind-ixfr-02.txt>. Author's Address Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 +1 415 747 0204 <paul@vix.com> Expires May, 1996 [Page 7]
