Internet Area                                          P. Vixie
DNSIND Working Group                                   Vixie Enterprises
<draft-ietf-dnsind-notify-02.txt>                      09-July-1995
<draft-ietf-dnsind-notify-03.txt>                      04-August-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 doc-
   uments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute
   working 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 Internet-Drafts as reference
   material 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. 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 potentially lengthy interval has elapsed.

   The DNS NOTIFY transaction 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

<draft-ietf-dnsind-notify-02.txt>- 2 -                      09-July-1995

<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,'' ``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. 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 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 specifi-
   able 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=0, ADCOUNT=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 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
   masters to retrieve the new data.  In no case shall the answer
   section sec-
   tion 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

   This version of the future, it is expected that this NOTIFY specification will be amended
   such that AUCOUNT or ADCOUNT may be allowed to be nonzero, to
   indicate that makes no use of the new author-
   ity or additional data is signed sections, and secure, and can therefore be

<draft-ietf-dnsind-notify-02.txt>- 3 -                      09-July-1995

   trusted.  Until that work has been completed 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 standard has been
   made, any packet with AUCOUNT<>0 future revision of this specification may define a backwards com-
   patible use for either or ADCOUNT<>0 both of these sections, current implementa-
   tions must be ignored by any
   server receiving it. ignore them if present.

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

   NOTE: This implies that slaves of a multihomed master must either
          specify the ``closest'' of the master's interface addresses,
          or must list them all.  Otherwise, the NOTIFY-!QR might come
          from an address that is not on the slave's state list of mas-
          ters for the zone, which would be an artificial error.

   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: the Primary Master Server is the host at the
        root of the AXFR/IXFR dependency graph.  The primary master is
        named in the zone's SOA MNAME field, and optionally by an NS RR.
        The source of 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 be the source of AXFR/IXFR from one or more slave servers.
        It is named in an NS RR for the zone.

   Definition: a Slave Server is a an authoritative server which that uses
        AXFR/IXFR to retrieve the zone.  All slave servers are named in
        the NS RRs for the zone.  A slave server can also act as a master mas-
        ter in the case of a deep AXFR/IXFR tree.

   Definition: a Stealth Server is a potentially authoritative server
   which
        that uses AXFR/IXFR as described above for ``Slave Server.''
        Stealth servers are not named in the NS RRs for the zone, and
        are thus useful only as a way to ``hotwire the cache.''  A
        stealth server will, unless explicitly configured to do otherwise, sets other-
        wise, set the AA bit in responses and is capable of acting as a
        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
        servers must be organized into a dependency graph such that
        there is a primary master, and all other servers must use AXFR

<draft-ietf-dnsind-notify-02.txt>- 4 -                      09-July-1995
        either from the primary master or from some slave which is also
        a 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 pro-
        tocol is used (e.g., FTP or NFS), it must simulate all of the
        semantics of SOA/AXFR/IXFR.

3. 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 was within that interval.  (Retaining this state information
   across host reboots is optional, but it is reasonable to simply
   execute exe-
   cute a 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 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/IXFR.  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 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 simulta-
   neous 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.  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 size.

   A slave which receives a valid NOTIFY should defer action on any
   subsequent sub-
   sequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has

<draft-ietf-dnsind-notify-02.txt>- 5 -                      09-July-1995

   completed com-
   pleted 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. 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 option-
   ally to all name servers which have queried for this SOA within the
   last SOA REFRESH interval.  The NOTIFY has the following
   characteristics: characteris-
   tics:

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

   3.a.1. Zone has Updated on a Slave that is also a 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. noti-
   fied.  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. 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

<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

<draft-ietf-dnsind-notify-02.txt>- 6 -                      09-July-1995
        flags:    QR AA
        qcount:   1
        qname:    (zone name)
        qclass: C_IN   (zone class)
        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
   are: (A) that a previous SOA query can optionally cause a master to
   NOTIFY a false slave, and slave; (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 sent very often. often; and (C) 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.

Author's Address

   Paul Vixie
   Vixie Enterprises
   Star Route Box 159A
   Woodside, CA 94062

   Phone: +1 415 747 0204

   E-Mail: paul@vix.com