📄 rfc2136.txt
字号:
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.
Vixie, et. al. Standards Track [Page 1]
RFC 2136 DNS Update April 1997
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. 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.
A domain name identifies a node within the domain name space tree
structure. Each node has a set (possibly empty) of Resource Records
(RRs). All RRs having the same NAME, CLASS and TYPE are called a
Resource Record Set (RRset).
The pseudocode used in this document is for example purposes only.
If it is found to disagree with the text, the text shall be
considered authoritative. If the text is found to be ambiguous, the
pseudocode can be used to help resolve the ambiguity.
1.1 - Comparison Rules
1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
RDLENGTH and RDATA fields are equal. Note that the time-to-live
(TTL) field is explicitly excluded from the comparison.
1.1.2. The rules for comparison of character strings in names are
specified in [RFC1035 2.3.3].
1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an
update only matches a wildcard ("*") in the zone, and vice versa.
1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
the update, and will not otherwise be followed. All UPDATE
operations are done on the basis of canonical names.
1.1.5. The following RR types cannot be appended to an RRset. If the
following comparison rules are met, then an attempt to add the new RR
will result in the replacement of the previous RR:
SOA compare only NAME, CLASS and TYPE -- it is not possible to
have more than one SOA per zone, even if any of the data
fields differ.
WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-- only one WKS RR is possible for this tuple, even if the
services masks differ.
Vixie, et. al. Standards Track [Page 2]
RFC 2136 DNS Update April 1997
CNAME compare only NAME, CLASS, and TYPE -- it is not possible
to have more than one CNAME RR, even if their data fields
differ.
1.2 - Glue RRs
For the purpose of determining whether a domain name used in the
UPDATE protocol is contained within a specified zone, a domain name
is "in" a zone if it is owned by that zone's domain name. See
section 7.18 for details.
1.3 - New Assigned Numbers
CLASS = NONE (254)
RCODE = YXDOMAIN (6)
RCODE = YXRRSET (7)
RCODE = NXRRSET (8)
RCODE = NOTAUTH (9)
RCODE = NOTZONE (10)
Opcode = UPDATE (5)
2 - Update Message Format
The DNS Message Format is defined by [RFC1035 4.1]. Some extensions
are necessary (for example, more error codes are possible under
UPDATE than under QUERY) and some fields must be overloaded (see
description of CLASS fields below).
The overall format of an UPDATE message is, following [ibid]:
+---------------------+
| Header |
+---------------------+
| Zone | specifies the zone to be updated
+---------------------+
| Prerequisite | RRs or RRsets which must (not) preexist
+---------------------+
| Update | RRs or RRsets to be added or deleted
+---------------------+
| Additional Data | additional data
+---------------------+
Vixie, et. al. Standards Track [Page 3]
RFC 2136 DNS Update April 1997
The Header Section specifies that this message is an UPDATE, and
describes the size of the other sections. The Zone Section names the
zone that is to be updated by this message. The Prerequisite Section
specifies the starting invariants (in terms of zone content) required
for this update. The Update Section contains the edits to be made,
and the Additional Data Section contains data which may be necessary
to complete, but is not part of, this update.
2.1 - Transport Issues
An update transaction may be carried in a UDP datagram, if the
request fits, or in a TCP connection (at the discretion of the
requestor). When TCP is used, the message is in the format described
in [RFC1035 4.2.2].
2.2 - Message Header
The header of the DNS Message Format is defined by [RFC 1035 4.1].
Not all opcodes define the same set of flag bits, though as a
practical matter most of the bits defined for QUERY (in [ibid]) are
identically defined by the other opcodes. UPDATE uses only one flag
bit (QR).
The DNS Message Format specifies record counts for its four sections
(Question, Answer, Authority, and Additional). UPDATE uses the same
fields, and the same section formats, but the naming and use of these
sections differs as shown in the following modified header, after
[RFC1035 4.1.1]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Vixie, et. al. Standards Track [Page 4]
RFC 2136 DNS Update April 1997
These fields are used as follows:
ID A 16-bit identifier assigned by the entity that generates any
kind of request. This identifier is copied in the
corresponding reply and can be used by the requestor to match
replies to outstanding requests, or by the server to detect
duplicated requests from some requestor.
QR A one bit field that specifies whether this message is a
request (0), or a response (1).
Opcode A four bit field that specifies the kind of request in this
message. This value is set by the originator of a request
and copied into the response. The Opcode value that
identifies an UPDATE message is five (5).
Z Reserved for future use. Should be zero (0) in all requests
and responses. A non-zero Z field should be ignored by
implementations of this specification.
RCODE Response code - this four bit field is undefined in requests
and set in responses. The values and meanings of this field
within responses are as follows:
Mneumonic Value Description
------------------------------------------------------------
NOERROR 0 No error condition.
FORMERR 1 The name server was unable to interpret
the request due to a format error.
SERVFAIL 2 The name server encountered an internal
failure while processing this request,
for example an operating system error
or a forwarding timeout.
NXDOMAIN 3 Some name that ought to exist,
does not exist.
NOTIMP 4 The name server does not support
the specified Opcode.
REFUSED 5 The name server refuses to perform the
specified operation for policy or
security reasons.
YXDOMAIN 6 Some name that ought not to exist,
does exist.
YXRRSET 7 Some RRset that ought not to exist,
does exist.
NXRRSET 8 Some RRset that ought to exist,
does not exist.
Vixie, et. al. Standards Track [Page 5]
RFC 2136 DNS Update April 1997
NOTAUTH 9 The server is not authoritative for
the zone named in the Zone Section.
NOTZONE 10 A name used in the Prerequisite or
Update Section is not within the
zone denoted by the Zone Section.
ZOCOUNT The number of RRs in the Zone Section.
PRCOUNT The number of RRs in the Prerequisite Section.
UPCOUNT The number of RRs in the Update Section.
ADCOUNT The number of RRs in the Additional Data Section.
2.3 - Zone Section
The Zone Section has the same format as that specified in [RFC1035
4.1.2], with the fields redefined as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ZNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ZCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UPDATE uses this section to denote the zone of the records being
updated. All records to be updated must be in the same zone, and
therefore the Zone Section is allowed to contain exactly one record.
The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
the zone's class.
2.4 - Prerequisite Section
This section contains a set of RRset prerequisites which must be
satisfied at the time the UPDATE packet is received by the primary
master server. The format of this section is as specified by
[RFC1035 4.1.3]. There are five possible sets of semantics that can
be expressed here, summarized as follows and then explained below.
(1) RRset exists (value independent). At least one RR with a
specified NAME and TYPE (in the zone and class specified by
the Zone Section) must exist.
Vixie, et. al. Standards Track [Page 6]
RFC 2136 DNS Update April 1997
(2) RRset exists (value dependent). A set of RRs with a
specified NAME and TYPE exists and has the same members
with the same RDATAs as the RRset specified here in this
Section.
(3) RRset does not exist. No RRs with a specified NAME and TYPE
(in the zone and class denoted by the Zone Section) can exist.
(4) Name is in use. At least one RR with a specified NAME (in
the zone and class specified by the Zone Section) must exist.
Note that this prerequisite is NOT satisfied by empty
nonterminals.
(5) Name is not in use. No RR of any type is owned by a
specified NAME. Note that this prerequisite IS satisfied by
empty nonterminals.
The syntax of these is as follows:
2.4.1 - RRset Exists (Value Independent)
At least one RR with a specified NAME and TYPE (in the zone and class
specified in the Zone Section) must exist.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -