diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc1996.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc1996.txt | 395 |
1 files changed, 0 insertions, 395 deletions
diff --git a/contrib/bind9/doc/rfc/rfc1996.txt b/contrib/bind9/doc/rfc/rfc1996.txt deleted file mode 100644 index b08f200..0000000 --- a/contrib/bind9/doc/rfc/rfc1996.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -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 - the header QR flag "clear" and a response message with QR "set". The - response message contains no useful information, but its reception by - the master is 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. - - 3.4. The transport protocol used for a NOTIFY transaction will be UDP - unless the master has reason to believe that TCP is necessary; for - example, if a firewall has been installed between master and slave, - and only TCP has been allowed; or, if the changed RR is too large to - fit in a UDP/DNS datagram. - - 3.5. If TCP is used, both master and slave must continue to offer - name service during the transaction, even when the TCP transaction is - not making progress. The NOTIFY request is sent once, and a - "timeout" is said to have occurred if no NOTIFY response is received - within a reasonable interval. - - 3.6. If UDP is used, a master periodically sends a NOTIFY request to - a slave until either too many copies have been sent (a "timeout"), an - ICMP message indicating that the port is unreachable, or until a - NOTIFY response is received from the slave with a matching query ID, - QNAME, IP source address, and UDP source port number. - - Note: - The interval between transmissions, 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 (or timeout if - using TCP), and a maximum of 5 retransmissions (for UDP). It is - considered reasonable to use additive or exponential backoff for - the retry interval. - - 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, - ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an - unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A - slave receiving such 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 ANCOUNT>0 and the answer section - differs from the slave's local data, then the slave should query its - known masters to retrieve the new data. - - 3.8. In no case shall the answer section of a NOTIFY request 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. - - - -Vixie Standards Track [Page 3] - -RFC 1996 DNS NOTIFY August 1996 - - - Only a "data present; data same" condition can lead a slave to act - differently if ANCOUNT>0 than it would if ANCOUNT=0. - - 3.9. This version of the NOTIFY specification makes no use of the - authority or additional data sections, and so conforming - implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting - requests. Since a future revision of this specification may define a - backwards compatible use for either or both of these sections, - current implementations must ignore these sections, but not the - entire message, if AUCOUNT>0 and/or ADCOUNT>0. - - 3.10. If a slave receives a NOTIFY request from a host that is not a - known master for the zone containing the QNAME, it should ignore the - request and produce an error message in its operations log. - - Note: - This implies that slaves of a multihomed master must either know - their master by the "closest" of the master's interface - addresses, or must know all of the master's interface addresses. - Otherwise, a valid NOTIFY request might come from an address - that is not on the slave's state list of masters for the zone, - which would be an error. - - 3.11. The only 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 [RFC1035]), i.e., it should query - its masters for the SOA of the zone given in the NOTIFY QNAME, and - check the answer to see if the SOA SERIAL has been incremented since - the last time the zone was fetched. If so, a zone transfer (either - AXFR or IXFR) should be initiated. - - Note: - Because a deep server dependency graph may have multiple paths - from the 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 rest of its known masters have not yet updated their - copies of the zone. Therefore, when issuing a QUERY for the - zone's SOA, the query should be directed at the known master who - was the source of the NOTIFY event, and not at any of the other - known masters. This represents a departure from [RFC1035], - which specifies that upon expiry of the SOA REFRESH interval, - all known masters should be queried in turn. - - 3.12. If a NOTIFY request is received by a slave who does not - implement the NOTIFY opcode, it will respond with a NOTIMP - (unimplemented feature error) message. A master server who receives - such a NOTIMP should consider the NOTIFY transaction complete for - - - -Vixie Standards Track [Page 4] - -RFC 1996 DNS NOTIFY August 1996 - - - that slave. - -4. Details and Examples - - 4.1. Retaining query state information across host reboots is - optional, but it is reasonable to simply execute an SOA NOTIFY - transaction on each authority zone when a server first starts. - - 4.2. Each slave is likely to receive several copies of the same - NOTIFY request: One from the primary master, and one from each other - slave as that slave transfers the new zone and notifies its potential - peers. The NOTIFY protocol supports this multiplicity by requiring - that NOTIFY be sent by a slave/master only AFTER it has updated the - SOA RR or has determined that no update is necessary, which in - practice means after a 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 known masters, it will have an - opportunity to retry its QUERY for the SOA after each of its masters - have completed each zone update. - - 4.3. If a master server seeks to avoid causing a large number of - 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. The delay shall not - in any case be longer than the SOA REFRESH time. - - Note: - This delay 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 adequate if the servers - share a LAN and the zones are of moderate size. - - 4.4. 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 first NOTIFY. This duplicate - rejection is necessary to avoid having multiple notifications lead to - pummeling the master server. - - - - - - - - - - - - -Vixie Standards Track [Page 5] - -RFC 1996 DNS NOTIFY August 1996 - - - 4.5 Zone has Updated on Primary Master - - Primary master sends a NOTIFY request to all servers named in Notify - Set. The NOTIFY request has the following characteristics: - - query ID: (new) - op: NOTIFY (4) - resp: NOERROR - flags: AA - qcount: 1 - qname: (zone name) - qclass: (zone class) - qtype: T_SOA - - 4.6 Zone has Updated on a Slave that is also a Master - - As above in 4.5, except that this server's Notify Set may be - different from the Primary Master's due to optional static - specification of local stealth servers. - - 4.7 Slave Receives a NOTIFY Request 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=0, 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 (4) - resp: NOERROR - flags: QR AA - qcount: 1 - qname: (zone name) - qclass: (zone class) - qtype: T_SOA - - This is intended to be identical to the NOTIFY request, except that - the QR bit is also set. The query ID of the response must be the - same as was received in the request. - - 4.8 Master Receives a NOTIFY Response from Slave - - When a master server receives a NOTIFY response, it deletes this - query from the retry queue, thus completing the "notification - process" of "this" RRset change to "that" server. - - - - - -Vixie Standards Track [Page 6] - -RFC 1996 DNS NOTIFY August 1996 - - -5. Security Considerations - - We believe that the NOTIFY operation's only security considerations - are: - - 1. 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. - - 2. 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. - -6. References - - [RFC1035] - Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [IXFR] - Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996. - -7. Author's Address - - Paul Vixie - Internet Software Consortium - Star Route Box 159A - Woodside, CA 94062 - - Phone: +1 415 747 0204 - EMail: paul@vix.com - - - - - - - - - - - - - - - - - - - -Vixie Standards Track [Page 7] - |
