One document matched: draft-ietf-dnsind-dynDNS-06.txt
Differences from draft-ietf-dnsind-dynDNS-05.txt
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Susan Thomson (Bellcore)
<draft-ietf-dnsind-dynDNS-06.txt> Yakov Rekhter (Cisco)
Jim Bound (DEC)
February 1996
Dynamic Updates in the Domain Name System (DNS UPDATE)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
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 depen-
dency 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.
Expires September 1996 [Page 1]
INTERNET-DRAFT DNS UPDATE February 1996
1 - Definitions
This document intentionally gives more definition to the roles of ``Mas-
ter,'' ``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 [NOTIFY]:
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. 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 struc-
ture. 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
Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH and
RDATA fields are equal, with exceptions as noted below. Note that the
time-to-live (TTL) field is explicitly excluded from the comparison.
The following RR types cannot be checked for identity by simply compar-
ing their data length and data values; instead, the fields within their
data must be compared as follows:
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 dif-
fer.
Expires September 1996 [Page 2]
INTERNET-DRAFT DNS UPDATE February 1996
WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL -- only
one WKS RR is possible for this tuple, even if the services
masks differ.
The rules for comparison of character strings in names are specified in
[RFC1035]. Upper and lower case letters are considered equivalent.
Wildcarding is disabled. That is, a wildcard (``*'') in an update only
matches a wildcard (``*'') in the zone, and vice versa.
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.2 - New Assigned Numbers
CLASS = NONE (TBD: 254?)
RCODE = YXDOMAIN (TBD: 6?)
RCODE = YXRRSET (TBD: 7?)
RCODE = NXRRSET (TBD: 8?)
RCODE = NOTAUTH (TBD: 9?)
Opcode = UPDATE (5)
2 - Update Message Format
The DNS Message Format is defined by [RFC1035 4.1]. Some extensions
were necessary (for example, more error codes are possible under UPDATE
than under QUERY) and some fields were overloaded (see description of
CLASS fields below).
The overall format of our packet 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
+---------------------+
| Reserved | reserved for future use
+---------------------+
Expires September 1996 [Page 3]
INTERNET-DRAFT DNS UPDATE February 1996
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]:
The message is prefixed with a two byte length field which gives the
message length, excluding the two byte length field. This length
field allows the low level processing to assemble a complete message
before beginning to parse it.
The connection management policies in [ibid] are recommended here, as
well.
DNS servers are should be prepared to receive, and respond to, multiple
queries on a TCP connection. The server should only close its side of a
TCP connection when it receives a close from the requestor. Servers
with limited system resources may close their side of a DNS TCP connec-
tion when necessary, at which time the requestor should close its side
and open a new connection when one is needed.
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 mat-
ter 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 our naming and use of these
sections differs as shown in our modified header, after [RFC1035 4.1.1]:
Expires September 1996 [Page 4]
INTERNET-DRAFT DNS UPDATE February 1996
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| XXCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The fields are set as follows in update requests and responses:
ID A 16-bit identifier assigned by the entity that generates any
kind of request. This identifier is copied in the corre-
sponding 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 identi-
fies 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.
Expires September 1996 [Page 5]
INTERNET-DRAFT DNS UPDATE February 1996
RCODE Response code - this four bit field is undefined in requests
and set in responses. The values and semantics of this field
within responses is 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.
NOTAUTH 9? The server is not authoritative for
the zone named in 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.
XXCOUNT The number of RRs in the Reserved Section.
Expires September 1996 [Page 6]
INTERNET-DRAFT DNS UPDATE February 1996
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 will be in the same zone, and there-
fore the Zone Section is allowed to contain exactly one (not zero, not
more than 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 satis-
fied at the time the UPDATE packet is received by the primary master
server. There are five possible semantics that can be expressed here,
summarized as follows and then explained below.
(1) RRset exists (value independent). At least one RR with a speci-
fied NAME and TYPE (in the zone and class specified by the Zone
Section) must exist.
(2) RRset exists (value dependent). A set of RRs with a specified
NAME and TYPE exists and has the same members with the same
RDATA sections 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.
Expires September 1996 [Page 7]
INTERNET-DRAFT DNS UPDATE February 1996
(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 nonter-
minals.
The syntax of these four semantics 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.
For this semantic, a single RR is added to the Prerequisite Section with
a NAME and TYPE equal to that of the RRset whose existence is required.
The RDLENGTH is zero and the RDATA section is therefore empty. CLASS
must be specified as ANY to differentiate this condition from that of an
actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TTL is
specified as zero (0).
2.4.2 - RRset Exists (Value Dependent)
A set of RRs with a specified NAME and TYPE exists and has the same mem-
bers with the same RDATA sections as the RRset specified here in this
section. While RRset ordering is undefined and therefore not signifi-
cant to this comparison, the sets be identical in their extent.
For this semantic, the entire prerequisite RRset is added to the Prereq-
uisite Section. NAME and TYPE are that of the RRset being denoted.
CLASS is that of the zone. TTL must be specified as zero (0) and is
ignored when comparing RRsets for identity.
2.4.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.
For this semantic, a single RR is added to the section with a NAME and
TYPE equal to that of the RRset whose nonexistence is required. The
RDLENGTH of this record is zero (0), and RDATA field is therefore empty.
CLASS must be specified as NONE in order to distinguish this condition
from a valid RR whose RDLENGTH is naturally zero (0) (for example, the
NULL RR). TTL must be specified as zero (0).
Expires September 1996 [Page 8]
INTERNET-DRAFT DNS UPDATE February 1996
2.4.4 - Name Is In Use
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 prereq-
uisite is NOT satisfied by empty nonterminals.
For this semantic, a single RR is added to the Prerequisite Section with
a NAME equal to that of the name whose ownership of an RR is required.
The RDLENGTH is zero and the RDATA section is therefore empty. CLASS
must be specified as ANY to differentiate this condition from that of an
actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE must
be specified as ANY to differentiate this case from that of an RRset
existence test. TTL is specified as zero (0).
2.4.5 - Name Is Not In Use
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.
For this semantic, a single RR is added to the Prerequisite Section with
a NAME equal to that of the name whose nonownership of any RRs is
required. The RDLENGTH is zero and the RDATA section is therefore
empty. CLASS must be specified as NONE. TYPE must be specified as ANY.
TTL must be specified as zero (0).
2.5 - Update Section
This section contains RRs to be added to or deleted from the zone. The
encoding is similar to that used by the Prerequisite Section. There are
four possible semantics, summarized below and with details to follow.
(1) Add RRs to an RRset.
(2) Delete an RRset.
(3) Delete all RRsets from a name.
(4) Delete an RR from an RRset.
The syntax of these four semantics is as follows:
2.5.1 - Add To An RRset
RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH and
RDATA are those being added, and CLASS is the same as the zone class.
Any duplicate RRs will be silently ignored by the primary master.
Expires September 1996 [Page 9]
INTERNET-DRAFT DNS UPDATE February 1996
2.5.2 - Delete An RRset
One RR is added to the Update Section whose NAME and TYPE are those of
the RRset to be deleted. TTL must be specified as zero (0) and is oth-
erwise not used by the primary master. CLASS must be specified as ANY.
RDLENGTH must be zero (0) and RDATA must therefore be empty. If no such
RRset exists, then this Update RR will be silently ignored by the pri-
mary master.
2.5.3 - Delete All RRsets From A Name
One RR is added to the Update Section whose NAME is that of the name to
be cleansed of RRsets. TYPE must be specified as ANY. TTL must be
specified as zero (0) and is otherwise not used by the primary master.
CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA
must therefore be empty. If no such RRsets exist, then this Update RR
will be silently ignored by the primary master.
2.5.4 - Delete An RR From An RRset
RRs to be deleted are added to the Update Section. The NAME, TYPE,
RDLENGTH and RDATA must match the RR being deleted. TTL must be speci-
fied as zero (0) and will otherwise be ignored by the primary master.
CLASS must be specified as NONE to distinguish this from an RR addition.
2.6 - Reserved Section
This section is reserved for use by future extensions to this protocol.
It will be ignored by servers, and made empty by requestors which imple-
ment only the protocol described by this document.
3 - Server Behavior
A server, upon receiving an UPDATE request, will signal NOTIMP to the
requestor if the UPDATE opcode is not recognized or if it is recognized
but has not been implemented. Otherwise, processing continues as fol-
lows.
3.1 - Process Zone Section
3.1.1. The Zone Section is checked to see that there is exactly one RR
therein and that the RR's ZTYPE is SOA, else signal FORMERR to
requestor. Next, the ZNAME and ZCLASS are checked to see if the zone so
named is one of this server's authority zones, else signal NOTAUTH to
requestor. If the server is a zone slave, the request will be forwarded
Expires September 1996 [Page 10]
INTERNET-DRAFT DNS UPDATE February 1996
as explained in Section 6, otherwise the request will be processed by
this server.
3.1.2 - Pseudocode For Zone Section Processing
if (zcount != 1 || ztype != SOA)
return (FORMERR)
if (zone_type(zname, zclass) == SLAVE)
return forward()
if (zone_type(zname, zclass) == MASTER)
return update()
return (NOTAUTH)
Sections 3.2 through 3.8 describe the primary master's behaviour,
whereas Section 6 describes a forwarder's behaviour.
3.2 - Process Prerequisite Section Next, the Prerequisite Section is
checked to see that all prerequisites are satisfied by the current state
of the zone.
3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL
and RDLENGTH are both zero (0) else signal FORMERR to requestor. If
TYPE is ANY, test to see that there is at least one RR in the zone whose
NAME is the same as that of the Prerequisite RR, else signal NXDOMAIN to
the requestor. If TYPE is not ANY, test to see that there is at least
one RR in the zone whose NAME and TYPE are the same as that of the Pre-
requisite RR, else signal NXRRSET to requestor.
3.2.2. For RRs in this section whose CLASS is NONE, test to see that the
TTL and RDLENGTH are both zero (0) else signal FORMERR to requestor. If
the TYPE is ANY, test to see that there are no RRs in the zone whose
NAME is the same as that of the Prerequisite RR, else signal YXDOMAIN to
requestor. If the TYPE is not ANY, test to see that there are no RRs in
the zone whose NAME and TYPE are the same as that of the Prerequisite
RR, else signal YXRRSET to requestor.
3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
test to see that the TTL is zero (0) else signal FORMERR to requestor.
Then, build an RRset for each unique <NAME,TYPE> and compare each
resulting RRset for set equality (same members, no more, no less) with
RRsets in the zone. If any Prerequisite RRset is not entirely and
exactly matched by a zone RRset, signal NXRRSET to requestor. If any RR
in this section has a CLASS other than ZCLASS or NONE or ANY, signal
FORMERR to requestor.
Expires September 1996 [Page 11]
INTERNET-DRAFT DNS UPDATE February 1996
3.2.4 - Table Of Metavalues Used In Prerequisite Section
CLASS TYPE RDATA Semantic
------------------------------------------------------------
ANY ANY empty Name is in use
ANY rrset empty RRset exists (value independent)
NONE ANY empty Name is not in use
NONE rrset empty RRset does not exist
zone rrset rr RRset exists (value dependent)
3.2.5 - Pseudocode for Prerequisite Section Processing
for rr in prerequisites
if (rr.ttl != 0)
return (FORMERR)
if (rr.class == ANY)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (!zone_name<rr.name>)
return (NXDOMAIN)
else
if (!zone_rrset<rr.name, rr.type>)
return (NXRRSET)
if (rr.class == NONE)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (zone_name<rr.name>)
return (YXDOMAIN)
else
if (zone_rrset<rr.name, rr.type>)
return (YXRRSET)
if (rr.class == zclass)
temp<rr.name, rr.type> += rr
else
return (FORMERR)
for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXDOMAIN)
Expires September 1996 [Page 12]
INTERNET-DRAFT DNS UPDATE February 1996
3.3 - Check Requestor's Permissions
3.3.1. Next, the requestor's permission to update the RRs named in the
Update Section may be tested in an implementation dependent fashion or
using mechanisms specified in a subsequent Secure DNS Update protocol.
If the requestor does not have permission to perform these updates, the
server may write a warning message in its operations log, and may either
signal REFUSED to requestor, or ignore the permission problem and pro-
ceed with the update.
3.3.2. While the exact processing is implementation defined, if these
verification activities are to be performed, this is the point in the
server's processing where such performance should take place, since if a
REFUSED condition is encountered after an update has been partially
applied, it will be necessary to undo the partial update and restore the
zone to its original state before answering the requestor.
3.3.3 - Pseudocode for Permission Checking
if (security policy exists)
if (this update is not permitted)
if (local option)
log a message about permission problem
if (local option)
return (REFUSED)
3.4 - Process Update Section
Next, the Update Section is processed as follows.
3.4.1 - Prescan The Update Section is parsed into RRs and each RR's
CLASS is checked to see if it is ANY, NONE, or the same as the Zone
Class, else signal a FORMERR to the requestor.
Expires September 1996 [Page 13]
INTERNET-DRAFT DNS UPDATE February 1996
3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any unrecog-
nized type, then signal FORMERR to the requestor. For RRs whose CLASS
is ANY or NONE, check the TTL to see that it is zero (0), else signal a
FORMERR to the requestor. For any RR whose CLASS is ANY, check the
RDLENGTH to make sure that it is zero (0) (that is, the RDATA field is
empty), and that the TYPE is not AXFR, MAILA, MAILB, or any other QUERY
metatype besides ANY, or any unrecognized type, else signal FORMERR to
the requestor.
3.4.1.3 - Pseudocode For Update Section Prescan
[rr] for rr in updates
if (rr.class == zclass)
if (rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == ANY)
if (rr.ttl != 0 || rr.rdlength != 0
|| rr.type & AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == NONE)
if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
else
return (FORMERR)
3.4.2 - Update The Update Section is parsed into RRs and these RRs are
processed in order.
3.4.2.1. If any system failure (such as an out of memory condition, or a
hardware error in persistent storage) occurs during the processing of
this section, signal SERVFAIL to the requestor and undo all updates
applied to the zone during this transaction.
3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the
zone. In case of duplicate RDATAs (which for SOA RRs is always the
case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields
both match), the Zone RR is replaced by Update RR. If the TYPE is SOA
and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according
to [KRE1996]) than the current Zone SOA RR's SOA.SERIAL, the Update RR
is ignored. In the case of a CNAME Update RR and a non-CNAME Zone RRset
or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME
Zone RR with the CNAME Update RR.
Expires September 1996 [Page 14]
INTERNET-DRAFT DNS UPDATE February 1996
3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all
Zone RRs with the same NAME are deleted, unless the NAME is the same as
ZNAME in which case only those RRs whose TYPE is other than SOA or NS
are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not
ANY all Zone RRs with the same NAME and TYPE are deleted, unless the
NAME is the same as ZNAME in which case neither SOA or NS RRs will be
deleted.
3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME,
TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless
the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is
NS and the matching Zone RR is the only NS remaining in the RRset, in
which case this Update RR is ignored.
3.4.2.5. Signal NOERROR to the requestor.
3.4.2.6 - Table Of Metavalues Used In Update Section
CLASS TYPE RDATA Semantic
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ANY rrset empty Delete an RRset
NONE rrset rr Delete an RR from an RRset
zone rrset rr Add to an RRset
Expires September 1996 [Page 15]
INTERNET-DRAFT DNS UPDATE February 1996
3.4.2.7 - Pseudocode For Update Section Processing
[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)
Expires September 1996 [Page 16]
INTERNET-DRAFT DNS UPDATE February 1996
3.5 - Stability
When a zone is modified by an UPDATE operation, the server must commit
the change to nonvolatile storage before sending a response to the
requestor or answering any queries or transfers for the modified zone.
It is reasonable for a server to store only the update records as long
as a system reboot or power failure will cause these update records to
be incorporated into the zone the next time the server is started. It
is also reasonable for the server to copy the entire modified zone to
nonvolatile storage after each update operation, though this would have
suboptimal performance for large zones.
3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that change
must be in a positive direction (using modulo 2**32 arithmetic as speci-
fied by [KRE1996]). Attempts to replace an SOA with one whose SERIAL is
less than the current one will be silently ignored by the primary master
server.
If the zone's SOA's SERIAL is not changed as a result of an update oper-
ation, then the server shall increment it automatically before the SOA
or any changed name or RR or RRset is included in any response or trans-
fer. The primary master server's implementor might choose to autoincre-
ment the SOA SERIAL if any of the following events occurs:
(1) Each update operation.
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was visi-
ble to a DNS client, and the SOA is about to become visible to a
DNS client.
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third of
the zone refresh time, and the default shall be the lesser of that
maximum and 300 seconds.
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
It is imperative that the zone's contents and the SOA's SERIAL have the
identity mapping. If the zone appears to change, the SOA must appear to
change as well.
Expires September 1996 [Page 17]
INTERNET-DRAFT DNS UPDATE February 1996
3.7 - Atomicity
During the processing of an UPDATE transaction, the server must ensure
atomicity with respect to other (concurrent) UPDATE or QUERY transac-
tions. No two transactions can be processed concurrently if either
depends on the final results of the other; in particular, a QUERY should
not be able to retrieve RRsets which have been partially modified by a
concurrent UPDATE, and an UPDATE should not be able to start from pre-
requisites that might not still hold at the completion of some other
concurrent UPDATE. Finally, if two UPDATE transactions would modify the
same names, RRs or RRsets, then such UPDATE transactions must be serial-
ized.
3.8 - Response
At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields from
the request, and either copying the ZOCOUNT, PRCOUNT, and UPCOUNT fields
and associated sections, or placing zeros (0) in the these ``count''
fields and not including any part of the original update. The XXCOUNT
will be set to zero (0) the Reserved Section will be made empty in
responses, no matter what was present in the request. The QR bit is set
to one (1), and the response is sent back to the requestor. If the
requestor used UDP, then the response will be sent to the requestor's
source UDP port. If the requestor used TCP, then the response will be
sent back on the requestor's open TCP connection.
4 - Requestor Behaviour
4.1. From a requestor's point of view, any authoritative server for the
zone can appear to be able to process update requests, even though only
the primary master server is actually able to modify the zone's master
file. Requestors are expected to know the name of the zone they intend
to update and to know or be able to determine the name servers for that
zone.
4.2. If update ordering is desired, the requestor will need to know the
value of the existing SOA RR. Requestors who update the SOA RR must
update the SOA SERIAL field in a positive direction (as defined by
[KRE1996]) and to preserve the other SOA fields unless the requestor's
explicit intent is to change them. The SOA SERIAL field must never be
set to zero (0).
Expires September 1996 [Page 18]
INTERNET-DRAFT DNS UPDATE February 1996
4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to try
the primary master server (as given by the SOA MNAME field if matched by
some NS NSDNAME) first to avoid unnecessary forwarding inside the slave
servers. (Note that the primary master will in some cases not be reach-
able by all requestors, due to firewalls or network partitioning.)
4.4. Once the zone's name servers been found and possibly sorted so that
the ones more likely to be reachable and/or support the UPDATE opcode
are listed first, the requestor composes an UPDATE message of the fol-
lowing form and sends it to the first name server on its list:
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Reserved Section: (empty)
4.5. If the requestor receives a response, and the response has an RCODE
other than SERVFAIL or NOTIMP, then the resolver returns an appropriate
response to its caller.
4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or if
no response is received within an implementation dependent timeout
period, or if an ICMP error is received indicating that the server's
port is unreachable, then the requestor will delete the unusable server
from its internal name server list and try the next one, repeating until
the name server list is empty. If the requestor runs out of servers to
try, an appropriate error will be returned to the requestor's caller.
5 - Duplicate Detection, Ordering and Mutual Exclusion
5.1. For correct operation, mechanisms may be needed to ensure idempo-
tence, order UPDATE requests and provide mutual exclusion. This is due
to DNS's use of UDP, a datagram protocol which does not ensure reliable
delivery. An UPDATE message or response might be delivered zero times,
one time, or multiple times. Datagram duplication is of particular
interest since it covers the case of the so-called ``replay attack''
where a correct request is duplicated maliciously by an intruder.
Expires September 1996 [Page 19]
INTERNET-DRAFT DNS UPDATE February 1996
5.2. Multiple UPDATE requests or responses in transit might be delivered
in any order, due to network topology changes or load balancing, or to
multipath forwarding graphs wherein several slave servers all forward to
the primary master. In some cases, it might be required that the ear-
lier update not be applied after the later update, where ``earlier'' and
``later'' are defined by an external time base visible to some set of
requestors, rather than by the order of request receipt at the primary
master.
5.3. A requestor can ensure transaction idempotence by explicitly delet-
ing some ``marker RR'' (rather than deleting the RRset of which it is a
part) and then adding a new ``marker RR'' with a different RDATA field.
The Prerequisite Section should specify that the original ``marker RR''
must be present in order for this UPDATE message to be accepted by the
server.
5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original ``marker
RR'' present and having its known previous value. The decisions of
whether to use such a ``marker RR'' and what RR to use are left up to
the application programmer, though one obvious choice is the zone's SOA
RR as described below.
5.5. Requestors can ensure update ordering by externally synchronizing
their use of successive values of the ``marker RR.'' Mutual exclusion
can be addressed as a degenerate case, in that a single succession of
the ``marker RR'' is all that is needed.
5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then back
to its previous value. Without a ``marker RR'' as described above, this
sequence of updates can leave the zone in an undefined state if data-
grams are duplicated.
5.7. To achieve an atomic multitransaction ``read-modify-write'' cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE message
one of whose prerequisites was the old SOA RR. It would then specify
updates that would delete this SOA RR and add a new one with an incre-
mented SOA SERIAL, along with whatever actual prerequisites and updates
were the object of the transaction. If the transaction succeeds, the
requestor knows that the RRs being changed were not otherwise altered by
any other requestor.
Expires September 1996 [Page 20]
INTERNET-DRAFT DNS UPDATE February 1996
6 - Forwarding
When a zone slave forwards an UPDATE message upward toward the zone's
primary master server, it must allocate a new ID and prepare to enter
the role of ``forwarding server'', which is a requestor with respect to
the forward server.
6.1. The set of forward servers will be same as the set of servers this
zone slave would use as the source of AXFR or IXFR data. So, while the
original requestor might have used the zone's NS RRset to locate its
update server, a forwarder always forwards toward its designated zone
master servers.
6.2. If the original requestor used TCP, then the TCP connection from
the requestor is still open and the forwarder must use TCP to forward
the message. If the original requestor used UDP, the forwarder may use
either UDP or TCP to forward the message, depending on the implementa-
tion.
6.3. It is reasonable for forward servers to be forwarders themselves,
if the AXFR dependency graph being followed is a deep one involving
firewalls and multiple connectivity realms. In most cases the AXFR
dependency graph will be shallow and the forward server will be the pri-
mary master server.
6.4. The forwarder will not respond to its requestor until it receives a
response from its forward server. UPDATE transactions involving for-
warders are therefore time synchronized with respect to the original
requestor and the primary master server.
6.5. When there are multiple possible sources of AXFR data and therefore
multiple possible forward servers, a forwarder will use the same fall-
back strategy with respect to connectivity or timeout errors that it
would use when performing an AXFR. This is implementation dependent.
6.6. When a forwarder receives a response from a forward server, it
copies this response into a new response message, assigns its
requestor's ID to that message, and sends the response back to the
requestor.
Expires September 1996 [Page 21]
INTERNET-DRAFT DNS UPDATE February 1996
7 - Design and Implementation Notes
Some of the principles which guided the design of this UPDATE specifica-
tion are as follows. Note that these are not part of the formal speci-
fication and any disagreement between this section and any other section
of this document should be resolved in favour of the other section.
7.1. Using metavalues for CLASS is possible only because all RRs in the
packet are assumed to be in the same zone, and CLASS is an attribute of
a zone rather than of an RRset. (It is for this reason that the Zone
Section is not optional.)
7.2. Since there are no data-present or data-absent errors possible from
processing the Update Section, it is necessary to state data-present and
data-absent dependencies in the Prerequisite Section.
7.3. The Reserved Zone might be used if some of the RRs later needed for
Secure DNS Update are not actually zone updates, but rather ancillary
keys or signatures not intended to be stored in the zone (as an update
would be), yet necessary for validating the update operation.
7.4. It is expected that in the absence of Secure DNS Update, a server
will only accept updates if they come from a source address that has
been statically configured in the server's description of a primary mas-
ter zone. DHCP servers would be likely candidates for inclusion in this
statically configured list.
7.5. It is not possible to create a zone using this protocol, since
there is no provision for a slave server to be told who its master
servers are. It is expected that this protocol will be extended in the
future to cover this case. Therefore, at this time, the addition of SOA
RRs is unsupported. For similar reasons, deletion of SOA RRs is also
unsupported.
7.6. The prerequisite for specifying that a name own at least one RR
differs semantically from QUERY, in that QUERY would return <NOER-
ROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at this
name, while our prerequisite condition [Section 2.4.4] would NOT be sat-
isfied.
7.7. It is possible for a UDP response to be lost in transit and for a
request to be retried due to a timeout condition. In this case an
UPDATE that was successful the first time it was received by the primary
master might ultimately appear to have failed when the response to a
duplicate request is finally received by the requestor. (This is
Expires September 1996 [Page 22]
INTERNET-DRAFT DNS UPDATE February 1996
because the original prerequisites may no longer be satisfied after the
update has been applied.) For this reason, requestors who require an
accurate response code must use TCP.
7.8. Because a requestor who requires an accurate response code will
initiate their UPDATE transaction using TCP, a forwarder who receives a
request via TCP must forward it using TCP.
7.9. Deferral of SOA SERIAL autoincrements is made possible so that
serial numbers can be conserved and wraparound at 2**32 can be made an
infrequent occurance. Visible (to DNS clients) SOA SERIALs need to dif-
fer if the zone differs. Note that the Authority Section SOA in a QUERY
response is a form of visibility, for the purposes of this semantic.
7.10. A zone's SOA SERIAL should never be set to zero (0) due to inter-
operability problems with some older but widely installed implementa-
tions of DNS. When incrementing an SOA SERIAL, if the result of the
increment is zero (0) (as will be true when wrapping around 2**32), it
is necessary to increment it again or set it to one (1). See [KRE1996]
for more detail on this subject.
7.11. Due to the TTL minimalization necessary when caching an RRset, it
is recommended that all TTLs in an RRset be set to the same value.
While the DNS Message Format permits variant TTLs to exist in the same
RRset, and this variance can exist inside a zone, such variance will
have counterintuitive results and its use is discouraged.
7.12. Zone cut management presents some obscure corner cases to the add
and delete semantics in the Update Section. It is possible to delete an
NS RR as long as it's not the last RR in the RRset. If deleting all RRs
from a name, SOA and NS RRs at the top of a zone are unaffected. If
deleting RRsets, it is not possible to delete either SOA or NS RRsets at
the top of a zone. An attempt to add an SOA will be treated as a
replace operation.
7.13. The Reserved Section in requests will be made empty by requestors,
passed through unchanged by forwarders and ignored by primary master
servers. The Reserved Section in responses will be made empty by pri-
mary master servers, ignored by forwarders, and ignored by requestors.
This is intended to make it possible for future requestor specifications
to use this section as a way to determine that a response was generated
according to a future primary master server specification.
Expires September 1996 [Page 23]
INTERNET-DRAFT DNS UPDATE February 1996
7.14. No semantic checking is required in the primary master server when
adding new RRs. Therefore a requestor can cause CNAME or NS or any
other kind of RR to be added even if their target name does not exist or
does not have the proper RRsets to make the original RR useful. Primary
master servers which implement this kind of checking should take great
care to avoid out-of-zone dependencies (whose veracity cannot be author-
itatively checked) or signals to the requestor during processing of the
Update Section after the prescan.
7.15. Nonterminal or wildcard CNAMEs are not well specified by RFC 1035
and their use will probably lead to unpredictable results. Their use is
discouraged.
7.16. Before adding a delegation to a zone, all RRsets at or below the
new zone cut should be removed, except for ``glue'' which are A RRs
below the zone cut which are targets of NS RRs at the zone cut.
7.17. A primary server implementation may choose to perform part of its
permission checking during the Update Section processing. This may be
needed if the permissions won't be known until the final form of an
RRset is known. In this case, a primary server can signal REFUSED to
the requestor as long as it also undoes all partial updates and restores
the zone to its original state.
8 - Security Considerations
In the absence of DNS Security, the protocol described by this document
makes it possible for anyone who can reach an authoritative name server
to alter the contents of a zone. This strongly indicates a need for out
of band access control such as static access control lists enforced by
the server, or firewall techniques, or both.
At the time of this writing, work is progressing (see [DNSSEC]) on the
general problem of DNS Security; however, no specification exists (at
this time) for updating security related RRs, or for using security
related RRs to control UPDATE access.
Acknowledgements
We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
Masataka Ohta, Mark Andrews, and Robert Elz.
Expires September 1996 [Page 24]
INTERNET-DRAFT DNS UPDATE February 1996
References
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specification,''
RFC 1035, USC/Information Sciences Institute, November 1987.
[DNSSEC]
Donald E. Eastlake and Charles W. Kaufman, ``Domain Name System Pro-
tocol Security Extensions,'' Internet Draft, December 1995, <draft-
ietf-dnssec-secext-09.txt>.
[IXFR]
M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, July 1995,
<draft-ietf-dnsind-ixfr-02.txt>.
[NOTIFY]
P. Vixie, ``Notify: a mechanism for prompt notification of authority
zone changes,'' Internet Draft, March 1995, <draft-ietf-dnsind-
notify-01.txt>.
[KRE1996]
Robert Elz, unpublished I-D
Authors' Addresses
Yakov Rekhter Susan Thomson
Cisco Systems Bellcore
170 West Tasman Drive 445 South Street
San Jose, CA 95134-1706 Morristown, NJ 07960
+1 914 528 0090 +1 201 829 4514
<yakov@cisco.com> <set@thumper.bellcore.com>
Jim Bound Paul Vixie
Digital Equipment Corp. Internet Software Consortium
110 Spitbrook Rd ZK3-3/U14 Star Route Box 159A
Nashua, NH 03062-2698 Woodside, CA 94062
+1 603 881 0400 +1 415 747 0204
<bound@zk3.dec.com> <paul@vix.com>
Expires September 1996 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-22 18:41:27 |