Internet Area                                          P. Vixie
   DNSIND Working Group                                   Paul Vixie Enterprises
<draft-ietf-dnsind-notify-03.txt>                      04-August-1995 (ISC)
   <draft-ietf-dnsind-notify-04.txt>

   Updates: RFC 1035

Notify:

       DNS NOTIFY: a mechanism for prompt notification of authority 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.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 benefi-
   cial 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 potentially lengthy interval has elapsed. long intervals of incoherence among authority
   servers whenever the zone is updated.

   The DNS NOTIFY transaction allows master servers to inform slave servers
   when data have 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

<draft-ietf-dnsind-notify-xx.txt>  -2-                    04-August-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
   ``Master,'' ``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 RFC 1035.

1. [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 a
   hint 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 NOTIFY-!QR to a slave until either too many
   copies have been sent (a ``timeout'') ``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 retransmissions, retrans-
   missions, should be operational parameters specifi-
   able 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 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 an update 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 defined known masters to retrieve
   the new data.  In no case shall the answer sec-
   tion 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. if ANCOUNT>0 than it would if ANCOUNT==0.

   This version of the NOTIFY specification makes no use of the author-
   ity authority
   or additional data sections, and so conforming implementations should
   set AUCOUNT=0 and ADCOUNT=0 when transmitting requests.  Since

<draft-ietf-dnsind-notify-xx.txt>  -3-                    04-August-1995 a future
   revision of this specification may define a backwards com-
   patible compatible use for
   either or both of these sections, current implementa-
   tions implementations must ignore them
   these sections, but not the entire packet, if present. AUCOUNT>0 and/or
   ADCOUNT>0.

   If a slave receives a NOTIFY request from a host that is not listed
   in the slave's static list of masters a known
   master for the zone containing the QNAME, it should ignore the request
   and produce an error message in its operations log.

   NOTE:

   Note:
      This implies that slaves of a multihomed master must either
          specify know
      their master by the ``closest'' of the master's interface addresses,
      or must list them all.  Otherwise, 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 mas-
          ters masters for the zone, which would be an artificial artifi-
      cial error.

   The only useful hint 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 RFC 1035], (see [RFC1035]), i.e., it should query the master
   that sent the NOTIFY request, asking its masters
   for the same QTYPE and QNAME as
   were SOA of the zone given in the NOTIFY request.  If an answer comes, QNAME, and check the answer
   to see if the SOA RR SERIAL has a newer serial number than been incremented since the slave's current copy of last time the zone,
   then
   zone was fetched.  If so, a zone transfer (either AXFR or IXFR) should
   be initiated.

2. Some Definitions and Two Requirements

   Definition:  (See [IXFR] for more information about incremental zone
   transfers.)
   Note:
      Because a deep server dependency graph may have multiple paths from
      the Primary Master Server 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 host at the
        root
      rest of its known masters have not yet updated their copies of the AXFR/IXFR dependency graph.  The primary master is
        named in
      zone.  Therefore, when issuing a QUERY for the zone's SOA MNAME field, and optionally by an NS RR.
        The source of SOA, the primary master's zone data is external to the
        DNS, for example, the host's file system.

   Definition: a Master Server is any authoritative server configured
        to query
      should be directed at the known master who was the source of AXFR/IXFR from one or more slave servers.
        It is named in an NS RR for the zone.

   Definition:
      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 Server is a           an authoritative server that which uses
        AXFR/IXFR zone transfer to
                      retrieve the zone.  All slave servers are named in
                      the NS RRs for the zone.  A slave

      Master          any authoritative server can also act as a mas-
        ter in configured to be the case source
                      of a deep AXFR/IXFR tree.

   Definition: a Stealth Server is a potentially authoritative server
        that uses AXFR/IXFR as described above zone transfer for ``Slave Server.''
        Stealth one or more slave servers.  All
                      slave servers are not named in the NS RRs for the zone, 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
        are thus useful optionally by an NS RR.
                      There is by definition only as one primary master server
                      per zone.

      Stealth         like a way to ``hotwire slave server except not listed in an NS RR for
                      the cache.'' zone.  A stealth server will, server, unless explicitly configured con-
                      figured to do other-
        wise, otherwise, will set the AA bit in
                      responses and is be capable of acting as a
        Master. master.  A
                      stealth server will only be recognized by other

<draft-ietf-dnsind-notify-xx.txt>  -4-                    04-August-1995
                      servers if it sends queries from the DNS service port
                      (UDP 53).

   Requirement: for a zone to make use of the NOTIFY protocol, its

   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 master. mas-
   ter.  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 pro-
        tocol is used (e.g., FTP or NFS), it must simulate all of the
        semantics of SOA/AXFR/IXFR.

3.

   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 RR's name
   and type RRset's
   <name,class,type> was within that interval.  (Retaining this state
   information across host reboots is optional, but it is reasonable to
   simply exe-
   cute a 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 RR's name and type 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 RR.  With an SOA NOTIFY, the RR can only change or has determined that no update is necessary, which
   in practice means after a
   subsequent AXFR/IXFR. 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 locally designated known masters, it will have an opportunity to
   retry its QUERY for the SOA query after each of its masters have completed
   each zone update.

   If a master server seeks to avoid causing a large number of simulta-
   neous 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, perhaps with some weighting
   so that pending outbound NOTIFY's are more likely to be sent out
   whenever a zone transfer completes. 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

<draft-ietf-dnsind-notify-xx.txt>  -5-                    04-August-1995 adequate if the servers
   share a LAN and the zones are less than a
   megabyte in of moderate size.

   A slave which receives a valid NOTIFY should defer action on any sub-
   sequent subse-
   quent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has com-
   pleted completed
   the transaction begun by the first NOTIFY.  This duplicate rejection is
   necessary to avoid having multiple notifications lead to pummeling the
   master server.

   The rest of this section is concerned only with SOA NOTIFY.

   3.a.

   3.1 - Zone has Updated on Primary Master

   Primary master sends a NOTIFY NOTIFY-!QR request to all servers named in the NS
   RR, except the one that is also named in the SOA MNAME, and option-
   ally optionally
   to all name servers which have queried for this SOA within the last SOA
   REFRESH interval.  The NOTIFY has the following characteris-
   tics: characteristics:

      query ID:   (new)
      op:         NOTIFY
      resp:       NOERROR
      flags:      AA
      qcount:     1
      qname:      (zone name)
      qclass:     (zone class)
      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 con-
   tain binary zero.

   3.a.1.

   3.1.1 - Zone has Updated on a Slave that is also a Master

   As above in 3.a, 3.1, except that only those authoritative name servers
   (i.e., those listed in the zone's NS RR set) RRset) which have queried for this
   name and type within the SOA REFRESH interval need to be noti-
   fied. 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.

   3.b. RRset.

   3.2 - Slave Receives a NOTIFY 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

<draft-ietf-dnsind-notify-xx.txt>  -6-                    04-August-1995 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
        ancount, aucount, adcount: 0

   Note that this

   This is intentionally intended to be identical to the NOTIFY request, NOTIFY-!QR, except that the QR
   bit is also set.  Note, also, that set, and the query ID must be the same as was received in
   the NOTIFY NOTIFY-!QR request.

   3.c.

   3.2 - Master Receives a NOTIFY-QR Packet from Slave

   When a master server receives a NOTIFY packet (with QR), NOTIFY-QR packet, it deletes this query
   from the retry queue, thus completing the ``notification process'' of
   ``this'' RR RRset change to ``that'' server.

   Security Considerations

   We believe that the NOTIFY operation's only security considerations are: (A) that

   1. That a previous SOA query can optionally cause a master to NOTIFY a
      false slave; (B) that 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; and (C) that
      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
   Vixie Enterprises
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062

   Phone:
         +1 415 747 0204

   E-Mail: paul@vix.com
         <paul@vix.com>