DNSIND Working Group Susan Thomson (Bellcore)
INTERNET-DRAFT Yakov Rekhter (Cisco)
<draft-ietf-dnsind-dynDNS-02.txt> Jim Bound (DEC)
July 1995
Dynamic Updates in the Domain Name System (DNS)
Status of this Memo
This document is a submission to the Namedroppers 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 accept requests to
update the database dynamically. The extensions provide support for
adding and deleting a set of names and associated resource records
within a single zone atomically.
Expires January, 1996 [Page 1]
INTERNET-DRAFT Dynamic DNS Updates July 1995
1. INTRODUCTION
The Domain Name System currently only supports queries on a stati-
cally configured database. This document describes extensions to the
Domain Name System to enable name servers to accept requests to
update the database dynamically.
Section 2 describes the update functionality, Section 3 describes the
update message format and Sections 4 and 5 describe name server and
resolver behavior when processing dynamic updates in more detail.
Examples of usage are described in Section 6. Security considerations
are discussed in Section 7.
1.1. TERMINOLOGY
Master Server - any authoritative server configured to be the source
of zone transfer (AXFR) from one or more slave
servers. It is named in a name server resource
record (NS RR) for the zone.
Slave Server - a quasi-authoritative server which uses AXFR to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
Primary Master Server
- master server at the root of the AXFR dependency
graph. The primary master is named in the zone's SOA
MNAME field and by an NS RR.
Expires January, 1996 [Page 2]
INTERNET-DRAFT Dynamic DNS Updates July 1995
2. PROTOCOL OVERVIEW
A domain name identifies a node within the domain name space tree
structure. Each node has a set of Resource Records (RRs).
The extensions to the DNS protocol enable name servers to accept
requests to update the name space and RRs associated with nodes in
the name space dynamically.
2.1. Definition
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 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)
If the name already exists, then the semantics of this operation
is the same as ADDNAMEEXIST. If the name does not exist, then
the semantics of this operation is 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
Expires January, 1996 [Page 3]
INTERNET-DRAFT Dynamic DNS Updates July 1995
without explicitly deleting each and every one of them. This is
done using a wildcard data resource record as specified below.
NOTE: For simplicity, the 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 (see below).
Update requests have the following properties:
- The effect of an update request is to perform all of the opera-
tions 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 subse-
quent operations on records in that request, i.e. the zone is
updated incrementally, albeit tentatively, as the update is pro-
cessed. 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 clarifica-
tion.)
- 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
asynchronously(see Section 4).
- 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 at the time of the update or asynchronously, at
the discretion of the primary master server (see Section 4).
- All records updated in a request must be contained within a sin-
gle zone, and hence all must have the same class.
2.2. Client and Server Behavior
From a client's perspective, any authoritative server for the zone to
be updated can process an update request. Users are expected to know
the name of the zone to be updated and resolvers use queries in the
Expires January, 1996 [Page 4]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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 name server is expected to check that it is authoritative for the
zone to be updated by verifying that the records added or deleted
belong to the zone, or by verifying that the update request expli-
citly carries the name of the zone for which the server is authorita-
tive.
Note: Typically the records to be updated will be part of authorita-
tive data of the zone. However, in the case of delegation (NS) and
glue (A) records, this is not the case. It is a matter of name server
policy which records in the zone may be updated.
From a server's perspective, only the primary master server actually
performs the update request. A slave server is responsible for for-
warding the request to the primary master server for the zone, possi-
bly via other slave servers. The forwarding of an update message is
done synchronously on an update request, i.e, a slave name server
will wait for a response to a forwarded update request from the pri-
mary master server, possibly via other slave servers, before return-
ing the response to the client.
Note: The specification of this protocol assumes that there is a sin-
gle primary master server per zone.
2.3. Testing for Resource Record Equality
2.3.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.
Expires January, 1996 [Page 5]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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.
Note: There are three exceptions to the above rule. 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.
2.3.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 data length of * and an empty data field is
defined to match all records of the same name, class and type includ-
ing the empty set, irrespective of the data contained in the records,
if any.
The wildcard data length field is encoded as follows:
* 65535 wildcard length field used in DELETE
operation to delete all records
of the same name, class and type.
Note: The above definition of a wildcard record does not allow SIG
RRs associated with a name, class and type to be deleted implicitly,
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
Expires January, 1996 [Page 6]
INTERNET-DRAFT Dynamic DNS Updates July 1995
wildcard data length of * and a data field of length two containing
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.4. 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 indempo-
tent, 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).
Misordering can occur if the network protocol used misorders packets,
if a client sends update requests to different slave servers (on the
way to the primary master) or simply if a client sends an update
request, does not know whether it succeeded, and then sends a dif-
ferent update request later. 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. To use the SOA RR for this purpose,
each update request must replace the current SOA RR with a new
SOA RR containing the new serial number. 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.
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
Expires January, 1996 [Page 7]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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 be also be used since it contains a timestamp which
can be used to order updates. The 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
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. Another
advantage of the SIG mechanism over the SOA mechanism is that it is
associated with records of a particular name, class and type and so
operates at a smaller granularity, and hence scales better.
Therefore, this document specifies the use of SIG RRs as the primary
(preferred) mechanism to support ordering and duplicate detection,
and the use of the zone's serial number as the secondary (alterna-
tive) mechanism. Note that the use of SIG RRs implies that DNS secu-
rity is implemented, but it does not necessarily imply that security
is in use. For example, all fields relating to the signature may be
empty, except for the 'time signed' field.
To use SIG RRs for ordering, the following rules must be put in
place:
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.
Expires January, 1996 [Page 8]
INTERNET-DRAFT Dynamic DNS Updates July 1995
For the purpose of supporting dynamic DNS updates the semantics
of the 'time signed' field in the SIG RR must be extended: 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 reasonably current, i.e. it
must not be set too far in the past or too far in the future.
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. (Given the current records stored
in the database and the applications envisaged, the need for mutual
exclusion is expected to be rare.) A client can ensure atomicity of a
read-modify-write cycle without the need for any new mechanism 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.
Expires January, 1996 [Page 9]
INTERNET-DRAFT Dynamic DNS Updates July 1995
3. 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 ZONENAME 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 zone name 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 zone name section, this section
must appear as the first section in the message body. This document
does not constrain the order of appearence of the rest of the sec-
tions within the body. Except for the zone name section, an update
request may have more than one section with the same operation type.
An update request have have at most one zone name 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 byte length field defining the length of the message in
octets, excluding the length field itself.
3.1. Header Section
Expires January, 1996 [Page 10]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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). Also, certain fields, the AA
bit, the TC bit, the RD bit and RA bit, do not exist anymore since
they are not used. These fields are reserved and must be set to zero.
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 January, 1996 [Page 11]
INTERNET-DRAFT Dynamic DNS Updates July 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 January, 1996 [Page 12]
INTERNET-DRAFT Dynamic DNS Updates July 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 Version Error - This code
indicates that the "time signed"
field in a SIG RR or the serial number
in a SOA RR is set incorrectly or that
these records do not cover the records
updated.
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 ZONENAME
Expires January, 1996 [Page 13]
INTERNET-DRAFT Dynamic DNS Updates July 1995
The count field is a 1 octet unsigned integer that contains the
number of RRs in the section. For the zone name section the only
legal value of the count field is 1.
Expires January, 1996 [Page 14]
INTERNET-DRAFT Dynamic DNS Updates July 1995
4. 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 aborts the transaction.
Otherwise, the name server begins processing the request. If the
request does not contain the zone name 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 zone name 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.
If this is a slave server for the zone, forward the request to the
primary master and wait for the response. Send the response back to
the initiator.
The primary master server then starts the transaction.
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
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 2.3. 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
Expires January, 1996 [Page 15]
INTERNET-DRAFT Dynamic DNS Updates July 1995
below.
If the operation is ADDNAMEEXIST or ADD, check if the
specified record already exists using the rules in Section
2.3. 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 we have a referral, abort the transaction. Return a
response indicating a Zone Error.
c) 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 indicat-
ing 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 name server has been configured to use SIG RRs for versioning
purposes, the name server checks that a SIG record has 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
2.4. If not, the name server aborts the transaction with a Version
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 a Version Error.
If no errors have been found, the name server commits the transac-
tion. 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 4.1. The name server returns a suc-
cessful response.
Expires January, 1996 [Page 16]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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. Committing a transaction
means that the changes are applied to the zone and are visible to
subsequent queries to the primary, although as mentioned earlier this
is not a requirement of the specification. It is an implementation
matter whether the master file is updated at this time or later. It
is sufficent that the changes are made persistent, e.g. in a log on
stable storage, and are typically added to the cached copy of the
zone. If the zone serial number is not explicitly updated in a
request, a primary 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. 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 pos-
sible to slow incrementing of the serial number in situations where
many updates occur close together in time.
4.1. Incrementing the Zone Serial Number
There is a limit on how slowly the zone serial number can be updated.
Each primary name server should be configured with the following
variable:
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
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:
Expires January, 1996 [Page 17]
INTERNET-DRAFT Dynamic DNS Updates July 1995
1. Before any response to a query that contains the SOA RR is sent
2. When the timer associated with IncrTime expires
3. When 100 update requests have been processed
4.2. Maintaining Internal Consistency
Zone consistency between primary and secondaries is achieved through
asynchronous zone transfer. Either full zone transfer as currently
defined can be used, or incremental zone transfer when it becomes
available[IXFR]. The Notify mechanism[NOTIFY] may also be used to
cause zone transfers to happen earlier than would otherwise be deter-
mined by the zone refresh time.
Expires January, 1996 [Page 18]
INTERNET-DRAFT Dynamic DNS Updates July 1995
5. RESOLVER BEHAVIOR
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
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 to one of them. and analyzes the
response:
a) If the response shows that updates are not implemented by
this server, or has been a server failure or the server is
unreachable, 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.
b) Otherwise, return an appropriate response to the client.
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).
Expires January, 1996 [Page 19]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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
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 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 3.4. 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 so since
the atomicity property of the transaction ensures that the name "foo"
Expires January, 1996 [Page 20]
INTERNET-DRAFT Dynamic DNS Updates July 1995
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 January, 1996 [Page 21]
INTERNET-DRAFT Dynamic DNS Updates July 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, Randy Bush, Donald Eastlake, Masataka Ohta
and Paul Vixie.
Expires January, 1996 [Page 22]
INTERNET-DRAFT Dynamic DNS Updates July 1995
9. REFERENCES
[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 January, 1996 [Page 23]
INTERNET-DRAFT Dynamic DNS Updates July 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 January, 1996 [Page 24]