Browse Prior Art Database

A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (RFC1996)

IP.com Disclosure Number: IPCOM000004206D
Original Publication Date: 1996-Aug-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 7 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Vixie: AUTHOR

Related Documents

10.17487/RFC1996: DOI

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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 25% of the total text.

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. Th...

Processing...
Loading...