One document matched: draft-ietf-dnsind-dynDNS-04.txt
Differences from draft-ietf-dnsind-dynDNS-03.txt
DNSIND Working Group Susan Thomson (Bellcore)
INTERNET-DRAFT Yakov Rekhter (Cisco)
<draft-ietf-dnsind-dynDNS-04.txt> Jim Bound (DEC)
Paul Vixie (ISC)
October 1995
Dynamic Updates in the Domain Name System (DNS)
Status of this Memo
This document is a submission to the dnsind Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the namedroppers@internic.net mailing list.
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
munnari.oz.au.
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 document describes extensions to the Domain Name System that
allow zone changes to be made dynamically by clients. The extensions
provide support for adding and deleting names and associated resource
records.
Expires May, 1996 [Page 1]
INTERNET-DRAFT DNS UPDATE October 1995
1.0 - 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 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. All
slave servers are named in the NS RRs for the zone.
Primary Master master server at the root of the zone transfer depen-
dency 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)
called a Resource Record Set (RRset.)
An update request is an atomic transaction consisting of a sequence of
operations on a set of names and RRs in a zone. There are four types of
update operations:
ADDNAMENEW Add a new name and a set of RRs to a zone.
This operation is only successful if the name does not
already exist. The effect of the operation is to cre-
ate a new node in the name space and add records to
this node. The existence rules are described in more
detail below.
ADDNAMEEXIST Add new RRs to an existing name in a zone.
This operation is only successful if the name already
exists. The effect of the operation is to add to the
RRset of a previously existing node in the name space.
Expires May, 1996 [Page 2]
INTERNET-DRAFT DNS UPDATE October 1995
ADD Add RRs to a possibly new name in a zone.
If the name already exists, then the semantics of this
operation are the same as ADDNAMEEXIST. If the name
does not exist, then the semantics of this operation
are the same as ADDNAMENEW.
DELETE Delete records from zone.
This operation is only successful if the specified
records exist. It is also possible to specify a wild-
card such that all resource records denoted by a
{name,class,type} can be deleted without specifying
each and every one of them.
For simplicity, the above definitions have been written as if an opera-
tion can only be applied to a single node at a time. While this may be
the way the mechanisms are used intuitively, this mode of operation is
not mandatory. Each operation may be applied to a set of records with
different names and types. However, the records must all be of the same
class and zone (see below).
UPDATE transactions have the following properties:
Atomicity The effect of an update request is to perform all of the
operations in the transaction, if all can be performed
successfully, or none at all. However, the effects of a
previous operation on a particular record in an update
request are visible to subsequent operations on records in
that request, i.e. the zone is updated incrementally,
albeit tentatively, as the update is processed. An excep-
tion is made in the case of the ADDNAMENEW operation: it
is permissible to add multiple records associated with a
new name using this operation. (See the Name Server
Behavior and Example sections for further clarification.)
Stability A successful update means that no errors were detected and
that the update has been applied to the zone by the pri-
mary master server, and has been committed to stable stor-
age. Updates are applied to slave servers asynchronously
(see Section 3.)
Scope All records updated in a request must be contained within
a single zone, and hence all must have the same class.
Expires May, 1996 [Page 3]
INTERNET-DRAFT DNS UPDATE October 1995
Coherence The zone serial number is updated as a side effect of an
update request (unless explicitly updated as part of the
request), but this may be done either at the time of the
update or asynchronously, at the discretion of the primary
master server (see Section 3.) This does not change cache
coherence, which depends on the TTL field of cached
records, but it does guarantee a direct mapping between
authority zone contents and zone serial numbers.
1.1 - Resource Record Comparison Rules
The four types of update operations depend on comparing for equality an
existing record with a record included in an update. For example, the
DELETE operation requires that the record exist before it is deleted,
and ADD* operations must be idempotent.
Two RRs are considered equal if their name, type, data length and data
value are the same, 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 and type (SOA) -- it is not possible to have
more than one SOA per zone, even if the data fields differ.
SIG compare only name, type, type covered, signer's name, key, and
algorithm -- ignore differences (if any) in the signature data
itself.
WKS compare only name, type, address, and protocol -- only one WKS
RR is possible for this tuple, ignoring differences in the ser-
vices mask.
The rules for comparison of character strings in names and in data
fields are specified in [RFC1035]. For two names to match, they must
match label by label. Wildcarding is one-way: a wildcard in an update
record will match any zone label, but a wildcard in the zone matches
only a wildcard in the update.
Expires May, 1996 [Page 4]
INTERNET-DRAFT DNS UPDATE October 1995
1.2 - Wildcard Data Resource Record
In a DELETE operation, it is sometimes convenient to specify that all
records associated with a certain name that are of a given class and
type be deleted, without specifying all existing records explicitly. In
DELETE operations, therefore, a record with a wildcard time-to-live
(TTL) of * (see below for encoding) and a zero (0) length data field is
considered a match for any records of the same name, class and type.
For the purpose of determining whether a DELETE operation was success-
ful, the wildcard also matches the empty set.
The wildcard TTL field is encoded as follows:
* (2^32) - 1 wildcard TTL field used in DELETE
operation to delete all records
of the same name, class and type.
An exception is made for SIG RRs since their identifying tuple includes
their "type signed" field. Therefore, an update record with a TTL of *,
a type of SIG, and data length of zero (0) will not match any zone
records. To specify a wildcard for SIG RR deletion, use a TTL of *, a
type of SIG, a data length of two (2), and a data field containing only
the "type signed."
A wildcard resource record is only useful in a DELETE request; the
record is not valid in a zone or in any other type of update request.
2.0 - Update Message Format
An update message has a header and optionally a body. Update requests
have both a header and a body; update responses contain just the header.
The message header has a similar format to that of QUERY [RFC1035]. The
message body consists of a variable number of sections, defined below.
This document defines the following section types:
ZONEAUTHORITY Supplies the SOA RR of the zone to be updated.
DELETE Specifies records to be deleted.
ADDNAMENEW Supplies records (with new names) to be added.
ADDNAMEEXIST Supplies records (with existing names) to be added.
ADD Supplies records (with new or existing names) to be
added.
Expires May, 1996 [Page 5]
INTERNET-DRAFT DNS UPDATE October 1995
If an update request contains a ZONEAUTHORITY section, this section must
appear first in the message body, and a maximum of one (1) such section
is allowed. The other section types can be used in any order and can be
used any number of times. Not all section types need be used in every
update message.
2.1 - Transport Issues
An update transaction may be carried in UDP datagrams, 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] (Sec-
tion 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 management policies in [ibid] are recommended here, as well.
It is not recommended that more than one transaction be performed over a
single TCP connection, since [ibid] did not define this case and no
known server implements it for QUERY messages. After completing each
UPDATE transaction, the TCP connection should be closed.
2.2 - Header Format
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The update header is smaller and simpler than the QUERY header described
in [RFC1035] (Section 4.1.1.) There are no section count fields in the
message header, since the sections in the message body are self-encoded.
However, the Opcode field is in the same location as for QUERY [ibid]
since this is the field used to demultiplex the message's type and
thereby interpret its format.
Expires May, 1996 [Page 6]
INTERNET-DRAFT DNS UPDATE October 1995
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 up
replies to outstanding requests.
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. Must be zero in all requests and
responses. A non-zero Z field should be treated as a format
error.
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:
Expires May, 1996 [Page 7]
INTERNET-DRAFT DNS UPDATE October 1995
(RCODE values, cont'd)
0 (No Error)
No error condition.
1 (Format Error)
The name server was unable to interpret the request.
2 (Server Failure)
The name server encountered an internal failure while processing
this request, for example an operating system error or a forward-
ing timeout.
3 (Name Error)
This code indicates that a domain name does not exist. This
return code is only meaningful from a server in response to a
ADDNAMEEXIST or DELETE operation.
4 (Not Implemented)
The name server does not support the specified Opcode.
5 (Refused)
The name server refuses to perform the specified operation for
policy or security reasons.
6 (Alias Error)
This code indicates that a domain name specified in an update is
an alias.
7 (Name Exists Error)
The name specified by an ADDNAMENEW operation already exists.
8 (Record Error)
The record specified by a DELETE operation does not exist.
9 (Zone Error)
The name specified by an update operation is not in any of the
server's authority zones, or is in more than one authority zone
(i.e., at a zone cut) and no disambiguating ZONEAUTHORITY section
is present.
10 (Ordering Error)
If an ordering mechanism is used (e.g. a SIG RR, or a SOA RR),
this code is used to indicate an ordering error.
Expires May, 1996 [Page 8]
INTERNET-DRAFT DNS UPDATE October 1995
2.3 - Section Format
Each section contains a type code (range: 0-15), followed by a count
field (range: 0-4095, in units of RRs), followed by that number of RRs.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Type Code | Count |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
// //
// "Count" RRs //
// //
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
This document defines the following section type codes:
1 DELETE
2 ADDNAMENEW
3 ADDNAMEEXIST
4 ADD
5 ZONEAUTHORITY
The Count field is a 12-bit unsigned integer in network byte order con-
taining the number of RRs in the section. For the ZONEAUTHORITY section
the only legal value of the Count field is one (1).
3.0 - Name Server Behavior
On receiving an update request, a name server checks to see whether the
UPDATE opcode is implemented. If not the name server returns Not Imple-
mented and terminates the transaction.
Note:
This describes the behaviour of all correct implementations of prior
specifications, since the Not Implemented encoding (its value and its
placement within the response packet) is the same as for QUERY.
If a ZONEAUTHORITY section was included in the request, and any nodes to
be updated (as specified in the other sections) are not within the zone
or at a ``zone cut'' (see [RFC1034] section 4.2) of the zone specified
by the ZONEAUTHORITY section's SOA RR, or if the ZONEAUTHORITY section's
SOA RR names a zone for which the server is not authoritative, then the
server returns a Zone Error.
Expires May, 1996 [Page 9]
INTERNET-DRAFT DNS UPDATE October 1995
If no ZONEAUTHORITY section was included in the request, and the collec-
tion of nodes intended to be updated by the other sections fails to lie
completely and unambiguously within a single zone for which the server
is authoritative, then the server returns a Zone Error.
Discussion:
Zone cuts present an ambiguous location for the purposes of UPDATE,
since a server that is authoritative for both the parent and child
zones around a cut would not know which zone to apply the updates to.
The ZONEAUTHORITY section is used to resolve the ambiguity, and
should be specified whenever the records to be updated might be
located on a zone cut. It is also acceptable to simply include a
ZONEAUTHORITY section with all update requests.
If the server is a slave for the zone containing the nodes to be
updated, then the server forwards the request to the master server from
which it most recently fetched (via AXFR or IXFR) the zone, and awaits a
response. If no response is received within an administrator config-
urable period, then the server returns Server Failure. If a response is
received, then the server forwards this response back to the request's
initiator.
Discussion:
Only the primary master server can apply updates since only that
server has access to the zone's master file or other external data
source. The rest of the authoritative servers for the updated zone
will receive the update in the form of an AXFR or IXFR, perhaps aided
by a NOTIFY.
Note:
If a request is received via TCP and must be forwarded, then the ini-
tiating server's TCP connection will be open for the entire period of
the forwarding operation (or until a timeout occurs.) To prevent
resource starvation in the host operating system, it is recommended
that the timeout period's default be on the order of 10 seconds.
If the server is the primary master for the zone containing the nodes to
be updated, then processing continues as follows: For each record in
the update request start matching down on the record name (RRNAME),
label by label, right to left. For each label, test for the following
cases:
Expires May, 1996 [Page 10]
INTERNET-DRAFT DNS UPDATE October 1995
1. If the whole name is matched, we have found the node to be updated:
If the record at the node is an alias (CNAME), and the type of the
update record (RRTYPE) is not CNAME, abort the transaction and return
a response indicating an Alias Error.
If the operation is DELETE, check if the specified record exists in
the zone using the rules in Section 1.1. If not, abort the transac-
tion and return a response indicating a Record Error.
If the operation is ADDNAMENEW, and the name existed before this
transaction was begun, abort the transaction and return a response
indicating a Name Exists Error. If the name exists only because of
this transaction, treat this ADDNAMENEW as an ADDNAMEEXIST.
If the operation is ADDNAMEEXIST or ADD, check if the specified
record already exists using the rules in Section 1.1. If the record
is a duplicate, ignore, unless the record is an SOA, SIG or WKS
record, in which case replace the existing RR with this update RR.
Perform the update operation tentatively.
2. If at some label, a match is impossible (i.e. the label does not
exist), and the operation is ADDNAMEEXIST or DELETE, abort the trans-
action and return a response indicating a Name Error.
If the operation is ADDNAMENEW or ADD, perform the update operation
tentatively.
Note:
The existence checks are applied to the state of the zone as modified
by this update request so far, with the exception of ADDNAMENEW as
specified above.
If the default (``SIG'') ordering mechanism is in use (see Section 5),
then the name server checks that the SIG RRs associated with the node
have been updated for each {name,class,type} updated, and that the "time
signed" field has been set to an appropriate value as specified in Sec-
tion 5. If not, the name server aborts the transaction with an Ordering
Error. Note that if all records of a given {name,class,type} are
deleted, then the SIG RR will cover the empty set. The SIG RR should be
retained for as long as the timestamp in the "time signed" field is
deemed to be reasonably current. This ensures that subsequent updates
use large enough timestamps for ordering purposes.
Expires May, 1996 [Page 11]
INTERNET-DRAFT DNS UPDATE October 1995
If the SOA ordering mechanism is in use (see Section 5), then the name
server must ensure that the serial number has been updated appropriately
(see Section 5). If not, the name server aborts the transaction with an
Ordering Error.
If no errors have been found, the name server commits the transaction.
If the zone serial number has not been explicitly updated as part of the
transaction, the zone serial number may or may not be updated at this
time (see Section 3.1). The name server returns a successful response.
Note:
At the start of a transaction, the primary master server must lock
the zone to prevent concurrent interleaving of query and update
requests. The zone is unlocked at the end of a (successful or unsuc-
cessful) transaction. Aborting a transaction requires that any
changes made so far must be rolled back. For the purpose of this
document committing a transaction means that the changes are made
persistent (e.g. written out to stable storage), and are visible to
subsequent queries to the primary master.
3.1 - Incrementing the Zone Serial Number
If the zone serial number is not explicitly updated in a request, a pri-
mary master server may update the zone serial number when committing
each transaction, or periodically, after some number of transactions or
time has passed, depending on policy as defined below.
Discussion:
Updating the serial number periodically makes it possible to slow
incrementing of the serial number in situations where many updates
occur close together in time.
Note:
This document imposes a limit on how slowly the zone serial number
can be updated.
Each primary name server should be configured with the following parame-
ters, whose names as shown below are examples for the use of this docu-
ment:
IncrTime (default: 300 seconds)
The time in seconds by which the zone serial number must be
updated after an update has been committed. The value must be
less than a third of the zone refresh time.
Expires May, 1996 [Page 12]
INTERNET-DRAFT DNS UPDATE October 1995
DeferUpdCnt (default: 100)
The maximum number of update requests that could be processed
before updating the zone serial number.
If changes have been made to a zone since the zone serial number was
last updated, the primary must update the zone serial number on the fol-
lowing events:
1. Before any QUERY response containing the zone's SOA RR is sent.
2. When the timer associated with IncrTime expires.
3. When DeferUpdCnt update requests have been processed.
3.2 - Maintaining Zone Consistency
Zone consistency between masters and slaves is achieved through zone
transfers. Once the primary master has updated its master file (the
zone's external data source), either AXFR or IXFR (see [IXFR]) can be
used to distribute these changes to the slaves. NOTIFY (see [NOTIFY])
can be used to shorten the delay before an AXFR or IXFR is begun.
4.0 - Client Behavior
From a client's point of view, any authoritative server for the zone can
appear to be able to process update requests, even though only the pri-
mary master server is actually able to modify the zone's master file.
Clients are expected to know the name of the zone they intend to update
and to know the name servers for that zone.
Note:
There is no provision for recursion or referral of update requests,
as this would require all caching servers on the Internet to support
dynamic updates before any zone could begin using it. Dynamic
updates depend on QUERY or on a priori knowledge to locate the zone's
name servers.
If the client 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 named in the SOA MNAME field) first to avoid
unnecessary forwarding inside the slave servers. Note that the primary
master will in many cases not be reachable by all clients, due to fire-
walls or network partitioning.
Expires May, 1996 [Page 13]
INTERNET-DRAFT DNS UPDATE October 1995
Discussion:
One way to acquire a node's zone name and server list is to use the
QUERY opcode, asking for the SOA RR of each successive parent domain,
moving to the next parent if a {NOERROR, ANCOUNT=0} response is
received, abandoning the search if an NXDOMAIN reply is received, or
declaring success if a {NOERROR, ANCOUNT=1} response is received with
an SOA RR in the answer section. For example, if updating the
GW.HOME.VIX.COM node inside the VIX.COM zone, the following transac-
tions might occur:
Query Response
------------------------------------------------
GW.HOME.VIX.COM SOA? RCODE=NOERROR, ANCOUNT=0
HOME.VIX.COM SOA? RCODE=NOERROR, ANCOUNT=0
VIX.COM SOA? RCODE=NOERROR, ANCOUNT=1
This relies on two obscure facts about QUERY: (1) that a query of a
node which has no records at all (HOME.VIX.COM in our example)
returns NOERROR rather than the more intuitive NXDOMAIN; and (2) that
a response containing an SOA RR answer should have the NS RR list for
that SOA's zone in the authority section.
Note that a robust implementation should be prepared for a response
that fails to satisfy either or both of the above assumptions.
Therefore it is recommended that the search continue all the way to
the root domain even in the face of an NXDOMAIN -- which will address
the potential for a server to answer with NXDOMAIN for an empty non-
terminal (see section 7); and also, if an SOA response is received
with no authority section, the implementation should be prepared to
query for the NS RR list of the returned SOA RR's zone.
If update ordering is desired, the client will need to know the existing
value of the ordering RR (SOA or SIG). If SIG RR record ordering is
used, and if full DNS Security is in use, the client must have the zone
key in order to generate the updated SIG RRs.
Once a set of name servers authoritative for the zone have been found, a
resolver sends an update request to one of them. If the resolver
receives a response, and the response has an RCODE other than Server
Failure or Not Implemented, then the resolver returns an appropriate
response to the client.
If a response is received whose RCODE is Server Failure or Not Imple-
mented, or if no response is received within a locally specified timeout
period, or if an ICMP error is received indicating that the server's
Expires May, 1996 [Page 14]
INTERNET-DRAFT DNS UPDATE October 1995
net, host or port is unreachable, then the resolver will delete the
unusable server from its internal NS RR list and try the next one,
repeating until the NS RR list is empty. If the resolver runs out of
servers to try, an appropriate error will be returned to the client.
Implementation Note:
The resolver may cache information about a zone's authoritative
servers, such as whether a server implements the UPDATE opcode or how
long the server takes to complete an UPDATE transaction. If such
information is cached, it should be purged according to the NS RRs'
TTL field.
5.0 - Duplicate Detection, Ordering and Mutual Exclusion
For correct operation, mechanisms are needed to detect duplicate
requests, order update requests and provide mutual exclusion. Duplicate
requests may arise when a resolver or client resends an update request
due to some error, or even maliciously.
Misordering can occur if the network misorders or duplicates packets, or
if a client sends update requests to multiple slave servers (on the way
to the primary master). In all cases, it is required that the earlier
update not be applied after the later update, and that each update be
applied only once.
To address these problems, this document specifies two mechanisms, one
that is based on the use of SIG RRs, and one that is based on the use of
the SOA RR. Support for dynamically updating SIG RRs must be imple-
mented, since SIG RR ordering is the default mechanism. The SOA RR
ordering mechanism is optional in servers and in clients. Note that
implementation of either scheme requires no extra mechanism beyond that
required for dynamically updating these RRs.
The SIG RR contains a timestamp which can be used to order updates. An
implementation that uses SIG RRs for ordering must follow the rules
below:
Each update of a particular {node,class,type} must be accompanied by
a SIG RR covering that {node,class,type}. That is, the existing set
of SIG RRs covering the existing set of RRs (typically there will
only be one such SIG, but there may be more) must be replaced by a
new set covering the new set of RRs. The delete and add operations
are used to update SIG RRs in the same way as they are used to update
any other type of RR.
Expires May, 1996 [Page 15]
INTERNET-DRAFT DNS UPDATE October 1995
For the purpose of supporting dynamic DNS updates this document extends
the semantics of the 'time signed' field in the SIG RR as follows: the
time signed must always be assigned a value that is larger than the cur-
rent value in all existing SIG RRs for the name, class and type (if any
exist) and must be reasonably current, i.e. it must not be set too far
in the past or too far in the future.
Note:
Note that the use of SIG RRs implies that DNS Security is imple-
mented, at least in a minimal form that supports null KEY RRs and
null SIG RRs (algorythm type 253 [DNSSEC].)
The zone SOA RR contains a serial number which can be used to order
updates. An implementation that uses the SOA RR for ordering must fol-
low the rules below:
Each update request must replace (delete old, add new) the current
SOA RR with a new SOA RR containing the new serial number. The
delete and add operations are used to update SOA RR in the same way
as they are used to update any other type of RR.
This document specifies the use of SIG RRs as the primary mechanism to
support ordering and duplicate detection, and the use of the zone's
serial number as an optional alternative mechanism. That is, a confor-
mant implementation must support ordering and duplicate detection based
on the use of SIG RRs, but support for ordering and duplication detec-
tion based on the SOA RR may be absent.
In addition to the two ordering mechanisms described above, this docu-
ment does not preclude the use of other ordering (serialization) mecha-
nisms. Details of such mechanisms are outside the scope of this docu-
ment.
Note:
It is expected that many UPDATE transactions will not specify any
kind of ordering. Such updates will succeed or fail based on the
presence and/or absence of the records supplied by the update. This
is dangerous if the possibility of circular updates (e.g., A becomes
B becomes A) exists, since duplicate or out of order UPDATE request
packets could leave the zone in an undefined state.
So far, we have dealt with duplicate detection and update ordering.
Mutual exclusion is necessary if an update is dependent on the state
previously read from the database. (Note: Given the current records
stored in the database and the applications envisaged, the need for
Expires May, 1996 [Page 16]
INTERNET-DRAFT DNS UPDATE October 1995
mutual exclusion is expected to be rare.) This document suggests that a
client can ensure atomicity of a read-modify-write cycle without the
need for any new mechanism. Such atomicity could be accomplished by
querying for the SIG or SOA RRs associated with the records to be
updated at the beginning of the read-modify-write cycle and by explic-
itly replacing them in the update request. By explicitly replacing
these records, the client ensures that, if the update is successful, the
state of the database has remained unchanged between the read and write
operations.
6.0 - Security Considerations
Without DNS Security, the protocol described by this document makes it
possible for anyone who can reach one of your authoritative servers to
update (i.e., add, change, or delete) the contents of your zones.
The SIG RRs defined in [DNSSEC] must be used to ensure that each set of
records of a particular {name,class,type} are updated only by entities
that have the appropriate authority. The SIG RR is updated as part of
an update transaction. As specified in [DNSSEC], the SIG RR must sign
all records associated with a {name,class,type}, not only those updated
in the request.
Note:
The SIG RR only covers records of a particular {name,class,type}.
Thus, while the integrity of each signed RR set updated in a transac-
tion can be assured, the integrity of a set of update records with
different names or types is not. To ensure integrity of the entire
message, a network layer security protocol should be used if avail-
able. Alternatively, one or more SIG RRs signing the entire message
can be placed at the end of the last section of a message as
explained in [DNSSEC].
Note:
A SIG RR is not only used to authenticate an update request, but is
stored along with the authenticated data in DNS to authenticate sub-
sequent queries for the data.
Detailed specification of the update security mechanism is outside the
scope of this document.
Expires May, 1996 [Page 17]
INTERNET-DRAFT DNS UPDATE October 1995
7.0 - DNS Corner Cases
Some of the features and side effects upon which this specification
rests are not well specified by [RFC1034] and [RFC1034], including at
least:
TTL Equivilence
All RRs in an RRset denoted by a given {name,class,type} will be
treated by name servers as having a time-to-live (TTL) equal to the
smallest actual TTL used in that set, for cache coherency purposes.
It is advised that all TTLs among each {name,class,type} RRset in the
master file be equal, and it is further advised that all dynamic
updates take care to preserve this condition.
Existence of Names
A name possessing no RRs but having at least one child cannot be said
to either exist or not exist. These names are called ``empty nonter-
minals'' and they present some important corner cases:
QUERY
The QUERY opcode will report {RCODE=NOERROR, ANCOUNT=0} if applied
to an empty nonterminal, regardless of QTYPE.
ADDNAMENEW
An UPDATE operation with an ADDNAMENEW section will succeed if
applied to an empty nonterminal, even though the name could be
considered to ``already exist'' by some standards.
ADDNAMEEXIST
An UPDATE operation with an ADDNAMEEXIST section will succeed if
applied to an empty nonterminal, even though the name could be
considered to ``not exist'' by some standards.
Expires May, 1996 [Page 18]
INTERNET-DRAFT DNS UPDATE October 1995
Appendix A
A wide range of update functions can be achieved using a combination of
the four update operations. To illustrate this, we use a simple zone
consisting of the following records:
XYZ.COM. SOA ns.xyz.com sysadm.xyz.com ( ... )
NS ns.xyz.com.
NS.XYZ.COM. SIG A 12345755
A 128.96.33.22
FOO.XYZ.COM. SIG A 12345900
A 128.96.33.33
A 128.96.34.34
Example 1:
One of the A records belonging to FOO.XYZ.COM can be modified by
first deleting it and adding a new one.
DELETE FOO.XYZ.COM. SIG A *
A 128.96.33.33
ADD FOO.XYZ.COM. SIG A 12346000
A 128.96.44.44
In this case, the A RR to be deleted is specified explicitly since we
only want to delete one of the records, not both, before the replace-
ment is added. To ensure ordering, the associated SIG record is also
replaced. In the example, we use the wildcard SIG RR to delete the
SIG RR since it is more efficient than deleting the SIG RR explic-
itly. It is generally possible to delete SIGs using this method as
there is typically only one per {name,class,type}, and even if not,
all SIG RRs must be replaced when the associated (``signed'') data is
updated. A SIG RR would only need to be deleted explicitly if it is
being used to implement mutual exclusion over a read-modify-write
cycle as explained in Section 5.
Note that ADDNAMEEXIST would also work in the above example to add
the replacement record since the name associated with the records
still exists after removal of the SIG and A record. However, there
is not much point to doing ADDNAMEEXIST since the atomicity property
of the transaction ensures that the name FOO.XYZ.COM exists.
Expires May, 1996 [Page 19]
INTERNET-DRAFT DNS UPDATE October 1995
Example 2:
The canonical name of a host can be changed from FOO to BAR and the
old name FOO made an alias, by sending an update transaction contain-
ing the following three operations:
DELETE FOO.XYZ.COM. SIG A *
FOO.XYZ.COM. A *
ADD FOO.XYZ.COM. SIG CNAME 12347000
FOO.XYZ.COM. CNAME BAR.XYZ.COM.
ADDNAMENEW BAR.XYZ.COM. SIG A 12347000
A 128.61.44.33
In this example, we use wildcard records to delete all records associ-
ated with FOO. Note that if FOO is a terminal node (that is, has no
children), then the DELETE operation removes the node name FOO from the
database, since records are no longer associated with it. Thus, we
could have used ADDNAMENEW to add the new records associated with FOO
instead of ADD. Again, there is no point to this since the atomic
transaction ensures that the name is unique. However, there is a use
for ADDNAMENEW in the case of the records associated with BAR. To
ensure that BAR is indeed a new name, ADDNAMENEW must be used.
Acknowledgements
We would like to thank the IETF DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake, and
Masataka Ohta.
Expires May, 1996 [Page 20]
INTERNET-DRAFT DNS UPDATE October 1995
References
[RFC1034]
P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034,
USC/Information Sciences Institute, November 1987.
[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 Proto-
col Security Extensions", Internet Draft, March 1994, <draft-ietf-
dnssec-secext-03.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>.
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 May, 1996 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 11:25:49 |