DNSIND Working Group                                   Paul Vixie (ISC)

   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


      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

   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.

   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.

   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

   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.

      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
      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

   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 known by other servers if it sends queries from the DNS service port
                      (UDP 53).
                      they are given static configuration data indicating
                      its existence.

   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.

   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
   address whose last successful query for the changed RRset's
   <name,class,type> was within that the SOA refresh interval.  (Retaining this  Master servers
   might also be statically configured with a list of stealth servers who
   should be notified of zone SOA changes.  Retaining query state
   information informa-
   tion 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.) 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.

   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.

   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

   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.


      P. Mockapetris, "Domain Names - Implementation and Specification",
      RFC 1035, USC/Information Sciences Institute, November 1987.

      M. Ohta, "Incremental Zone Transfer", Internet Draft, July 1995,

   Author's Address

      Paul Vixie
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062
         +1 415 747 0204