Browse Prior Art Database

Dynamic Updates in the Domain Name System (DNS UPDATE) (RFC2136)

IP.com Disclosure Number: IPCOM000002691D
Original Publication Date: 1997-Apr-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 20 page(s) / 52K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Vixie: AUTHOR [+5]

Abstract

The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 5% of the total text.

Network Working Group P. Vixie, Editor

Request for Comments: 2136 ISC

Updates: 1035 S. Thomson

Category: Standards Track Bellcore

Y. Rekhter

Cisco

J. Bound

DEC

April 1997

Dynamic Updates in the Domain Name System (DNS UPDATE)

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

The Domain Name System was originally designed to support queries of

a statically configured database. While the data was expected to

change, the frequency of those changes was expected to be fairly low,

and all updates were made as external edits to a zone's Master File.

Using this specification of the UPDATE opcode, it is possible to add

or delete RRs or RRsets from a specified zone. Prerequisites are

specified separately from update operations, and can specify a

dependency upon either the previous existence or nonexistence of an

RRset, or the existence of a single RR.

UPDATE is atomic, i.e., all prerequisites must be satisfied or else

no update operations will take place. There are no data dependent

error conditions defined after the prerequisites have been met.

1 - Definitions

This document intentionally gives more definition to the roles of

"Master," "Slave," and "Primary Master" servers, and their

enumeration in NS RRs, and the SOA MNAME field. In that sense, the

following server type definitions can be considered an addendum to

[RFC1035], and are intended to be consistent with [RFC1996]:

Slave an authoritative server that uses AXFR or IXFR to

retrieve the zone and is named in the zone's NS

RRset.

Master an authoritative server configured to be the

source of AXFR or IXFR data for one or more slave

servers.

Primary Master master server at the root of the AXFR/IXFR

dependency graph. ...