Network Working Group C. Allocchio Request for Comments: 1664 A. Bonito Category: Experimental GARR-Italy B. Cole Cisco Systems Inc. S. Giordano Centro Svizzero Calcolo Scientifico R. Hagens Advanced Network & Services August 1994 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail and Messaging working group (WG-MSG). 1. Introduction The connectivity between the Internet SMTP mail and other mail services, including the Internet X.400 mail and the commercial X.400 service providers, is assured by the Mail eXchanger (MX) record information distributed via the Internet Domain Name System (DNS). A number of documents then specify in details how to convert or encode addresses from/to RFC822 style to the other mail system syntax. However, only conversion methods provide, via some algorithm or a set of mapping rules, a smooth translation, resulting in addresses indistinguishable from the native ones in both RFC822 and foreign world. RFC1327 describes a set of mappings which will enable interworking between systems operating the CCITT X.400 (1984/88) Recommendations Allocchio, Bonito, Cole, Giordano & Hagens [Page 1] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 and systems using the RFC822 mail protocol, or protocols derived from RFC822. That document addresses conversion of services, addresses, message envelopes, and message bodies between the two mail systems. This document is concerned with one aspect of RFC1327: the mechanism for mapping between X.400 O/R addresses and RFC822 domain names. As described in Appendix F of RFC1327, implementation of the mappings requires a database which maps between X.400 O/R addresses and domain names, and this database is statically defined. This approach requires many efforts to maintain the correct mapping: all the gateways need to get coherent tables to apply the same mappings, the conversion tables must be distributed among all the operational gateways, and also every update needs to be distributed. This static mechanism requires quite a long time to be spent modifying and distributing the information, putting heavy constraints on the time schedule of every update. In fact it does not appear efficient compared to the Internet Domain Name Service (DNS). More over it does not look feasible to distribute the database to a large number of other useful applications, like local address converters, e-mail User Agents or any other tool requiring the mapping rules to produce correct results. A first proposal to use the Internet DNS to store, retrieve and maintain those mappings was introduced by two of the authors (B. Cole and R. Hagens) adopting two new DNS resource record (RR) types: TO- X400 and TO-822. This new proposal adopts a more complete strategy, and requires one new RR only. The distribution of the RFC1327 mapping rules via DNS is in fact an important service for the whole Internet community: it completes the information given by MX resource record and it allows to produce clean addresses when messages are exchanged among the Internet RFC822 world and the X.400 one (both Internet and Public X.400 service providers). A first experiment in using the DNS without expanding the current set of RR and using available ones was in the mean time deployed by some of the authors. The existing PTR resource records were used to store the mapping rules, and a new DNS tree was created under the ".it" top level domain. The result of the experiment was positive, and a few test applications ran under this provisional set up. This test was also very useful in order to define a possible migration strategy during the deployment of the new DNS containing the new RR. The Internet DNS nameservers wishing to provide this mapping information need in fact to be modified to support the new RR type, and in the real Internet, due to the large number of different implementations, this takes some time. The basic idea is to adopt a new DNS RR to store the mapping information. The RFC822 to X.400 mapping rules (including the so Allocchio, Bonito, Cole, Giordano & Hagens [Page 2] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 called 'gate' rules) will be stored in the ordinary DNS tree, while the definition of a new branch of the name space defined under each national top level domain is envisaged in order to contain the X.400 to RFC822 mappings. A "two-way" mapping resolution schema is thus fully implemented. The creation of the new domain name space representing the X.400 O/R names structure also provides the chance to use the DNS to distribute dynamically other X.400 related information, thus solving other efficiency problems currently affecting the X.400 MHS service. In this paper we will adopt the RFC1327 mapping rules syntax, showing how it can be stored into the Internet DNS. 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 Implementations of RFC1327 gateways require that a database store address mapping information for X.400 and RFC822. This information must be disseminated to all RFC1327 gateways. 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 mapping tables by every host that wishes to implement RFC1327 gateways and/or tools - Modifications to the DNS based mapping information can be made available in a more timely manner than with a table driven approach. - It allows full authority delegation, in agreement with the Internet regionalization process. Allocchio, Bonito, Cole, Giordano & Hagens [Page 3] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 - Table management is not necessarily required for DNS-based RFC1327 gateways. - One can determine the mappings in use by a remote gateway by querying the DNS (remote debugging). Also many other tools, like address converters and User Agents can take advantage of the real-time availability of RFC1327 tables, allowing a much easier maintenance of the information. 3. The domain space for X.400 O/R name addresses 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 distributed database under a number of top-level domains. Some top- level domains are used for traditional categories or international organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand any country has its own two letter ISO country code as top-level domain (FR, DE, GB, IT, RU, ...), including "US" for USA. The special top-level/second-level couple IN-ADDR.ARPA is used to store the IP address to domain name relationship. Our proposal defines in the above structure the appropriate way to locate the X.400 O/R name space, thus enabling us to store in DNS the RFC1327 mapping data. The RFC1327 mapping information is composed by three tables: 'table1' gives the translation from X.400 to RFC822 while 'table2' and 'gate' tables map RFC822 into X.400. Each mapping table is composed by mapping rules, and a single mapping rule is composed by a keyword (the argument of the mapping function derived from the address to be translated) and a translator (the mapping function parameter): keyword#translator# the '#' sign is a delimiter enclosing the translator. An example: foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us# Local mappings are not intended for use outside their restricted environment, thus they should not be included in DNS. If local mappings are used, they should be stored using static local tables, exactly as local static host tables can be used with DNS. The keyword of a 'table2' and 'gate' table entry is a valid RFC822 domain; thus the usual domain name space can be used without problems to store these entries. Allocchio, Bonito, Cole, Giordano & Hagens [Page 4] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 On the other hand, the keyword of a 'table1' entry belongs to the X.400 O/R name space. The X.400 O/R name space does not usually fit into the usual domain name space, although there are a number of similarities; a new name structure is thus needed to represent it. This new name structure contains the X.400 mail domains. To ensure the correct functioning of the DNS system, the new X.400 name structure must be hooked to the existing domain name space in a way which respects the existing name hierarchy. A possible solution was to create another special branch, starting from the root of the DNS tree, somehow similar to the in-addr.arpa tree. This idea would have required to establish a central authority to coordinate at international level the management of each national X.400 name tree, including the X.400 public service providers. This coordination problem is a heavy burden if approached globally. More over the X.400 name structure is very 'country oriented': thus while it requires a coordination at national level, it does not have concepts like the international root. In fact the X.400 international service is based on a large number of bilateral agreements, and only within some communities an international coordination service exists. The X.400 two letter ISO country codes, however, are the same used for the RFC822 country top-level domains and this gives us an appropriate hook to insert the new branches. Our proposal is, in fact, to create under each national top level ISO country code a new branch in the name space. This branch represents exactly the X.400 O/R name structure as defined in each single country, following the ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed under each country top-level domain, and hence the national X.400 name space derives its own structure: Allocchio, Bonito, Cole, Giordano & Hagens [Page 5] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 . (root) | +-----------------+-----------+--------+-----------------+... | | | | edu it us fr | | | | +---+---+... +-----+-----+... +-----+-----+... +--+---+... | | | | | | | | | | ... ... cnr X42D infn va ca X42D X42D inria | | | | +------------+------------+... ... ... +----+-------+... | | | | | ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red | | | | +----------+----+... ... +-------+------+... ... | | | | PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault | | | | ... ... ... ... The creation of the X.400 new name tree at national level solves the problem of the international coordination. Actually the coordination problem is just moved at national level, but it thus becomes easier to solve. The coordination at national level between the X.400 communities and the Internet world is already a requirement for the creation of the national static RFC1327 mapping tables; the use of the Internet DNS gives further motivations for this coordination. The coordination at national level also fits in the ongoing proposal intended to define exactly the RFC1327 Mapping Authorities. The DNS in fact allows a step by step authority distribution, up to a final complete delegation, which can be easily controlled at national level accordingly with national needs and situations. A further advantage of the national based solution is to allow each country to set up its own X.400 name structure in DNS and to deploy its own authority delegation according to its local time scale and requirements, with no loss of global service in the mean time. And last, placing the new X.400 name tree and coordination process at national level fits into the Internet regionalization and internationalisation process, as it requires local bodies to take care of local coordination problems. The DNS name space thus contains completely the information required by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a simple query to the nearest nameserver provides it. Moreover there is no more any need to store, maintain and distribute manually any mapping table. The new X.400 name space can also contain further information about the X.400 community, as DNS allows for it a Allocchio, Bonito, Cole, Giordano & Hagens [Page 6] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 complete set of resource records, and thus it allows further developments. This set of RRs in the new X.400 name space must be considered 'reserved' and thus not used until further specifications. The construction of the new domain space trees will follow the same procedures used when organising at first the already existing DNS space: at first 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 and the methods to assure a smooth introduction of the new service. 4. The new DNS resource record for RFC1327 mapping rules: PX The specification of the Internet DNS (RFC1035) provides a number of specific resource records (RRs) to contain specific pieces of information. In particular they contain the Mail eXchanger (MX) RR and the host Address (A) records which are used by the Internet SMTP mailers. As we will store the RFC822 to X.400 mapping information in the already existing DNS name tree, we need to define a new DNS RR in order to avoid any possible clash or misuse of already existing data structures. The same new RR will also be used to store the mappings from X.400 to RFC822. More over the mapping information, i.e., the RFC1327 mapping rules, has a specific format and syntax which require an appropriate data structure and processing. A further advantage of defining a new RR is the ability to include flexibility for some eventual future development. The definition of the new 'PX' DNS resource record is: class: IN (Internet) name: PX (pointer to X.400/RFC822 mapping information) value: 26 The PX RDATA format is: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MAP822 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MAPX400 / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: Allocchio, Bonito, Cole, Giordano & Hagens [Page 7] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred; MAP822 A element containing , the RFC822 part of the RFC1327 mapping information; MAPX400 A element containing the value of derived from the X.400 part of the RFC1327 mapping information (see sect. 4.2); PX records cause no additional section processing. The PX RR format is the usual one: [] [] When we store in DNS a 'table1' entry, then will be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we store a 'table2' or a 'gate' table entry, will be an RFC822 mail domain name, including both fully qualified DNS domains and mail only domains (MX-only domains). All normal DNS conventions, like default values, wildcards, abbreviations and message compression, apply also for all the components of the PX RR. In particular , MAP822 and MAPX400, as elements, must have the final "." (root) when they are fully qualified. 4.1 Additional features of the PX resource record The definition of the RDATA for the PX resource record, and the fact that DNS allows a distinction between an exact value and a wildcard match for the parameter, represent an extension of the RFC1327 specification for mapping rules. In fact, any RFC1327 mapping table entry is an implicit wildcard entry, i.e., the rule net2.it#PRMD$net2.ADMD$p400.C$it# covers any RFC822 domain ending with 'net2.it', unless more detailed rules for some subdomain in 'net2.it' are present. Thus there is no possibility to specify explicitly an RFC1327 entry as an exact match only rule. In DNS an entry like *.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it. specify the usual wildcard match as for RFC1327 tables. However an entry like ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it. Allocchio, Bonito, Cole, Giordano & Hagens [Page 8] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 is valid only for an exact match of 'ab.net2.it' RFC822 domain. Note also that in DNS syntax there is no '#' delimiter around MAP822 and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not allow the (ASCII decimal 32) character within these fields, making unneeded the use of an explicit delimiter as required in the RFC1327 original syntax. Another extension to the RFC1327 specifications is the PREFERENCE value defined as part of the PX RDATA section. This numeric value has exactly the same meaning than the similar one used for the MX RR. It is thus possible to specify more than one single mapping for a domain (both from RFC822 to X.400 and vice versa), giving as the preference order. In RFC1327 static tables, however, you cannot specify more than one mapping per each RFC822 domain, and the same restriction apply for any X.400 domain mapping to an RFC822 one. More over, in the X.400 recommendations a note suggests than an ADMD= should be reserved for some special cases. Various national functional profile specifications for an X.400 MHS states that if an X.400 PRMD is reachable via any of its national ADMDs, independently of its actual single or multiple connectivity with them, it should use ADMD= to advertise this fact. Again, if a PRMD has no connections to any ADMD it should use ADMD=0 to notify its status, etc. However, in most of the current real situations, the ADMD service providers do not accept messages coming from their subscribers if they have a blank ADMD, forcing them to have their own ADMD value. In such a situation there are problems in indicating properly the actually working mappings for domains with multiple connectivity. The PX RDATA 'PREFERENCE' extension was introduced to take in consideration these problems. However, as these extensions are not available with RFC1327 static tables, it is strongly discouraged to use them when interworking with any table based gateway or application. The extensions were in fact introduced just to add more flexibility, like the PREFERENCE value, or they were already implicit in the DNS mechanism, like the wildcard specification. They should be used very carefully or just considered 'reserved for future use'. In particular, for current use, the PREFERENCE value in the PX record specification should be fixed to a value of 50, and only wildcard specifications should be used when specifying values. 4.2 The DNS syntax for an X.400 'domain' The syntax definition of the RFC1327 mapping rules is defined in appendix F of that document. However that syntax is not very human oriented and contains a number of characters which have a special Allocchio, Bonito, Cole, Giordano & Hagens [Page 9] RFC 1664 Internet DNS for Mail Mapping Tables August 1994 meaning in other fields of the Internet DNS. Thus in order to avoid any possible problem, especially due to some old DNS implementations still being used in the Internet, we define a syntax for the X.400 part of any RFC1327 mapping rules (and hence for any X.400 O/R name) which makes it compatible with a element, i.e., ::= | " " ::=