1 Network Working Group                                           P. Vixie   
    2 Request for Comments: 1996                                           ISC   
    3 Updates: 1035                                                August 1996   
    4 Category: Standards Track                                                  
    7     A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)       
    9 Status of this Memo                                                        
   11    This document specifies an Internet standards track protocol for the    
   12    Internet community, and requests discussion and suggestions for         
   13    improvements.  Please refer to the current edition of the "Internet     
   14    Official Protocol Standards" (STD 1) for the standardization state      
   15    and status of this protocol.  Distribution of this memo is unlimited.   
   17 Abstract                                                                   
   19    This memo describes the NOTIFY opcode for DNS, by which a master        
   20    server advises a set of slave servers that the master's data has been   
   21    changed and that a query should be initiated to discover the new        
   22    data.                                                                   
   24 1. Rationale and Scope                                                     
   26    1.1. Slow propagation of new and changed data in a DNS zone can be      
   27    due to a zone's relatively long refresh times.  Longer refresh times    
   28    are beneficial in that they reduce load on the master servers, but      
   29    that benefit comes at the cost of long intervals of incoherence among   
   30    authority servers whenever the zone is updated.                         
   32    1.2. The DNS NOTIFY transaction allows master servers to inform slave   
   33    servers when the zone has changed -- an interrupt as opposed to poll    
   34    model -- which it is hoped will reduce propagation delay while not      
   35    unduly increasing the masters' load.  This specification only allows    
   36    slaves to be notified of SOA RR changes, but the architechture of       
   37    NOTIFY is intended to be extensible to other RR types.                  
   39    1.3. This document intentionally gives more definition to the roles     
   40    of "Master," "Slave" and "Stealth" servers, their enumeration in NS     
   41    RRs, and the SOA MNAME field.  In that sense, this document can be      
   42    considered an addendum to [RFC1035].                                    
   52 Vixie                       Standards Track                     [Page 1]   

   53 RFC 1996                       DNS NOTIFY                    August 1996   
   56 2. Definitions and Invariants                                              
   58    2.1. The following definitions are used in this document:               
   60    Slave           an authoritative server which uses zone transfer to     
   61                    retrieve the zone.  All slave servers are named in      
   62                    the NS RRs for the zone.                                
   64    Master          any authoritative server configured to be the source    
   65                    of zone transfer for one or more slave servers.         
   67    Primary Master  master server at the root of the zone transfer          
   68                    dependency graph.  The primary master is named in the   
   69                    zone's SOA MNAME field and optionally by an NS RR.      
   70                    There is by definition only one primary master server   
   71                    per zone.                                               
   73    Stealth         like a slave server except not listed in an NS RR for   
   74                    the zone.  A stealth server, unless explicitly          
   75                    configured to do otherwise, will set the AA bit in      
   76                    responses and be capable of acting as a master.  A      
   77                    stealth server will only be known by other servers if   
   78                    they are given static configuration data indicating     
   79                    its existence.                                          
   81    Notify Set      set of servers to be notified of changes to some        
   82                    zone.  Default is all servers named in the NS RRset,    
   83                    except for any server also named in the SOA MNAME.      
   84                    Some implementations will permit the name server        
   85                    administrator to override this set or add elements to   
   86                    it (such as, for example, stealth servers).             
   88    2.2. The zone's servers must be organized into a dependency graph       
   89    such that there is a primary master, and all other servers must use     
   90    AXFR or IXFR either from the primary master or from some slave which    
   91    is also a master.  No loops are permitted in the AXFR dependency        
   92    graph.                                                                  
   94 3. NOTIFY Message                                                          
   96    3.1. When a master has updated one or more RRs in which slave servers   
   97    may be interested, the master may send the changed RR's name, class,    
   98    type, and optionally, new RDATA(s), to each known slave server using    
   99    a best efforts protocol based on the NOTIFY opcode.                     
  101    3.2. NOTIFY uses the DNS Message Format, although it uses only a        
  102    subset of the available fields.  Fields not otherwise described         
  103    herein are to be filled with binary zero (0), and implementations       
  107 Vixie                       Standards Track                     [Page 2]   

  108 RFC 1996                       DNS NOTIFY                    August 1996   
  111    must ignore all messages for which this is not the case.                
  113    3.3. NOTIFY is similar to QUERY in that it has a request message with   
  114    the header QR flag "clear" and a response message with QR "set".  The   
  115    response message contains no useful information, but its reception by   
  116    the master is an indication that the slave has received the NOTIFY      
  117    and that the master can remove the slave from any retry queue for       
  118    this NOTIFY event.                                                      
  120    3.4. The transport protocol used for a NOTIFY transaction will be UDP   
  121    unless the master has reason to believe that TCP is necessary; for      
  122    example, if a firewall has been installed between master and slave,     
  123    and only TCP has been allowed; or, if the changed RR is too large to    
  124    fit in a UDP/DNS datagram.                                              
  126    3.5. If TCP is used, both master and slave must continue to offer       
  127    name service during the transaction, even when the TCP transaction is   
  128    not making progress.  The NOTIFY request is sent once, and a            
  129    "timeout" is said to have occurred if no NOTIFY response is received    
  130    within a reasonable interval.                                           
  132    3.6. If UDP is used, a master periodically sends a NOTIFY request to    
  133    a slave until either too many copies have been sent (a "timeout"), an   
  134    ICMP message indicating that the port is unreachable, or until a        
  135    NOTIFY response is received from the slave with a matching query ID,    
  136    QNAME, IP source address, and UDP source port number.                   
  138    Note:                                                                   
  139       The interval between transmissions, and the total number of          
  140       retransmissions, should be operational parameters specifiable by     
  141       the name server administrator, perhaps on a per-zone basis.          
  142       Reasonable defaults are a 60 second interval (or timeout if          
  143       using TCP), and a maximum of 5 retransmissions (for UDP).  It is     
  144       considered reasonable to use additive or exponential backoff for     
  145       the retry interval.                                                  
  147    3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,            
  148    ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an        
  149    unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A        
  150    slave receiving such a hint is free to treat equivilence of this        
  151    answer section with its local data as a "no further work needs to be    
  152    done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section    
  153    differs from the slave's local data, then the slave should query its    
  154    known masters to retrieve the new data.                                 
  156    3.8. In no case shall the answer section of a NOTIFY request be used    
  157    to update a slave's local data, or to indicate that a zone transfer     
  158    needs to be undertaken, or to change the slave's zone refresh timers.   
  162 Vixie                       Standards Track                     [Page 3]   

  163 RFC 1996                       DNS NOTIFY                    August 1996   
  166    Only a "data present; data same" condition can lead a slave to act      
  167    differently if ANCOUNT>0 than it would if ANCOUNT=0.                    
  169    3.9. This version of the NOTIFY specification makes no use of the       
  170    authority or additional data sections, and so conforming                
  171    implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting    
  172    requests.  Since a future revision of this specification may define a   
  173    backwards compatible use for either or both of these sections,          
  174    current implementations must ignore these sections, but not the         
  175    entire message, if AUCOUNT>0 and/or ADCOUNT>0.                          
  177    3.10. If a slave receives a NOTIFY request from a host that is not a    
  178    known master for the zone containing the QNAME, it should ignore the    
  179    request and produce an error message in its operations log.             
  181    Note:                                                                   
  182       This implies that slaves of a multihomed master must either know     
  183       their master by the "closest" of the master's interface              
  184       addresses, or must know all of the master's interface addresses.     
  185       Otherwise, a valid NOTIFY request might come from an address         
  186       that is not on the slave's state list of masters for the zone,       
  187       which would be an error.                                             
  189    3.11. The only defined NOTIFY event at this time is that the SOA RR     
  190    has changed.  Upon completion of a NOTIFY transaction for QTYPE=SOA,    
  191    the slave should behave as though the zone given in the QNAME had       
  192    reached its REFRESH interval (see [RFC1035]), i.e., it should query     
  193    its masters for the SOA of the zone given in the NOTIFY QNAME, and      
  194    check the answer to see if the SOA SERIAL has been incremented since    
  195    the last time the zone was fetched.  If so, a zone transfer (either     
  196    AXFR or IXFR) should be initiated.                                      
  198    Note:                                                                   
  199       Because a deep server dependency graph may have multiple paths       
  200       from the primary master to any given slave, it is possible that      
  201       a slave will receive a NOTIFY from one of its known masters even     
  202       though the rest of its known masters have not yet updated their      
  203       copies of the zone.  Therefore, when issuing a QUERY for the         
  204       zone's SOA, the query should be directed at the known master who     
  205       was the source of the NOTIFY event, and not at any of the other      
  206       known masters.  This represents a departure from [RFC1035],          
  207       which specifies that upon expiry of the SOA REFRESH interval,        
  208       all known masters should be queried in turn.                         
  210    3.12. If a NOTIFY request is received by a slave who does not           
  211    implement the NOTIFY opcode, it will respond with a NOTIMP              
  212    (unimplemented feature error) message.  A master server who receives    
  213    such a NOTIMP should consider the NOTIFY transaction complete for       
  217 Vixie                       Standards Track                     [Page 4]   

  218 RFC 1996                       DNS NOTIFY                    August 1996   
  221    that slave.                                                             
  223 4. Details and Examples                                                    
  225    4.1. Retaining query state information across host reboots is           
  226    optional, but it is reasonable to simply execute an SOA NOTIFY          
  227    transaction on each authority zone when a server first starts.          
  229    4.2. Each slave is likely to receive several copies of the same         
  230    NOTIFY request:  One from the primary master, and one from each other   
  231    slave as that slave transfers the new zone and notifies its potential   
  232    peers.  The NOTIFY protocol supports this multiplicity by requiring     
  233    that NOTIFY be sent by a slave/master only AFTER it has updated the     
  234    SOA RR or has determined that no update is necessary, which in          
  235    practice means after a successful zone transfer.  Thus, barring         
  236    delivery reordering, the last NOTIFY any slave receives will be the     
  237    one indicating the latest change.  Since a slave always requests SOAs   
  238    and AXFR/IXFRs only from its known masters, it will have an             
  239    opportunity to retry its QUERY for the SOA after each of its masters    
  240    have completed each zone update.                                        
  242    4.3. If a master server seeks to avoid causing a large number of        
  243    simultaneous outbound zone transfers, it may delay for an arbitrary     
  244    length of time before sending a NOTIFY message to any given slave.      
  245    It is expected that the time will be chosen at random, so that each     
  246    slave will begin its transfer at a unique time.  The delay shall not    
  247    in any case be longer than the SOA REFRESH time.                        
  249    Note:                                                                   
  250       This delay should be a parameter that each primary master name       
  251       server can specify, perhaps on a per-zone basis.  Random delays      
  252       of between 30 and 60 seconds would seem adequate if the servers      
  253       share a LAN and the zones are of moderate size.                      
  255    4.4. A slave which receives a valid NOTIFY should defer action on any   
  256    subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has       
  257    completed the transaction begun by the first NOTIFY.  This duplicate    
  258    rejection is necessary to avoid having multiple notifications lead to   
  259    pummeling the master server.                                            
  272 Vixie                       Standards Track                     [Page 5]   

  273 RFC 1996                       DNS NOTIFY                    August 1996   
  276    4.5 Zone has Updated on Primary Master                                  
  278    Primary master sends a NOTIFY request to all servers named in Notify    
  279    Set.  The NOTIFY request has the following characteristics:             
  281       query ID:   (new)                                                    
  282       op:         NOTIFY (4)                                               
  283       resp:       NOERROR                                                  
  284       flags:      AA                                                       
  285       qcount:     1                                                        
  286       qname:      (zone name)                                              
  287       qclass:     (zone class)                                             
  288       qtype:      T_SOA                                                    
  290    4.6 Zone has Updated on a Slave that is also a Master                   
  292    As above in 4.5, except that this server's Notify Set may be            
  293    different from the Primary Master's due to optional static              
  294    specification of local stealth servers.                                 
  296    4.7 Slave Receives a NOTIFY Request from a Master                       
  298    When a slave server receives a NOTIFY request from one of its locally   
  299    designated masters for the zone enclosing the given QNAME, with         
  300    QTYPE=SOA and QR=0, it should enter the state it would if the zone's    
  301    refresh timer had expired.  It will also send a NOTIFY response back    
  302    to the NOTIFY request's source, with the following characteristics:     
  304       query ID:   (same)                                                   
  305       op:         NOTIFY (4)                                               
  306       resp:       NOERROR                                                  
  307       flags:      QR AA                                                    
  308       qcount:     1                                                        
  309       qname:      (zone name)                                              
  310       qclass:     (zone class)                                             
  311       qtype:      T_SOA                                                    
  313    This is intended to be identical to the NOTIFY request, except that     
  314    the QR bit is also set.  The query ID of the response must be the       
  315    same as was received in the request.                                    
  317    4.8 Master Receives a NOTIFY Response from Slave                        
  319    When a master server receives a NOTIFY response, it deletes this        
  320    query from the retry queue, thus completing the "notification           
  321    process" of "this" RRset change to "that" server.                       
  327 Vixie                       Standards Track                     [Page 6]   

  328 RFC 1996                       DNS NOTIFY                    August 1996   
  331 5. Security Considerations                                                 
  333    We believe that the NOTIFY operation's only security considerations     
  334    are:                                                                    
  336    1. That a NOTIFY request with a forged IP/UDP source address can        
  337       cause a slave to send spurious SOA queries to its masters,           
  338       leading to a benign denial of service attack if the forged           
  339       requests are sent very often.                                        
  341    2. That TCP spoofing could be used against a slave server given         
  342       NOTIFY as a means of synchronizing an SOA query and UDP/DNS          
  343       spoofing as a means of forcing a zone transfer.                      
  345 6. References                                                              
  347    [RFC1035]                                                               
  348       Mockapetris, P., "Domain Names - Implementation and                  
  349       Specification", STD 13, RFC 1035, November 1987.                     
  351    [IXFR]                                                                  
  352       Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.        
  354 7. Author's Address                                                        
  356    Paul Vixie                                                              
  357    Internet Software Consortium                                            
  358    Star Route Box 159A                                                     
  359    Woodside, CA 94062                                                      
  361    Phone: +1 415 747 0204                                                  
  362    EMail: paul@vix.com                                                     
  382 Vixie                       Standards Track                     [Page 7]   

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

This RFC is implemented in BIND 9.18 (all versions).