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: 2000-Sep-13
Document File: 6 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Vixie: AUTHOR

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 19% 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].

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