HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:06:16 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 07 Jul 1995 22:00:00 GMT ETag: "2ed83e-a7a2-2ffdae60" Accept-Ranges: bytes Content-Length: 42914 Connection: close Content-Type: text/plain DNSIND Working Group Susan Thomson (Bellcore) INTERNET-DRAFT Yakov Rekhter (Cisco) 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, . [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 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]