HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:06:18 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 04 Aug 1995 22:00:00 GMT ETag: "2ed83f-a193-30229860" Accept-Ranges: bytes Content-Length: 41363 Connection: close Content-Type: text/plain DNSIND Working Group Susan Thomson (Bellcore) INTERNET-DRAFT Yakov Rekhter (Cisco) 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, . [IXFR]M. Ohta, "Incremental Zone Transfer", Internet Draft, July 1995, . [NOTIFY] P. Vixie, "Notify: a mechanism for prompt notification of authority zone changes", Internet Draft, March 1995, . 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]