Network Working Group February 1993 Internet-DRAFT v4.1 Using the Internet DNS to maintain X.400 MHS Routing Informations Claudio Allocchio (Allocchio@elettra.trieste.it) Antonio Blasco Bonito (bonito@cnuce.cnr.it) Bruce Cole (bcole@cisco.com) Silvia Giordano (giordano@cscs.ch) Robert Hagens (hagens@ans.net) GARR-Italy Cisco Systems Inc. Centro Svizzero Calcolo Scientifico Advanced Network & Services 0. Status of this memo This memo proposes a method of storing in the Internet Domain Name System the routing information needed by X.400 MTAs within an X.400 MHS. Routing information can be managed in a distributed rather than a centralized way. MTAs located on Internet hosts can retrieve the routing information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This document specifies a prototype standard proposal. This memo is a joint effort of X400 operation working group and RARE Mail and Messaging working group. Distribution of this memo is unlimited. Another document by the same authors describes a method to store and distribute the RFC1327 mapping information using the Internet DNS. 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." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Allocchio et. al. (Doc. expiration date: June 1993) [Page 1] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 1. Introduction The routing informations are an essential element to implement an efficient e-mail service within any community. In the Internet Domain Name System the "A" and "MX" records are used to store and distribute dynamically the routing information used by mailers to transport and deliver e-mail messages. In X.400 MHS usually static tables contain the routing data. In the early X.400 times, the MHS configurations were quite simple: a few well managed MTAs (often called "Well known Entry Point" or "WEP") were taking care of the whole routing for one or more communities; all the traffic was managed by static point-to-point connections among the WEPs, and often there was only one network transport available (usually X.25 or TCP with RFC1006). In this situation static tables proved to be enough to run such initial service. The rapid growth of X.400 Message Handling Systems, however, made very soon inadequate the use of a simple statically defined database: in fact the X.400 addresses tree grows daily adding new branches and many new MTAs show up either. More over a large number of X.400 implementations now support multiple transport stacks, allowing a real and global connectivity. Many efforts have been done in order to take in account this new situation, and a document defining the X.400 MHS routing strategy has been defined by Urs Eppenberger from SWITCH/COSINE MHS project team [EPPEN V3]. In that document the approach to the routing problem is again table driven, using the so called "DOMAIN" and "RELAY" tables (section 4). Two additional tables, "COMMUNITY" and "PERSON", complete the data about the X.400 MHS. That document, however, has been carefully designed to allow easily the store of the information it defines in distributed databases like DNS or X.500: our aim is to define the use of DNS to store those routing information. A first proposal to use the Internet DNS to store, to retrieve and to maintain X.400 related information (the RFC1327 mapping tables) was introduced by two of the authors (B. Cole and R. Hagens). However it required modifications to the actual Internet DNS nameservers and, due to the large variety of currently available implementations, this was unfeasible within a reasonable time. A different approach, using already defined, commonly available DNS resource-record types to store the information is proposed now. In addition, the use of a new domain name space is envisaged in order to fully implement a distributed X.400 routing information tree: again the MX resource-records will be used, jointly with some other ones needed to store the more complex X.400 routing data. The creation of the new domain name space also provides the chance to use the DNS to distribute dynamically the X.400 to/from RFC822 Allocchio et. al. (Doc. expiration date: June 1993) [Page 2] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 mapping information described in RFC1327, thus solving another efficiency problems currently affecting the X.400 MHS implementations. In this paper we will adopt the DOMAIN and RELAY document definitions from [EPPEN V3] routing coordination document. 1.1 Definitions syntax The definitions in this document is given in BNF-like syntax, using the following conventions: | means choice \ is used for continuation of a definition over several lines [] means optional {} means repeated one or more times The definitions, however, are detailed only until a certain level, and below it self-explaining character text strings will be used. 2. Motivation The implementation of a fully meshed connectivity among MTAs, and the ability to use at best the available network transport stacks require to disseminate complete and up to date routing data to all MTAs. In the Internet community, the DNS has proven to be a practical mean for providing a distributed name service. Advantages of using a DNS based system over a table based approach for mapping between O/R addresses and domain names are: - It avoids fetching and storing of entire routing tables by every MTA wishing to use full connectivity. - Modifications to the DNS based routing information can be made available in a more timely manner than with a table driven approach. - Table management is not necessarily required for DNS-based X.400 MTAs. - One can determine the routing in use by a remote MTA by querying the DNS (remote debugging). Routing decisions taken by the MTAs involved in delivering an X.400 message will also be more likely to result correct, if the routing information is updated in real time. 3. Proposal: the new "X400.ARPA" domain space Usual domain names (the ones normally used as the global part of an RFC822 e-mail address) and their associated information, i.e. host IP addresses, mail exchanger names, etc., are stored in the DNS as a Allocchio et. al. (Doc. expiration date: June 1993) [Page 3] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 distributed database under a number of top-level domains (EDU, COM, countries like UK, IT, FR, etc.). The special top-level/second-level couple IN-ADDR.ARPA is used to store the IP address to domain name relationship. Our proposal, which closely resembles the above model, is to store the X.400 routing data in a new branch of the DNS name space (under the already defined top-level domain "ARPA") using the MX and HINFO resource records. In particular in this new name space "X400.ARPA" we will have a complete set of existing resource records available to store any other useful information concerning X.400, like RFC1327 mappings, responsible people, etc. This name space is thus used to contain completely the information: the data required by an MTA to route an X.400 message to destination can be easily found with a simple query to the nearest nameserver. Moreover there is no more any need to store, maintain and distribute manually those tables. The special name space begins at the top-level "X400.ARPA" and should have a structure following the X.400 hierachical structure (country, ADMD, PRMD, organisation, ...). The fully qualified MX and HINFO resource-records are constructed starting from the information contained in the DOMAIN and RELAY documents. The construction of the new domain space tree will follow the same procedures used when organising at first the already existing DNS space: authoritative information about the X400.ARPA top-level domain is maintained by the root servers while a central nameserver in each country is delegated by the root servers to hold the national part of the routing tables. At first, however, the information will be stored in a quite centralised way, and distribution of authority will be gradually achieved. A separate document will describe the implementation phase. 4. Storing X.400 routing information In the usual domain name space the MX records are used to store information for SMTP mailers; their content is a list of possible Mail eXchanger and a pure number stating the preferred order of these mailers (priority). The creation of a new domain space under X400.ARPA top level domain, enables now us to use the MX resource records in it to store information about routing in the X.400 MHS, using the same principles adopted by SMTP mailers. Some other DNS resource records will then be used to store the additional data present in the RELAY and DOMAIN documents described in sect. 5.3 and 5.4 of [EPPEN V3] document. The syntax form of the usual MX record in DNS is: MX Allocchio et. al. (Doc. expiration date: June 1993) [Page 4] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 where is then resolved via an "A" resource record into an IP host address: in fact the only transport foreseen in DNS for SMTP protocol is TCP/IP, and the socket number 25 is already reserved. Also NJE, DDCMP and X.25 transports are used for SMTP (BSMTP, DSMTP and XSMTP), but their connection data are not included and distributed via DNS. In the X.400 MHS routing document we can identify these elements: which can be somehow equivalenced to the usual DNS elements. However the routing can be done on different protocol stacks, and each stack can have a different priority. Thus we have additional data for each specific stack like , , , . On the other hand, the MTA connection data are much more complex than a simple 4-byte IP address. We have in fact , , , , etc. and many of these elements are themselves a set of complex data. Thus we will need additional resource records to store these data. 4.1 Detailed storage proposal for routing information in DNS To implement in the most convenient way the storage of X.400 MHS routing data we can take advantage of the DNS MX records; in fact they already provide wildcard support and a priority mechanism. Other available DNS resource record types will be then used for the remaining RELAY data; in particular the HINFO resource record can be used for the RELAY connection and system data. Let us define the object which can be inserted into a DNS MX resource record: ::= "IN" "MX" \ where: ::= DNS translation of (sect. 4.3.1) ::= (see [EPPEN V3] sect. 5.4) ::= { ["-" ] "." } \ ::= A unique keyword to identify a and record (sect. 4.3.5) Allocchio et. al. (Doc. expiration date: June 1993) [Page 5] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 ::= DNS translation of (sect. 4.3.4) ::= DNS translation of (sect. 4.3.2) The presence of element in the DOMAIN document determines the distinction between wildcard and exact matching of an O/R address with : in DNS this will be implemented with the provided MX wildcard mechanism (see an example in section 4.3.1). The , as you can see, is the translation of the combination of and ; this requires the mandatory presence of the information, even if this information is defined as optional in [EPPEN V3]. The must in fact be located in the correct branch of the X400.ARPA DNS tree, i.e. exactly where the authority managing the RELAY lies. A similar situation occurs also for the location of the MTA object within the X.500 tree. As a consequence, for a community wishing to distribute its routing information via DNS, the element becomes mandatory. The additional data for a RELAY connection are stored into HINFO DNS resource records. In particular we need to store information about the RELAY itself (, , , ) and about the network connectivity (, and ). We define thus three records, which will be stored into three different DNS HINFO records: ::= "IN" "HINFO" \ " []" \ " { [ "." ] }" ::= "C.""." \ "IN" "HINFO" " " \ "" ::= "R.""." "IN" \ "HINFO" " " "" where: ::= DNS translation of (sect. 4.3.3) and , , , , are defined in [EPPEN V3], sect. 5.1 and 5.3. Note that the list contained into the record must contain exactly the same elements used for any couple of and records, i.e. is we have 3 couples of connection information records using "XX0", "RX0" and "IT6" keys, then this list must be present in the record. Allocchio et. al. (Doc. expiration date: June 1993) [Page 6] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 The HINFO resource record can hold up to twice 256 octet strings, allowing thus enough available space even for complex data. We can understand better the reason of the three HINFO resource records defined previously if we think of the multiple stacks available for an X.400 MHS: an MTA has some data which are independent from the network stack being used (stored into ) and on the contrary some other information depending upon it (stored into and ). 4.2 Basic mappings The formal definition of an MX resource record is (RFC1035, sect. 3.3.9): +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EXCHANGE / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same "owner name". EXCHANGE A which specifies a host willing to act as a mail exchange for the "owner name". and also the "owner name" is a element. At the same time the formal definition of an HINFO resource record is (RFC1035, sect. 3.3.2) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CPU / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / OS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CPU and OS area both of type and the "owner name" is a element. In our proposal, , , , and must thus be conformant with Allocchio et. al. (Doc. expiration date: June 1993) [Page 7] I-d v4.1 Internet DNS for X.400 MHS routing data February 1993 the syntax rules, i.e. ::= | " " ::=