Internet Area                                          P. Vixie
DNSIND Working Group
<draft-ietf-dnsind-notify-00.txt>                      30 November 1994                                   Vixie Enterprises

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 new data having changes not becoming available 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
   binary zero, and implementations are free to must ignore any request or

<draft-vixie-dns-notify-00.txt>DNS NOTIFY               30 November 1994 response
   packets where this is not the case.  The intent of this
   requirement is to permit future use specifications to be backward
   compatible with implementations conforming only to the initial use
   specification.

   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 name, type, and type
   optionally, new RDATA(s), to each known slave server using a best
   efforts protocol based on the NOTIFY opcode.

   One section (query) and one RR type (SOA) are defined at this time.
   Use of other sections or of other RR types is not defined by this
   document, and implementations are free to ignore packets containing
   such values unless they also implement some future specification(s)
   which specify their use.

   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=AUCOUNT=ADCOUNT=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 <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 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 ANCOUNT, AUCOUNT, and/or AUCOUNT or ADCOUNT may be allowed to be nonzero, to
   indicate that the new data is contained within the NOTIFY packet,
   possibly along with authentication data to validate this update.  For
   now, NOTIFY is merely a hint signed and secure, and can therefore be
   trusted.  Until that the slave server should query the
   master for a new copy of the RR(s) specified in the query section.
   As work has been completed and a result of this query, the slave standard has been
   made, any packet with AUCOUNT<>0 or ADCOUNT<>0 must be ignored by any
   server may decide to take some
   action, such as initiating a zone transfer.

<draft-vixie-dns-notify-00.txt>DNS NOTIFY               30 November 1994

   Note that there 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.  This is necessary for security reasons.  Implementations are must also free to 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 receipt completion of a NOTIFY hint transaction for QTYPE=SOA, the slave
   should behave as though the zone given in the QNAME had reached its
   REFRESH
   interval, 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 possibly-authoritative 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.

   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.

<draft-vixie-dns-notify-00.txt>DNS NOTIFY               30 November 1994

   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.

   A zone transfer resulting from an SOA NOTIFY should be deferred for

   If a
   random period of time so that master server seeks to avoid causing a large number of slaves will not
   simultaneously request a
   simultaneous outbound zone transfer when the serial number
   changes. transfers, it may delay for an arbitrary
   length of time before sending a NOTIFY message to any given slave.
   It is reasonable expected that the delay time will occur before the be chosen at random, so that each
   slave
   even bothers to ask for the new SOA, but it is not reasonable for the
   master will begin its transfer at a unique time, perhaps with some
   weighting so that pending outbound NOTIFY's are more likely to insert the be
   sent out whenever a zone transfer completes.  The delay before sending shall not in
   any case be longer than the SOA NOTIFY to any
   slaves.  The delay REFRESH time, and should be chosen to be a
   parameter that each primary master name server can specify, perhaps
   on a per-zone basis.  Random delays of between 10 30 and 60 seconds,
   unless these limits seconds
   would seem adequate if the servers share a LAN and the zones are overridden less
   than a megabyte in size.

   A slave which receives a valid NOTIFY should defer action on any
   subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
   completed the transaction begun by the name server administrator. 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.

<draft-vixie-dns-notify-00.txt>DNS NOTIFY               30 November 1994

   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.

   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

<draft-vixie-dns-notify-00.txt>DNS NOTIFY               30 November 1994

   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