HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:06:14 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 27 Mar 1995 22:00:00 GMT ETag: "2ed83d-9fce-2f773560" Accept-Ranges: bytes Content-Length: 40910 Connection: close Content-Type: text/plain DNSIND Working Group Susan Thomson (Bellcore) INTERNET-DRAFT Yakov Rekhter (IBM) Jim Bound (DEC) March 24, 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. The extensions assume that DNS security has been implemented, but is not necessarily in use. Expires September 24, 1995 [Page 1] INTERNET-DRAFT Dynamic DNS Updates March 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. 2. SEMANTICS 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 names space and RRs associated with nodes in the name space dynamically. 2.1. Dynamic Update Requests An update request is an atomic transaction consisting of a sequence of operations on names and RRs in a zone. The operations may be one of four types: 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 records 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) Expires September 24, 1995 [Page 2] INTERNET-DRAFT Dynamic DNS Updates March 1995 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 doesn't 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 without explicitly deleting each and every one of them. This is done using a wildcard data resource record as described in detail below. All four operations can be performed on sets of records with dif- ferent owner names and record types, provided that all names updated in a request are contained within a single zone. The four operations are performed in sequence in the following order: DELETE, ADDNAMENEW, ADDNAMEEXIST and ADD. Note that 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 opera- tion: 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. The effect of an entire update transaction is to perform all of the operations in the transaction, if all can be performed successfully, or none at all. A successful update means that no errors were detected and that the update will be applied to the zone. An update is defined to be asyn- chronous. Typically, updates will be implemented in such a way that Expires September 24, 1995 [Page 3] INTERNET-DRAFT Dynamic DNS Updates March 1995 a primary name server applies the successful update synchronously to the database, and secondary name servers transfer the data asynchro- nously. However, we do not preclude implementations in which the pri- mary applies updates asynchronously. Such implementations must be careful to make sure that any new update request does not conflict with pending requests before returning success. 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 dis- cretion of the primary name server. This is discussed in more detail in Section 4. 2.2. Who performs update requests 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 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. 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 authoritative name server actually performs the update request. A secondary name server is responsible for forwarding the request to the primary name server for the zone, possibly via other secondary name servers. The forward- ing of an update message is done synchronously on an update request, i.e, a secondary name server will wait for a response to a forwarded update request from the primary name server, possibly via other secondary name servers, before returning the response to the client. Note: The specification of this protocol assumes that there is a sin- gle primary name server per zone. Expires September 24, 1995 [Page 4] INTERNET-DRAFT Dynamic DNS Updates March 1995 2.3. Testing for Resource Record Equality 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 this. Also, it is prudent to prevent any of the add operations from adding identical records to the database. 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. 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 Expires September 24, 1995 [Page 5] INTERNET-DRAFT Dynamic DNS Updates March 1995 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 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. 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. In this case, the problem is to ensure that duplicate update requests are not applied to the database after other later updates have been applied. This is a special case of the ordering problem: a client may send an update request, not know whether it succeeded, and then send a dif- ferent update request later. The client would like to ensure that the earlier update will not be applied after the later update. Hence the need for ordering of updates. This problem can be solved by associat- ing a monotonically increasing number with the data to be updated. The zone SOA RR contains a serial number which could be used to order requests. For example, the current SOA RR could be required to be passed on each update request. However, this has several drawbacks. One is that this would imply 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 name server (or at least the system administrator that updates the master file) and it was felt that this property should remain for two reasons: one is a con- cern that the serial number space may be too small and the other is to give the primary (or system administrator) total control over when to indicate to secondaries 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. It is possible to define a special record to hold a serial number Expires September 24, 1995 [Page 6] INTERNET-DRAFT Dynamic DNS Updates March 1995 that would be used to order updates to all records within different scopes, e.g. the whole zone, all records associated with a particular node, or all records associated of a certain type associated with a particular node. We note that a SIG RR is a special case of the above RR since it contains a timestamp which can be used to order updates, but covers RRs at the smallest granularity only, i.e. name, class and type. Defining a new record for ordering and allowing for different scopes seems unnecessarily complicated, especially if it is expected that SIG RRs are going to be used for security purposes in any case. It is thus proposed that we use SIG RRs to support ordering. Note that this implies that DNS security is implemented, but it does not neces- sarily imply that security is in use. For example, all fields relat- ing 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. The semantics of the 'time signed' field 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. Note that one of the advantages of using a timestamp for ordering, rather than a sequence 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 ser- vice by the server if its clock is too fast. DISCUSSION: How large a problem is the above in practice? So far, we have dealt with duplicate detection and update ordering. Expires September 24, 1995 [Page 7] INTERNET-DRAFT Dynamic DNS Updates March 1995 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 RRs associated with the records to be updated at the beginning of the read-modify-write cycle and by explicitly delet- ing 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 September 24, 1995 [Page 8] INTERNET-DRAFT Dynamic DNS Updates March 1995 3. UPDATE MESSAGE FORMAT The message format has the following structure: the message header followed by the message body. The message header has a similar format to that of the query. The message body consists of four sections, one per operation type. The four sections are in the order listed: the delete section, the add section for adding records with new names, the add section for adding records with existing names and the plain add secion. Each section contains the records that need to have the associated operation applied. An update request 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, excluding the length field itself. 3.1. Header Section 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DELCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NEWCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OLDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The main differences between the query header and the update header are in the values that certain fields can assume, and in the seman- tics of certain fields. Also, certain fields, the AA bit, the TC bit, Expires September 24, 1995 [Page 9] INTERNET-DRAFT Dynamic DNS Updates March 1995 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 four count fields have different semantics: they contain the number of records in the DELETE section, the number of records in the ADDNAMENEW section, the number of records in the ADDNAMEEXIST section and the number of records in the ADD section, respectively. The fields are set as follows in update requests and responses: Expires September 24, 1995 [Page 10] INTERNET-DRAFT Dynamic DNS Updates March 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 September 24, 1995 [Page 11] INTERNET-DRAFT Dynamic DNS Updates March 1995 policy 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 Serial Error - This code indicates that the "time signed" field in a SIG RR is set incorrectly or that a SIG RR does not cover the records updated. 11 Permission Denied - This code indicates that the client has insufficient authority to perform the update. DELCOUNT an unsigned 16 bit integer specifying the number of resource records in the DELETE section. Always zero in a response. NEWCOUNT an unsigned 16 bit integer specifying the number of resource records in the ADDNAMENEW section. Always zero in a response. OLDCOUNT an unsigned 16 bit integer specifying the number of resource records in the ADDNAMEEXIST section. Always zero in a response. Expires September 24, 1995 [Page 12] INTERNET-DRAFT Dynamic DNS Updates March 1995 ADDCOUNT an unsigned 16 bit integer specifying the number of resource records in the ADD section. Always zero in a response. Expires September 24, 1995 [Page 13] INTERNET-DRAFT Dynamic DNS Updates March 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 exits. Otherwise, the name server begins processing the request. 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 this is a secondary name server for the zone, forward the request to the primary and wait for the response. Send the response back to the initiator and exit. The primary name 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 X. 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 specified record already exists using the rules in Section Expires September 24, 1995 [Page 14] INTERNET-DRAFT Dynamic DNS Updates March 1995 X. 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. Otherwise, perform the update operation tentatively. b) If we have a referral, abort the transaction. Return a response indicating a Zone Error. Exit. 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. Once all records have been processed, 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 X. If not, the name server aborts the transac- tion with a Serial Error and exits. 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 times- tamps for ordering purposes. 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 X. The name server returns a suc- cessful response and exits. At the start of a transaction, the primary name 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 unsuccessful) transaction. Aborting a transaction requires that any changes made so far must be rolled back. Committing a transaction typically means that the changes are applied to the zone and are visible to Expires September 24, 1995 [Page 15] INTERNET-DRAFT Dynamic DNS Updates March 1995 subsequent queries to the primary, although as mentioned earlier this is not a requirement of the specification. (It is also an implemen- tation matter whether the master file is updated at this time or later. The point is 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 name 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 must be configured with the following vari- able: 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: 1. Before any response to a query that contains the SOA RR is sent 2. When the timer associated with IncrTime expires Expires September 24, 1995 [Page 16] INTERNET-DRAFT Dynamic DNS Updates March 1995 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 proposed Notify mechanism[NOTIFY] may also be used to cause zone transfers to happen earlier than would otherwise be determined by the zone refresh time. Expires September 24, 1995 [Page 17] INTERNET-DRAFT Dynamic DNS Updates March 1995 5. RESOLVER BEHAVIOR A resolver provides the application library interface 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, although undesirable, that the appropriate name servers are statically configured. Once a set of name servers authoritative for the zone have been found, send an update to one of them. Analyze the response: a) If the response shows that updates are not implemented by this server, or there has been a server failure or any other server malfunction, 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 appropri- ate 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 may provide better performance than secondaries). Expires September 24, 1995 [Page 18] INTERNET-DRAFT Dynamic DNS Updates March 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 X. 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 September 24, 1995 [Page 19] INTERNET-DRAFT Dynamic DNS Updates March 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 September 24, 1995 [Page 20] INTERNET-DRAFT Dynamic DNS Updates March 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] can 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 signature record is updated along with the associated records in an update transaction. 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 updates 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, a SIG RR 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. 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. 9. REFERENCES Expires September 24, 1995 [Page 21] INTERNET-DRAFT Dynamic DNS Updates March 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, . [IXFR]M. Ohta, "Incremental Zone Transfer", Internet Draft, November 1994, . [NOTIFY] P. Vixie, "Notify: a mechanism for prompt notification of authority zone changes", Internet Draft, November 1994, . Expires September 24, 1995 [Page 22] INTERNET-DRAFT Dynamic DNS Updates March 1995 Authors' Addresses Susan Thomson Bellcore 445 South Street Morristown, NJ 07960 Phone: (201) 829-4514 email: set@thumper.bellcore.com Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 740, H3-D40, Yorktown Heights, NY 10598 Phone: (914) 784-7361 email: yakov@watson.ibm.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 September 24, 1995 [Page 23]