Network Working Group P. Vixie
Request for Comments: 1996 ISC
Updates: 1035 August 1996
Category: Standards Track
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo 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.
1. Rationale and Scope
1.1. 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 long intervals of incoherence among
authority servers whenever the zone is updated.
1.2. 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 specification only allows
slaves to be notified of SOA RR changes, but the architechture of
NOTIFY is intended to be extensible to other RR types.
1.3. 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 [RFC1035].
Vixie Standards Track [Page 1]
RFC 1996 DNS NOTIFY August 1996
2. Definitions and Invariants
2.1. 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.
Primary Master master server at the root of the zone transfer
dependency 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
configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A
stealth server will only be known by other servers if
they are given static configuration data indicating
its existence.
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
2.2. 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. No loops are permitted in the AXFR dependency
graph.
3. NOTIFY Message
3.1. 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.
3.2. NOTIFY uses the DNS Message Format, although it uses only a
subset of the available fields. Fields not otherwise described
herein are to be filled with binary zero (0), and implementations
Vixie Standards Track [Page 2]
RFC 1996 DNS NOTIFY August 1996
must ignore all messages for which this is not the case.
3.3. NOTIFY is similar to QUERY in that it has a request message with
datatracker.ietf.org