DNSIND Working Group Susan Thomson (Bellcore)
INTERNET-DRAFT Yakov Rekhter (Cisco)
<draft-ietf-dnsind-dynDNS-03.txt> Jim Bound (DEC)
August 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
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working 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 currently only supports queries on a
statically configured database. This document describes extensions
to the Domain Name System to enable name servers to dynamically
accept requests to update the database. The extensions provide
support for adding and deleting a set of names and associated
resource records within a single zone atomically.
Expires February, 1996 [Page 1]
INTERNET-DRAFT Dynamic DNS Updates August 1995
1 Definitions
Slave Server - an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
Master Server - any authoritative server configured to be the source
of zone transfer from one or more slave
servers. It is named in a name server resource
record (NS RR) for the zone.
Primary Master Server
- master server at the root of the zone transfer
dependency graph. The primary master is named in
the zone's SOA MNAME field and by an NS RR. The
specification of this protocol assumes that there
is a single primary master server per zone.
A domain name identifies a node within the domain name space tree
structure. Each node has a set of Resource Records (RRs).
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 operation:
1. Add new name and associated with it a set of records to zone
(ADDNAMENEW)
This operation is only successful if the name of the record(s)
does not already exist in the zone. The effect of the operation
is to create a new node in the name space and add records to
this node. The existence rules are described in more detail
below.
2. Add records associated with an existing name to zone (ADDNAMEEX-
IST)
This operation is only successful if the name the records are
associated with exists in the zone. The effect of the operation
is to update records that belong to an existing node in the name
space.
3. Add name and associated with it a set of records to zone,
whether name exists or not (ADD)
Expires February, 1996 [Page 2]
INTERNET-DRAFT Dynamic DNS Updates August 1995
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.
4. Delete records from zone (DELETE)
This operation is only successful if the specified records
exist. However, it is possible to specify that all resource
records associated with a name, class and type must be deleted
without explicitly deleting each and every one of them. This is
done using a wildcard data resource record as specified below.
For simplicity, the above definitions have been written as if an
operation 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 requests have the following properties:
- The effect of an update request is to perform all of the
operations in the transaction, if all can be performed suc-
cessfully, 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 exception 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 section on Name Server Behavior and the Example section
for further clarification.)
- A successful update means that no errors were detected and
that the update has been applied to the zone by the primary
master server. Updates are applied to slaver servers asyn-
chronously (see Section 3).
- 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).
- All records updated in a request must be contained within a
Expires February, 1996 [Page 3]
INTERNET-DRAFT Dynamic DNS Updates August 1995
single zone, and hence all must have the same class.
1.1 Resource Record Comparison Rules
The four types of update operation depend on comparing an existing
record with a record specified in an update for equality. For exam-
ple, the DELETE operation requires that the record exist before it is
deleted and ADD operations must be idempotent.
Two records are considered to be the same if their name, class, type,
data length and value are the same. The time-to-live field is specif-
ically excluded from comparison.
There are three exceptions to the above rule that apply for all, but
DELETE operations. In the case of SOA RRs, it only makes sense to
have one SOA record per zone, so only the type is checked. In the
case of SIG RRs, it only makes sense to have one SIG record per name,
class, type, type covered, signer's name, key and algorithm used. So
only these fields are checked. In the case of WKS records, the name,
class, type, address and protocol fields are checked, since there
should be only one record for these fields.
The comparison of character strings in names and in data fields is
case-insensitive. For two names to match, they must match label by
label. A non-wildcard label never matches the '*' label, i.e. names
must exist explicitly in a zone to be matched by a record specified
in an update.
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. A
record with a wildcard TTL of * and an empty data field is defined to
match all records of the same name, class and type including the
empty set, irrespective of the data contained in the records, if any.
The wildcard TTL field is encoded as follows:
Expires February, 1996 [Page 4]
INTERNET-DRAFT Dynamic DNS Updates August 1995
* 2^32 wildcard TTL field used in DELETE
operation to delete all records
of the same name, class and type.
Observe that the above definition of a wildcard record does not allow
SIG RRs associated with a name, class and type to be deleted impli-
citly, since the type of records signed by the SIG RR is stored in
the data field. An exception is thus made for the SIG RR. A SIG
record with a wildcard TTL of * and a data field of length two con-
taining the type covered is defined to match any SIG records of the
same name, class and type covered.
A wildcard resource record is only useful in an update request; the
record is not valid in a zone.
2 Update message format
The message format has the following structure: the message header
followed by the message body. An update request contains both the
header and the body. An update response contains just the header.
The message header has a similar format to that of the query. The
message body consists of a variable number of sections.
This document defines 5 types of sections: the ZONEAUTHORITY section
(for specifying the name of the zone to which the update(s) have to
be applied), the DELETE section (for deleting existing records), the
ADDNAMENEW section (for adding records with new names), the
ADDNAMEEXIST section (for adding records with existing names), and
the plain ADD section (for adding records with either new or existing
names).
The DELETE, ADDNAMENEW, ADDNAMEEXIST, and ADD sections contain the
records that need to have the operation associated with the section
type applied. The ZONEAUTHORITY section contains the SOA RR of the
zone to which updates (carried in the rest of the sections of the
message) should be applied.
If an update request contains the ZONEAUTHORITY section, this section
must appear as the first section in the message body. This document
does not constrain the order of appearance of the rest of the sec-
tions within the body. Except for the ZONEAUTHORITY section, an
Expires February, 1996 [Page 5]
INTERNET-DRAFT Dynamic DNS Updates August 1995
update request may have more than one section with the same operation
type. An update request may have at most one ZONEAUTHORITY section.
An update request is not required to have all the sections present.
An update request/response may be carried in a UDP datagram, if it
fits, or a TCP connection. When TCP is used, the message is prefixed
with a two octet length field (in network byte order) defining the
length of the message in octets, excluding the length field itself.
2.1 Header Section
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. There
are no section count fields in the message header (the sections in
the message body are self-encoded).
There is a new operation code (value to be defined) to specify an
update request in the Opcode field.
UPDATE TBD
This Opcode distinguishes the update header from the query header.
This document specifies the semantics of the fields in the update
header only.
Besides a new operation code, there are also new return codes.
The fields are set as follows in update requests and responses:
Expires February, 1996 [Page 6]
INTERNET-DRAFT Dynamic DNS Updates August 1995
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 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. In addition to
the values defined in RFC1034, this document defines the
following value:
TBD an update request (UPDATE)
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 4 bit field is set as part of
responses. The values and semantics of update responses
are as follows:
0 No error condition
1 Format error - The name server was
unable to interpret the request.
2 Server failure - The name server was
unable to process this request due to a
problem with the name server.
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
Expires February, 1996 [Page 7]
INTERNET-DRAFT Dynamic DNS Updates August 1995
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 - This code indicates
a name already exists. This return code
is only meaningful from a server
in response to an ADDNAMENEW operation.
8 Record Error - This code
indicates that a resource record does
not exist.
This return code is only meaningful from a
server in response to a DELETE operation.
9 Zone Error - This code
indicates that the update is
to be performed on a zone for which
the server is not authoritative, or
that the records to be
updated exist in more than one zone
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.
Each section contains a 1 octet type code, followed by a 1 octet
count field (in units of RRs), followed by a number of RRs (the
number is specified in the count field). This document defines the
following section type codes:
1 DELETE
2 ADDNAMENEW
3 ADDNAMEEXIST
4 ADD
5 ZONEAUTHORITY
The count field is a 1 octet unsigned integer that contains the
number of RRs in the section. For the ZONEAUTHORITY section the only
Expires February, 1996 [Page 8]
INTERNET-DRAFT Dynamic DNS Updates August 1995
legal value of the count field is 1.
3 Name Server Behavior
On receiving an update request, a name server checks to see whether
updates are implemented. If not the name server returns Not Imple-
mented and terminates the transaction.
Otherwise, the name server begins processing the request. If the
request does not contain the ZONEAUTHORITY section, then the name
server checks to see whether all nodes to be updated are in a single
zone for which it is authoritative. If not, the name server returns a
Zone Error. If the request contains the ZONEAUTHORITY section, then
the name server checks to see whether it is authoritative for the
zone, as specified in the section. If not, the name server returns a
Zone Error.
From a server's perspective, only the primary master server actually
performs the update request.
If an update request is received by a slave server for the zone, the
server forwards the request to the primary master server for the zone
and waits for the response. The wait time is bounded by the a confi-
gurable parameter MasterTimeOut (default value 10 seconds). If the
server receives a response within the MasterTimeOut interval, the
server sends the response back to the initiator. If no response has
been received within the MasterTimeOut interval, the server sends a
response indicating Server Failure back to the initiator.
If an update request is received by the primary master server, the
server starts the transaction as follows. For each record in the
update request start matching down on the record name (RRNAME), label
by label, in the zone. For each label, test for the following cases:
a) 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 record (RRTYPE) does not match CNAME, abort the transac-
tion and return a response indicating an Alias Error.
If the operation is DELETE, check if the specified record
Expires February, 1996 [Page 9]
INTERNET-DRAFT Dynamic DNS Updates August 1995
exists in the zone using the rules in Section 1.1. If not,
abort the transaction and return a response indicating a
Record Error.
If the operation is ADDNAMENEW, abort the transaction and
return a response indicating a Name Exists Error. Note that if
the name exists because it has been added as a result of this
update request, proceed as for ADDNAMEEXIST and ADD below.
If the operation is ADDNAMEEXIST or ADD, check if the speci-
fied 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 RR.
Perform the update operation tentatively.
b) If at some label, a match is impossible (i.e. the label does
not exist), and the operation is ADDNAMEEXIST or DELETE, abort
the transaction and return response indicating a Name Error.
If the operation is ADDNAMENEW or ADD, perform the update
operation tentatively.
Note that 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 node whose RRs to be updated has one or more SIG RRs, then the
name server checks that these SIG RRs have been updated for each
name, class and type updated and that the "time signed" field has
been set to an appropriate value as specified in Section 5. If not,
the name server aborts the transaction with an Ordering Error. Note
that if all records of a given name, class and 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.
If the SOA is updated as part of the transaction, then it must be
ensured that the serial number has been updated appropriately. If
not, the name server aborts the transaction with an Ordering Error.
If no errors have been found, the name server commits the
Expires February, 1996 [Page 10]
INTERNET-DRAFT Dynamic DNS Updates August 1995
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.
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. in a log on stable storage), and are visible to sub-
sequent queries to the primary at the time of committing the transac-
tion.
3.1 Incrementing the Zone Serial Number
If the zone serial number is not explicitly updated in a request, a
primary master server may update the zone serial number when commit-
ting each transaction, or periodically, after some number of transac-
tions or time has passed, depending on policy as defined below. The
effect of incrementing the serial number periodically rather than on
each transaction means that a secondary may not detect that a zone
has been updated as quickly as it otherwise would do. On the other
hand, 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.
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
parameters:
IncrTime
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.
Default: 300 seconds
Expires February, 1996 [Page 11]
INTERNET-DRAFT Dynamic DNS Updates August 1995
DeferUpdCnt
The maximum number of update requests that could be processed
before updating the zone serial number
Default: 100
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
following events:
1. Before any response to a query that contains the SOA RR is sent
2. When the timer associated with IncrTime expires
3. When DeferUpdCnt update requests have been processed
3.2 Maintaining Internal Consistency
Zone consistency between masters and slaves is achieved through asyn-
chronous zone transfer. Either full zone transfer as currently
defined can be used, or incremental zone transfer as defined in
[IXFR]. The Notify mechanism[NOTIFY] may also be used to cause zone
transfers to happen earlier than would otherwise be determined by the
zone refresh time.
4 Client Behavior
From a client's perspective, any authoritative server for the zone to
be updated can process an update request. Clients are expected to
know the name of the zone to be updated and resolvers use queries in
the normal way to determine the set of name servers authoritative for
the zone to be updated. Unlike queries, recursion and referrals are
not supported by update requests.
A resolver provides the client side protocol of DNS to name servers.
A resolver must enable applications to perform both standard queries
and updates.
In an update, a client is expected to pass to the resolver the name
of the zone to be updated as well as the records that need to be
Expires February, 1996 [Page 12]
INTERNET-DRAFT Dynamic DNS Updates August 1995
deleted and added. The resolver determines the name servers authori-
tative for the zone using the normal query mechanism, i.e. either by
performing a recursive NS query to a local name server or doing the
resolution itself. It is also possible that the appropriate name
servers are statically configured.
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 does not indicate that
updates are not implemented, or server failure, then the resolver
returns an appropriate response to the client. If the response shows
that updates are not implemented by this server, or there has been a
server failure, the resolver may delete the server from the list of
servers and resend the request to one of the remaining servers, if
any. If no servers remain, return an appropriate error. If the server
is unreachable, or not responding within the locally maintained
timeout interval, the resolver should resend the request to one of
the remaining servers (if any), and may also try to resend it to the
server at some later point. A strategy for resending requests to an
unreachable or not responding server(s) is implementation defined by
the resolver.
From an implementation perspective, the resolver may cache informa-
tion about which out of the set of authoritative name servers are the
"best" to ask. For example, the resolver may keep information about
which in a set of authoritative name servers accept update requests
for a given zone (some name servers may refuse to accept update
requests) and the relative performance of the name servers (primary
master may provide better performance than slaves).
5 Duplicate Detection, Ordering and Mutual Exclusion
For correct operation, mechanisms are needed to detect duplicate
requests, order update requests and provide mutual exclusion. Dupli-
cate requests may arise when a resolver or client retries a particu-
lar update request due to some error or maliciously. Duplicate
requests give rise to two problems: since update requests, and in
particular, the DELETE and ADDNAMENEW operations, are not idempotent,
duplicate requests will return two different response codes. The
other problem is to ensure that duplicate update requests are not
applied to the database after other later updates have been applied.
(This latter problem is a a special case of the reordering problem).
Expires February, 1996 [Page 13]
INTERNET-DRAFT Dynamic DNS Updates August 1995
Misordering can occur if the network protocol used misorders packets,
or if a client sends update requests to different 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.
To address these problems, it is recommended that a monotonically
increasing "version" number be associated with records in a zone
using values in existing record definitions as outlined below.
The zone SOA RR contains a serial number which can be used as a ver-
sion number. An implementation that uses the SOA RR for this purpose
must follow 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.
Use of the SOA for ordering and duplicate detection has several draw-
backs, however. One is that this implies that the serial number be
incremented on each update. Traditionally, the serial number in the
SOA has been incremented at the discretion of the primary master
server (or at least the system administrator that updates the master
file) and is a privileged operation. It is felt that this property
should remain for two reasons: one is a concern that the serial
number space may be too small and the other is to give the primary
master (or system administrator) total control over when to indicate
to slaves that a zone transfer is needed. More importantly, it is
felt that having a serial number per zone will not scale well since
it forces all updates to a zone to be ordered even when this is not
necessary for correctness. Since it is expected that there will be
bursts of concurrent updates to different nodes within a single zone,
e.g. when many hosts power up for the first time or when a site
renumbers, ordering should be possible at a smaller granularity,
namely on at least a per node basis.
The SIG RR can also be used since it contains a timestamp which can
be used to order updates. The advantage of the SIG mechanism over
the SOA mechanism is that it is associated with records of a particu-
lar name, class and type and so operates at a smaller granularity,
and hence scales better. Another advantage of using a timestamp for
ordering, rather than a serial number which is incremented by one
each time, is that it is not necessary for a client to know the
current value in order to update it. The disadvantage is that
client's clocks are not necessarily synchronised and so a client with
Expires February, 1996 [Page 14]
INTERNET-DRAFT Dynamic DNS Updates August 1995
a slower clock can be denied service by a client with a faster clock
if they are both updating the same set of records. Also, a client may
be denied service by the server if its clock is too fast.
Therefore, 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 the secondary (alternative) mechanism.
Note that the use of SIG RRs implies that SIG RRs are implemented,
but it does not necessarily imply than the rest of DNSSEC mechanisms
are implemented, or that security is in use. For example, all fields
relating to the signature may be empty, except for the 'time signed'
field.
An implementation that uses SIG RRs for ordering must follow the
rules below:
Each update of a particular node, class and type must be accom-
panied by a SIG RR covering that node, class and 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.
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 current value in all existing SIG RRs
for the name, class and type (if any exist) and must be reason-
ably current, i.e. it must not be set too far in the past or too
far in the future.
In addition to the two ordering mechanisms described above, this
document does not preclude the use of other ordering (serialization)
mechanisms. Details of such mechanisms are outside the scope of this
document.
This document does not require every application that uses dynamic
DNS update facilities described here to use ordering (serialization)
mechanism(s). However, the application that does not use any ordering
(serialization) needs to be cognizant of possible implications (as
described above).
So far, we have dealt with duplicate detection and update ordering.
Mutual exclusion is necessary if an update is dependent on the state
Expires February, 1996 [Page 15]
INTERNET-DRAFT Dynamic DNS Updates August 1995
previously read from the database. (Given the current records stored
in the database and the applications envisaged, the need for 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 expli-
citly deleting them in the update request. By explicitly deleting
these records, the client ensures that, if the update is successful,
the state of the database has remained unchanged between the read and
write part of the cycle.
6 Examples
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
For example, one of the A records belonging to foo.xyz.com can be
modified by first deleting it and adding the new.
DELETE foo.xyz.com SIG A *
A 128.96.33.33
ADD foo.xyz.com SIG A 12346000
A 128.96.44.44
Expires February, 1996 [Page 16]
INTERNET-DRAFT Dynamic DNS Updates August 1995
In this case, the A record to be deleted is specified explicitly
since we only want to delete one of the records, not both, and the
replacement added. To ensure ordering, the associated SIG record is
also replaced. In the example, we use the wildcard SIG record to
delete the SIG since it is more efficient than deleting the SIG
explicitly. It is generally possible to delete SIGs using this
method as there is typically only one per name, class and type, and
even if not, all SIGs must be replaced when the associated data needs
to be updated. A SIG 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" exists.
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
consisting of 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 asso-
ciated with "foo" for efficiency. Note that 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.
Expires February, 1996 [Page 17]
INTERNET-DRAFT Dynamic DNS Updates August 1995
7 Security Considerations
DNS updates must be able to be made secure. The security mechanism
must provide data origin authentication, data integrity and protec-
tion against replay. Data confidentiality is not required.
The signature records defined in [DNSSEC] should be used to ensure
that each set of records of a particular name, type and class are
updated by an entity that has the appropriate authority. The signa-
ture record is updated along with the associated records in an update
transaction. As specified in [DNSSEC], the SIG RR must sign all
records associated with a name, class and type, not only those
updated in the request.
The "time signed" timestamp in the SIG record may be used to protect
against replay if it is defined that, when updated, it must have a
value greater than the current value and be set to a time not too far
in the future.
Note that a signature record only covers records of a particular
name, class and type. Thus, while the integrity of each set of
records of the same name, class and type updated in a transaction 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 available. Alterna-
tively, 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 that a SIG RR is not only used to authenticate an update
request, but is stored along with the authenticated data in DNS to
authenticate subsequent queries for the data.
Detailed specification of the update security mechanism is outside
the scope of this document.
8 Acknowledgements
We would like to thank the DNSIND working group for their input and
assistance, in particular, Rob Austein, Randy Bush, Donald Eastlake,
Masataka Ohta and Paul Vixie.
9 References
Expires February, 1996 [Page 18]
INTERNET-DRAFT Dynamic DNS Updates August 1995
[RFC1034]
P. Mockapetris, "Domain Names - Concepts and Facilities", RFC
1034, USC/Information Sciences Institute, November 1987.
[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specifica-
tion", RFC 1035, USC/Information Sciences Institute, November
1987.
[DNSSEC]
Donald E. Eastlake and Charles W. Kaufman, "Domain Name System
Protocol 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>.
Expires February, 1996 [Page 19]
INTERNET-DRAFT Dynamic DNS Updates August 1995
Authors' Addresses
Susan Thomson
Bellcore
445 South Street
Morristown, NJ 07960
Phone: (201) 829-4514
email: set@thumper.bellcore.com
Yakov Rekhter
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: (914) 528-0090
email: yakov@cisco.com
Jim Bound
Digital Equipment Corporation
110 Spitbrook Road ZK3-3/U14
Nashua, NH 03062-2698
Phone: (603) 881-0400
email: bound@zk3.dec.com
Expires February, 1996 [Page 20]
