DNSIND Working Group Susan Thomson (Bellcore) INTERNET-DRAFT Yakov Rekhter (IBM) Jim Bound (DEC) January 31, 1995 Extending the Domain Name System (DNS) to Perform Dynamic Updates Status of this Memo 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. Extensions include support for adding and deleting a set of names and associated resource records within a zone atomically and the definition of a new resource record that enables update requests to be serialized. Expires July 31, 1995 [Page 1] INTERNET-DRAFT Dynamic DNS Updates January 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 provides an overview of the update function. 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. A new resource record useful for serializing update requests is defined in Section 7 and security considerations are discussed in Section 8. 2. 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 names space and RRs associated with nodes in the name space dynamically. An update request is an atomic transac- tion consisting of a set 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 (ADDNEW) 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. 2. Add records associated with an existing name to zone (ADDEXIST) 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 July 31, 1995 [Page 2] INTERNET-DRAFT Dynamic DNS Updates January 1995 If the name already exists, then the semantics of this operation is the same as ADDEXIST. If the name doesn't exist, then the semantics of this operation is the same as ADDNEW. 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 field in the resource record. The update protocol allows several operations to be performed on sets of records with different owner names and record types, provided all names are contained within a single zone. The effect of an update transaction is to perform all of the operations in the transaction, if all can be performed successfully, or none at all. If the zone serial number in the SOA RR is not explicitly updated in an update request, a side-effect of a successful update transaction may be to update the zone serial number. A successful update is applied syn- chronously to the database by the primary name server for the zone, and the updates are transferred to secondary name servers asynchro- nously. Some of the operations depend on comparing an existing record with a record specified in an update. 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 specifically excluded from comparison. The effect of wildcard names and data fields are discussed in Section 3. The message format used to implement an atomic transaction has a similar structure to that of a query, but the contents of some of the fields differ. An entity that initiates an update indicates in an update message the update operations to be performed along with the records to be updated. A name server responds to an update request by (a) indicating that the update has been successfully applied to the database at the primary name server, (b) indicating that the name server is not authoritative for the records specified, or (c) indi- cating an error. An update may be carried in a UDP datagram or a TCP connection. Expires July 31, 1995 [Page 3] INTERNET-DRAFT Dynamic DNS Updates January 1995 3. UPDATE MESSAGE FORMAT The message format has the following structure: the message header, which is similar to that of the query, and the message body, which consists of four sections, one per operation type. The four sections are in the order listed: the delete section, the add new record sec- tion, the add existing record section and the plain add secion. Each section contains the records that need to have the associated opera- tion applied. 3.1. Header Section 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DELCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | AECOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ACOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The differences between the query header and the update header are in the values that certain fields can assume, and in the semantics of certain fields. There is a new operation code (value to be defined) to specify an update request in the Opcode field. UPDATE TBD Expires July 31, 1995 [Page 4] INTERNET-DRAFT Dynamic DNS Updates January 1995 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 ADDNEW section, the number of records in the ADDEXIST section and the number of records in the ADD section, respectively. The other fields remain the same, except that they apply to update requests rather than queries. Note the AA bit is set in a response if and only if a server is authoritative for ALL nodes specified in the request. Also, the TC bit is not applicable to updates. The fields are set as follows in update requests and responses: Expires July 31, 1995 [Page 5] INTERNET-DRAFT Dynamic DNS Updates January 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) AA Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for all domain names in the message body. TC Bit is set to zero in an update request and copied into the response. The TC bit is ignored on receipt of a request or response. RD Recursion Desired - this bit may be set in a request and is copied into the response. If RD is set, it directs the name server to pursue the request recursively. Recursive update support is optional. RA Recursion Available - this be is set or cleared in a response, and denotes whether recursive update support is available in the name server. Z Reserved for future use. Must be zero in all requests and responses. 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 Expires July 31, 1995 [Page 6] INTERNET-DRAFT Dynamic DNS Updates January 1995 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 - Meaningful only for responses from an authoritative name server, this code signifies that one or more of the domain names referenced in the update request does not exist. 4 Not Implemented - The name server does not support the specified operation. 5 Refused - The name server refuses to perform the specified operation for policy reasons. 6 Alias Error - This code indicates that the domain name specified in an update is an alias. 7 Name Exists Error - This code indicates the name already exists. This return code is only meaningful from a server in response to an ADDNEW operation. 8 Record Not Exist Error - This code indicates that the resource record does not exist. This return code is only meaningful from a server in response to a DELETE operation. 9 Too many Zones Error - This code indicates that the records to be updated exist in more than one zone. 10 SERIAL RR Error - This code indicates that an operation on the SERIAL record is in error. 11 Permission Denied - This code indicates that the client has insufficient authority to perform the update. Expires July 31, 1995 [Page 7] INTERNET-DRAFT Dynamic DNS Updates January 1995 DELCOUNT an unsigned 16 bit integer specifying the number of resource records in the DELETE section. Always zero in a response. ANCOUNT an unsigned 16 bit integer specifying the number of resource records in the ADDNEW section. Always zero in a response. AECOUNT an unsigned 16 bit integer specifying the number of resource records in the ADDEXIST section. Always zero in a response. ACOUNT an unsigned 16 bit integer specifying the number of resource records in the ADD section. Always zero in a response. 3.2. Testing for Resource Record Equality The update operations require that records be compared. In particu- lar, the DELETE operation requires that the records to be deleted must exist. It has already been stated that records are tested for equality by comparing their name, class, type, data length and data values. The time-to-live value is excluded from the comparison. 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; the use of a wildcard name in a zone does not imply existence for updates. 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 data field containing the '*' character and a data length field of one is defined to match data in any other record. DISCUSSION: I believe the '*' data value does not match existing legal data values, expect for the NULL record, which is experimental and not supported by BIND. Expires July 31, 1995 [Page 8] INTERNET-DRAFT Dynamic DNS Updates January 1995 4. NAME SERVER BEHAVIOR From a client's perspective, any authoritative server can process an update request. Non-authoritative name servers forward the request to an authoritative name server if recursive service is specified or indicate to the client that the server is not authoritative for the records to 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. As mentioned above, a non-authoritative name server is also responsible for forwarding the update request to the primary, if recursive service is desired by the client and it is available. Unlike a secondary, however, a non-authoritative name server will need to determine the name servers authoritative for the domain names to be updated by asking other names servers for referrals if the information is not cached locally. A secondary name server will have this information preconfigured. Note that the forwarding of an update message is done synchronously on an update request, whether it is performed by a secondary name server or a non-authoritative server that provides recursive service. That is, a name server will wait for a response to a forwarded update request before returning the response to the client. 4.1. 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. 4.2. Algorithm On receiving an update request, the server's behavior will depend on whether recursive service is requested and available. If recursive Expires July 31, 1995 [Page 9] INTERNET-DRAFT Dynamic DNS Updates January 1995 service is requested and available, the server determines the set of authoritative name servers for the nodes specified in the transac- tion. The server sends the update to the set of name servers, waits for the response, and returns the response to the resolver. If recursive service is not requested or is not available, then the name server checks to see whether the update is in a zone for which it is authoritative. If so, the server attempts to perform the update if the name server is primary for the zone. If the name server is secondary for the zone, the server forwards the update to the pri- mary name server, waits for the response and returns the response to the resolver. Otherwise, if the name server is not authoritative for the zone to be updated, an error is returned. The algorithm for name server behavior is explained in more detail below (adapted from [RFC1034]): 1. Indicate in the response whether update recursion is available or not. If recursive service is available and requested, then the server uses the local resolver or a copy of its algorithm (Section 4) to perform the update operation. Otherwise, go to step 2. 2 Determine the names (RRNAMEs) associated with all records to be updated in the transaction. For each RRNAME, search the avail- able zones for the zone which is the nearest to RRNAME. a) If no zone is found, return a non-authoritative response indicating no error. Exit. b) If more than one zone is found, return a response indicat- ing that the update request is not restricted to a single zone. Exit. Otherwise, go to step 3. 3. If this is a secondary name server for the zone, forward the request to the primary and wait for the response. Send the response to the resolver. Exit. (A secondary may do further checking of the update request before sending to the primary for processing, if desired.) Otherwise, go to step 4. 4. Start the transaction 5. For each RRNAME in the update request, start matching down, Expires July 31, 1995 [Page 10] INTERNET-DRAFT Dynamic DNS Updates January 1995 label by label, in the zone (found in step 2). For each label, test for the following cases: a) If the whole RRNAME is matched, we have found the node to be updated. If the record at the node is a CNAME, and RRTYPE does not match CNAME, abort the transaction and return an authorita- tive response indicating an alias error. If the operation is ADDNEW, abort the transaction and return an authoritative response indicating that the name already exists. If the operation is ADDEXIST or ADD, check if the specified record already exists. If so, ignore. If the operation is DELETE, check if the specified record exists in the zone. If not, abort the transaction and return an authoritative response indicating that the record does not exist. Otherwise, perform the update operation tentatively. b) If we have a referral, abort the transaction. Return a non-authoritative response indicating no error. Exit. c) If at some label, a match is impossible (i.e. the label does not exist), and the operation is ADDEXIST or DELETE, abort the transaction and return an authoritative response indicating that the name does not exist. Otherwise, perform the update operation tentatively. 6 Commit the 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 incremented at this time. Indicate in the response that the server is authoritative and return a suc- cessful response. Exit. At the start of a transaction, the zone must be locked to prevent concurrent interleaving of concurrent 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 means that the changes are Expires July 31, 1995 [Page 11] INTERNET-DRAFT Dynamic DNS Updates January 1995 applied to the zone and are visible to subsequent queries to the pri- mary. (It is an implementation 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 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. 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. Expires July 31, 1995 [Page 12] INTERNET-DRAFT Dynamic DNS Updates January 1995 5. RESOLVER BEHAVIOR A resolver provides the application interface to name servers. A resolver must enable applications to perform both standard queries and updates. A stub resolver performs no resolution function itself, but must either be configured with a list of name servers that provide recur- sive service, i.e. name servers that can perform requests on the resolver's behalf, or be configured with the names of authoritative servers of zones that this resolver is known to be responsible for updating. A full-service resolver traverses the domain name space itself, pos- sibly querying several name servers to find the name servers authori- tative for the zone to be updated. A full-service resolver performs an update operation as follows (adapted from [RFC1034]): 1. If a resolver has direct access to a name server's authoritative data, determine the names (RRNAMEs) associated with all records to be updated in the transaction. For each RRNAME, search the available zones for the zone which is authoritative for RRNAME. a) If more than one zone is found, return a response indicat- ing that the update request is not restricted to a single zone. Exit. b) If a single authoritative zone is found, perform the update transaction in the relevant zone as outlined in Section 4.2. Exit. 2. If the zone is non-local, find the best servers to ask for any or all RRNAMEs. If the resolver finds that the RRNAMEs cannot be in the same zone, it returns a response indicating that the update is not constrained to a single zone and exits. 3. Send a query to one of the servers for any RRNAME, RRCLASS and RRTYPE to be updated in the zone. 4. Analyze the response: a) If the response is authoritative, go to step 5 b) If the response contains better delegation information, Expires July 31, 1995 [Page 13] INTERNET-DRAFT Dynamic DNS Updates January 1995 cache the delegation information and go to step 2. c) If the response shows a server failure or other bizarre contents, delete the server from the list of servers and go back to step 3. 5. Send an update to an authoritative name server. 6. Analyze the response: a) If the response shows a server failure or other bizarre contents, delete the server from the list of servers and go back to step 5. b) Otherwise, return the response to the client. The data structures used to represent the state of a query in pro- gress in the resolver are the same as that specified in RFC1034, except that the list that represents the resolver's best guess about which name servers to ask may include additional information per- tinent to updates, e.g. 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 July 31, 1995 [Page 14] INTERNET-DRAFT Dynamic DNS Updates January 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. A 128.96.33.22 foo.xyz.com. 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 A 128.96.33.33 ADD foo.xyz.com A 128.96.44.44 Both ADD or ADDEXIST would work in the above example to add the replacement record. 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 A 128.96.33.33 foo.xyz.com A 128.96.34.34 ADDEXIST foo.xyz.com CNAME bar.xyz.com ADDNEW bar.xyz.com A 128.61.44.33 Alternatively, the A records belonging to "foo" need not be individu- ally deleted. The wildcard data field can be used to delete all Expires July 31, 1995 [Page 15] INTERNET-DRAFT Dynamic DNS Updates January 1995 records associated with "foo" as follows: DELETE foo.xyz.com A * Also, both of the above add operations could be replaced by ADD. However, the existence checks would not then be applied. Expires July 31, 1995 [Page 16] INTERNET-DRAFT Dynamic DNS Updates January 1995 7. SERIAL RESOURCE RECORD A new resource record is defined that can be used to serialize update requests. Serialization is needed if updates can be concurrent or the update is dependent on the database being in a certain state. In particular, serialisation may be necessary to protect against dupli- cate messages. Duplicate messages arise when the transport protocol used does not guarantee otherwise, or when resolvers retransmit mes- sages because the transport protocol is unreliable. Also, malicious clients may deliberately replay old update requests. In general, to serialize requests, a token needs to be associated with the set of records to be updated. This token must be set to a different value on each update. The SERIAL resource record is defined to hold this token and to indicate the set of records associated with the token. The SERIAL record has the same name, class, and TTL values as the records to be protected. The name may contain the wild- card label in which case the SERIAL record covers all records in the zone (of the type specified in the data field), and can be used to serialize updates at the granularity of a zone. The data field of the record contains the type of the records protected and the token itself. The type may be any valid record type, or it may contain type ANY which means that the token covers all records associated with the name specified. The token is a 64-bit number (the exact definition of which is to be discussed below). The data field of the record is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RR type covered | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | token | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ To update the SERIAL record, a client MUST delete the current record explicitly and then add the new record with the new token value. The Expires July 31, 1995 [Page 17] INTERNET-DRAFT Dynamic DNS Updates January 1995 SERIAL record is the only record where the use of the wildcard data field when deleting records is invalid. This restriction ensures that the update of the token is itself serialized, by making sure that the change from the current token value to the new token value is done in a mutually exclusive manner. For example, given a zone containing a SERIAL RR as follows: xyz.com. SOA ns.xyz.com sysadm.xyz.com ( ... ) NS ns.xyz.com. ns.xyz.com. A 128.96.33.22 foo.xyz.com. SERIAL A 2157449756503 A 128.96.33.33 A 128.96.34.34 Updates to the A records would be serialized by using the following operations: DELETE foo.xyz.com SERIAL A 2157449756503 foo.xyz.com A * ADD foo.xyz.com SERIAL A 7575470909833451 foo.xyz.com A 128.96.44.44 foo.xyz.com A 128.96.55.55 FOR DISCUSSION: One approach would be to define the token as a random number. However, update serialization is only as good as the random numbers generated. If clients cannot be trusted to generate unique random numbers or it is too expensive to do so, an alternative approach is to define the token as a sequence number. This approach is cheap to implement, but does require that the name server inter- pret the value of the data field of the SERIAL RR added to determine that it is appropriately set. Another approach is to have the server responsible for generating the next token (in any way it liked). This also requires the server to interpret the data field of the SERIAL RR. Expires July 31, 1995 [Page 18] INTERNET-DRAFT Dynamic DNS Updates January 1995 8. 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]. If SIG records are not used to authenticate individual updates, the SERIAL record will need to be used to ensure against replay. 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. Expires July 31, 1995 [Page 19] INTERNET-DRAFT Dynamic DNS Updates January 1995 9. OPEN ISSUES 1. Should non-recursive updates perform referrals when an update is sent to a non-authoritative server? This is a bit less clean for updates than for queries, since multiple nodes can be specified in an atomic transaction. (A referral need only be to one of the nodes specified - any one will do. On the other hand, using queries to locate authoritative servers before sending an update is likely to be less efficient than using updates only. However, caching of queries should alleviate this. The usefulness of having updates perform referrals is not clear: a) While updates need to be reliable and hence might be car- ried using TCP, the recommended approach to get referrals is UDP. b) As a practical matter, it cannot be required that all name servers in DNS support dynamic updates. Thus, queries will always have to be used as the fallback mechanism for locat- ing the authoritative name servers for a dynamic zone. This document as it stands does not specify referrals. 10. ACKNOWLEDGEMENTS We would like to thank the DNSIND working group for their valuable input, in particular, Donald Eastlake. 11. REFERENCES Expires July 31, 1995 [Page 20] INTERNET-DRAFT Dynamic DNS Updates January 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 July 31, 1995 [Page 21] INTERNET-DRAFT Dynamic DNS Updates January 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 July 31, 1995 [Page 22]