diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2163.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2163.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2163.txt b/contrib/bind9/doc/rfc/rfc2163.txt new file mode 100644 index 000000000000..00fcee7c8843 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc2163.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 2163 GARR-Italy +Obsoletes: 1664 January 1998 +Category: Standards Track + + + Using the Internet DNS to Distribute + MIXER Conformant Global Address Mapping (MCGAM) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This memo is the complete technical specification to store in the + Internet Domain Name System (DNS) the mapping information (MCGAM) + needed by MIXER conformant 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. Organizations can publish their MIXER mapping or preferred + gateway routing information using just local resources (their local + DNS server), avoiding the need for a strong coordination with any + centralised organization. MIXER conformant gateways and tools 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 obsoletes RFC1664. It includes the changes introduced by + MIXER specification with respect to RFC1327: the new 'gate1' (O/R + addresses to domain) table is fully supported. Full backward + compatibility with RFC1664 specification is mantained, too. + + RFC1664 was a joint effort of IETF X400 operation working group + (x400ops) and TERENA (formely named "RARE") Mail and Messaging + working group (WG-MSG). This update was performed by the IETF MIXER + working group. + + + + + + +Allocchio Standards Track [Page 1] + +RFC 2163 MIXER MCGAM January 1998 + + +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. + + MIXER describes a set of mappings (MIXER Conformant Global Address + Mapping - MCGAM) which will enable interworking between systems + operating the CCITT X.400 (1984/88/92) Recommendations and systems + using 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 MIXER: the mechanism + for mapping between X.400 O/R addresses and RFC822 domain names. As + described in Appendix F of MIXER, implementation of the mappings + requires a database which maps between X.400 O/R addresses and domain + names; in RFC1327 this database was statically defined. + + The original approach in RFC1327 required many efforts to maintain + the correct mapping: all the gateways needed to get coherent tables + to apply the same mappings, the conversion tables had to be + distributed among all the operational gateways, and also every update + needed to be distributed. + + The concept of mapping rules distribution and use has been revised in + the new MIXER specification, introducing the concept of MIXER + Conformant Global Address Mapping (MCGAM). A MCGAM does not need to + be globally installed by any MIXER conformant gateway in the world + any more. However MIXER requires now efficient methods to publish its + MCGAM. + + Static tables are one of the possible methods to publish MCGAM. + However 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. + + + + +Allocchio Standards Track [Page 2] + +RFC 2163 MIXER MCGAM January 1998 + + + Two much more efficient methods are proposed by MIXER for publication + of MCGAM: the Internet DNS and X.500. This memo is the complete + technical specification for publishing MCGAM via Internet DNS. + + A first proposal to use the Internet DNS to store, retrieve and + maintain those mappings was introduced by two of the authors of + RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record + (RR) types: TO-X400 and TO-822. This proposal now adopts a more + complete strategy, and requires one new RR only. The distribution of + MCGAMs 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 deployed by some of the authors of + RFC1664 at the time of its development. 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 + called 'gate2' 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 ('table1' and 'gate1'). 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 MCGAM syntax, showing how it can be + stored into the Internet DNS. + + + + + + + + +Allocchio Standards Track [Page 3] + +RFC 2163 MIXER MCGAM January 1998 + + +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 MIXER gateways require that a database store + address mapping information for X.400 and RFC822. This information + must be made available (published) to all MIXER 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 MIXER 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. + + - Table management is not necessarily required for DNS-based + MIXER 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 MIXER 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 + + + +Allocchio Standards Track [Page 4] + +RFC 2163 MIXER MCGAM January 1998 + + + 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. This memo defines in the + above structure the appropriate way to locate the X.400 O/R name + space, thus enabling to store in DNS the MIXER mappings (MCGAMs). + + The MIXER mapping information is composed by four tables: + + - 'table1' and 'gate1' gives the translation from X.400 to RFC822; + - 'table2' and 'gate2' 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 'gate2' table entry is a valid RFC822 + domain; thus the usual domain name space can be used without problems + to store these entries. + On the other hand, the keyword of a 'table1' and 'gate1' 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 + + + +Allocchio Standards Track [Page 5] + +RFC 2163 MIXER MCGAM January 1998 + + + 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. The 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: + + . (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 MIXER mapping tables; the use of the + Internet DNS gives further motivations for this coordination. + + + + +Allocchio Standards Track [Page 6] + +RFC 2163 MIXER MCGAM January 1998 + + + The coordination at national level also fits in the new concept of + MCGAM pubblication. The DNS in fact allows a step by step authority + distribution, up to a final complete delegation: thus organizations + whishing to publish their MCGAM just need to receive delegation also + for their branch of the new X.400 name space. 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 + 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 MIXER 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 + MCGAMs, 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. + + + + + + +Allocchio Standards Track [Page 7] + +RFC 2163 MIXER MCGAM January 1998 + + + 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: + + 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 <domain-name> element containing <rfc822-domain>, the + RFC822 part of the MCGAM; + + MAPX400 A <domain-name> element containing the value of + <x400-in-domain-syntax> derived from the X.400 part of + the MCGAM (see sect. 4.2); + + PX records cause no additional section processing. The PX RR format + is the usual one: + + <name> [<class>] [<TTL>] <type> <RDATA> + + When we store in DNS a 'table1' or a 'gate1' entry, then <name> will + be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we + store a 'table2' or a 'gate2' table entry, <name> 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 <name>, + MAP822 and MAPX400, as <domain-name> elements, must have the final + "." (root) when they are fully qualified. + + + + +Allocchio Standards Track [Page 8] + +RFC 2163 MIXER MCGAM January 1998 + + +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 <name> parameter, represent an extension of the MIXER + specification for mapping rules. In fact, any MCGAM 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 a MCGAM 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 MIXER tables. However an + entry like + + ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it. + + 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 <blank> (ASCII decimal 32) character within these fields, + making unneeded the use of an explicit delimiter as required in the + MIXER original syntax. + + Another extension to the MIXER 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 MIXER 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=<blank> 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=<blank> 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 + + + +Allocchio Standards Track [Page 9] + +RFC 2163 MIXER MCGAM January 1998 + + + 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 MIXER 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 <name> values. + +4.2 The DNS syntax for an X.400 'domain' + + The syntax definition of the MCGAM 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 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 + MCGAM rules (and hence for any X.400 O/R name) which makes it + compatible with a <domain-name> element, i.e., + + <domain-name> ::= <subdomain> | " " + <subdomain> ::= <label> | <label> "." <subdomain> + <label> ::= <alphanum>| + <alphanum> {<alphanumhyphen>} <alphanum> + <alphanum> ::= "0".."9" | "A".."Z" | "a".."z" + <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-" + + (see RFC1035, section 2.3.1, page 8). The legal character set for + <label> does not correspond to the IA5 Printablestring one used in + MIXER to define MCGAM rules. However a very simple "escape mechanism" + can be applied in order to bypass the problem. We can in fact simply + describe the X.400 part of a MCGAM rule format as: + + <map-rule> ::= <map-elem> | <map-elem> { "." <map-elem> } + <map-elem> ::= <attr-label> "$" <attr-value> + <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU" + <attr-value> ::= " " | "@" | IA5-Printablestring + + + + + + +Allocchio Standards Track [Page 10] + +RFC 2163 MIXER MCGAM January 1998 + + + As you can notice <domain-name> and <map-rule> look similar, and also + <label> and <map-elem> look the same. If we define the correct method + to transform a <map-elem> into a <label> and vice versa the problem + to write a MCGAM rule in <domain-name> syntax is solved. + + The RFC822 domain part of any MCGAM rule is of course already in + <domain-name> syntax, and thus remains unchanged. + + In particular, in a 'table1' or 'gate1' mapping rule the 'keyword' + value must be converted into <x400-in-domain-syntax> (X.400 mail DNS + mail domain), while the 'translator' value is already a valid RFC822 + domain. Vice versa in a 'table2' or 'gate2' mapping rule, the + 'translator' must be converted into <x400-in-domain-syntax>, while + the 'keyword' is already a valid RFC822 domain. + +4.2.1 IA5-Printablestring to <alphanumhyphen> mappings + + The problem of unmatching IA5-Printablestring and <label> character + set definition is solved by a simple character mapping rule: whenever + an IA5 character does not belong to <alphanumhyphen>, then it is + mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A + small set of special rules is also defined for the most frequent + cases. Moreover some frequent characters combinations used in MIXER + rules are also mapped as special cases. + + Let's then define the following simple rules: + + MCGAM rule DNS store translation conditions + ----------------------------------------------------------------- + <attr-label>$@ <attr-label> missing attribute + <attr-label>$<blank> <attr-label>"b" blank attribute + <attr-label>$xxx <attr-label>-xxx elsewhere + + Non <alphanumhyphen> characters in <attr-value>: + + MCGAM rule DNS store translation conditions + ----------------------------------------------------------------- + - -h- hyphen + \. -d- quoted dot + <blank> -b- blank + <non A/N character> -<3digit-decimal>- elsewhere + + If the DNS store translation of <attr-value> happens to end with an + hyphen, then this last hyphen is omitted. + + Let's now have some examples: + + + + + +Allocchio Standards Track [Page 11] + +RFC 2163 MIXER MCGAM January 1998 + + + MCGAM rule DNS store translation conditions + ----------------------------------------------------------------- + PRMD$@ PRMD missing attribute + ADMD$<blank> ADMDb blank attribute + ADMD$400-net ADMD-400-h-net hyphen mapping + PRMD$UK\.BD PRMD-UK-d-BD quoted dot mapping + O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen + PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping + O$-123-b O--h-123-h-b hyphen mapping + OU$123-x OU-123-h-x hyphen mapping + PRMD$Adis+co PRMD-Adis-043-co 3digit mapping + + Thus, an X.400 part from a MCGAM like + + OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc + + translates to + + OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc + + Another example: + + OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB + + translates to + + OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB + +4.2.2 Flow chart + + In order to achieve the proper DNS store translations of the X.400 + part of a MCGAM or any other X.400 O/R name, some software tools will + be used. It is in fact evident that the above rules for converting + mapping table from MIXER to DNS format (and vice versa) are not user + friendly enough to think of a human made conversion. + + To help in designing such tools, we describe hereunder a small flow + chart. The fundamental rule to be applied during translation is, + however, the following: + + "A string must be parsed from left to right, moving appropriately + the pointer in order not to consider again the already translated + left section of the string in subsequent analysis." + + + + + + + + +Allocchio Standards Track [Page 12] + +RFC 2163 MIXER MCGAM January 1998 + + + Flow chart 1 - Translation from MIXER to DNS format: + + parse single attribute + (enclosed in "." separators) + | + (yes) --- <label>$@ ? --- (no) + | | + map to <label> (no) <label>$<blank> ? (yes) + | | | + | map to <label>- map to <label>"b" + | | | + | map "\." to -d- | + | | | + | map "-" to -h- | + | | | + | map non A/N char to -<3digit>- | + restart | | | + ^ | remove (if any) last "-" | + | | | | + | \-------> add a "." <--------------/ + | | + \---------- take next attribute (if any) + + + Flow chart 2 - Translation from DNS to MIXER format: + + + parse single attribute + (enclosed in "." separators) + | + (yes) ---- <label> ? ---- (no) + | | + map to <label>$@ (no) <label>"b" ? (yes) + | | | + | map to <label>$ map to <label>$<blank> + | | | + | map -d- to "\." | + | | | + | map -h- to "-" | + | | | + | map -b- to " " | + restart | | | + ^ | map -<3digit>- to non A/N char | + | | | | + | \--------> add a "." <----------/ + | | + \------------- take next attribute (if any) + + + + +Allocchio Standards Track [Page 13] + +RFC 2163 MIXER MCGAM January 1998 + + + Note that the above flow charts deal with the translation of the + attributes syntax, only. + +4.2.3 The Country Code convention in the <name> value. + + The RFC822 domain space and the X.400 O/R address space, as said in + section 3, have one specific common feature: the X.400 ISO country + codes are the same as the RFC822 ISO top level domains for countries. + In the previous sections we have also defined a method to write in + <domain-name> syntax any X.400 domain, while in section 3 we + described the new name space starting at each country top level + domain under the X42D.cc (where 'cc' is then two letter ISO country + code). + + The <name> value for a 'table1' or 'gate1' entry in DNS should thus + be derived from the X.400 domain value, translated to <domain-name> + syntax, adding the 'X42D.cc.' post-fix to it, i.e., + + ADMD$acme.C$fr + + produces in <domain-name> syntax the key: + + ADMD-acme.C-fr + + which is post-fixed by 'X42D.fr.' resulting in: + + ADMD-acme.C-fr.X42D.fr. + + However, due to the identical encoding for X.400 country codes and + RFC822 country top level domains, the string 'C-fr.X42D.fr.' is + clearly redundant. + + We thus define the 'Country Code convention' for the <name> key, + i.e., + + "The C-cc section of an X.400 domain in <domain-name> syntax must + be omitted when creating a <name> key, as it is identical to the + top level country code used to identify the DNS zone where the + information is stored". + + Thus we obtain the following <name> key examples: + + X.400 domain DNS <name> key + -------------------------------------------------------------------- + ADMD$acme.C$fr ADMD-acme.X42D.fr. + PRMD$ux\.av.ADMD$ .C$gb PRMD-ux-d-av.ADMDb.X42D.gb. + PRMD$ppb.ADMD$Dat 400.C$de PRMD-ppb.ADMD-Dat-b-400.X42D.de. + + + + +Allocchio Standards Track [Page 14] + +RFC 2163 MIXER MCGAM January 1998 + + +4.3 Creating the appropriate DNS files + + Using MIXER's assumption of an asymmetric mapping between X.400 and + RFC822 addresses, two separate relations are required to store the + mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS + we will maintain the two different sections, even if they will both + use the PX resource record. More over MIXER also specify two + additional tables: MIXER 'gate1' and 'gate2' tables. These additional + tables, however, have the same syntax rules than MIXER 'table1' and + 'table2' respectively, and thus the same translation procedure as + 'table1' and 'table2' will be applied; some details about the MIXER + 'gate1' and 'gate2' tables are discussed in section 4.4. + + Let's now check how to create, from an MCGAM entry, the appropriate + DNS entry in a DNS data file. We can again define an MCGAM entry as + defined in appendix F of that document as: + + <x400-domain>#<rfc822-domain># (case A: 'table1' and 'gate1' + entry) + + and + + <rfc822-domain>#<x400-domain># (case B: 'table2' and 'gate2' + entry) + + The two cases must be considered separately. Let's consider case A. + + - take <x400-domain> and translate it into <domain-name> syntax, + obtaining <x400-in-domain-syntax>; + - create the <name> key from <x400-in-domain-syntax> i.e., apply + the Country Code convention described in sect. 4.2.3; + - construct the DNS PX record as: + + *.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax> + + Please note that within PX RDATA the <rfc822-domain> precedes the + <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry. + + an example: from the 'table1' rule + + PRMD$ab.ADMD$ac.C$fr#ab.fr# + + we obtain + + *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr. + + Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are + fully qualified <domain-name> elements, thus ending with a ".". + + + +Allocchio Standards Track [Page 15] + +RFC 2163 MIXER MCGAM January 1998 + + + Let's now consider case B. + + - take <rfc822-domain> as <name> key; + - translate <x400-domain> into <x400-in-domain-syntax>; + - construct the DNS PX record as: + + *.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax> + + an example: from the 'table2' rule + + ab.fr#PRMD$ab.ADMD$ac.C$fr# + + we obtain + + *.ab.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr. + + Again note the fully qualified <domain-name> elements. + + A file containing the MIXER mapping rules and MIXER 'gate1' and + 'gate2' table written in DNS format will look like the following + fictious example: + + ! + ! MIXER table 1: X.400 --> RFC822 + ! + *.ADMD-acme.X42D.it. IN PX 50 it. ADMD-acme.C-it. + *.PRMD-accred.ADMD-tx400.X42D.it. IN PX 50 \ + accred.it. PRMD-accred.ADMD-tx400.C-it. + *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it. IN PX 50 \ + cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it. + ! + ! MIXER table 2: RFC822 --> X.400 + ! + *.nrc.it. IN PX 50 nrc.it. PRMD-nrc.ADMD-acme.C-it. + *.ninp.it. IN PX 50 ninp.it. O.PRMD-ninp.ADMD-acme.C-it. + *.bd.it. IN PX 50 bd.it. PRMD-uk-d-bd.ADMDb.C-it. + ! + ! MIXER Gate 1 Table + ! + *.ADMD-XKW-h-Mail.X42D.it. IN PX 50 \ + XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G. + *.PRMD-Super-b-Inc.ADMDb.X42D.it. IN PX 50 \ + GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G. + ! + ! MIXER Gate 2 Table + ! + my.it. IN PX 50 my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G. + co.it. IN PX 50 co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G. + + + +Allocchio Standards Track [Page 16] + +RFC 2163 MIXER MCGAM January 1998 + + + (here the "\" indicates continuation on the same line, as wrapping is + done only due to typographical reasons). + + Note the special suffix ".G." on the right side of the 'gate1' and + 'gate2' Tables section whose aim is described in section 4.4. The + corresponding MIXER tables are: + + # + # MIXER table 1: X.400 --> RFC822 + # + ADMD$acme.C$it#it# + PRMD$accred.ADMD$tx400.C$it#accred.it# + O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it# + # + # MIXER table 2: RFC822 --> X.400 + # + nrc.it#PRMD$nrc.ADMD$acme.C$it# + ninp.it#O.PRMD$ninp.ADMD$acme.C$it# + bd.it#PRMD$uk\.bd.ADMD$ .C$it# + # + # MIXER Gate 1 Table + # + ADMD$XKW-Mail.C$it#XKW-gateway.it# + PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it# + # + # MIXER Gate 2 Table + # + my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it# + co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t# + +4.4 Storing the MIXER 'gate1' and 'gate2' tables + + Section 4.3.4 of MIXER also specify how an address should be + converted between RFC822 and X.400 in case a complete mapping is + impossible. To allow the use of DDAs for non mappable domains, the + MIXER 'gate2' table is thus introduced. + + In a totally similar way, when an X.400 address cannot be completely + converted in RFC822, section 4.3.5 of MIXER specifies how to encode + (LHS encoding) the address itself, pointing then to the appropriate + MIXER conformant gateway, indicated in the MIXER 'gate1' table. + + DNS must store and distribute also these 'gate1' and 'gate2' data. + + One of the major features of the DNS is the ability to distribute the + authority: a certain site runs the "primary" nameserver for one + determined sub-tree and thus it is also the only place allowed to + update information regarding that sub-tree. This fact allows, in our + + + +Allocchio Standards Track [Page 17] + +RFC 2163 MIXER MCGAM January 1998 + + + case, a further additional feature to the table based approach. In + fact we can avoid one possible ambiguity about the use of the 'gate1' + and 'gate2' tables (and thus of LHS and DDAs encoding). + + The authority maintaining a DNS entry in the usual RFC822 domain + space is the only one allowed to decide if its domain should be + mapped using Standard Attributes (SA) syntax or Domain Defined + Attributes (DDA) one. If the authority decides that its RFC822 domain + should be mapped using SA, then the PX RDATA will be a 'table2' + entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822 + domain we cannot have any more two possible entries, one from 'table2 + and another one from 'gate2' table, and the action for a gateway + results clearly stated. + + Similarly, the authority mantaining a DNS entry in the new X.400 name + space is the only one allowed to decide if its X.400 domain should be + mapped using SA syntax or Left Hand Side (LHS) encoding. If the + authority decides that its X.400 domain should be mapped using SA, + then the PX RDATA will be a 'table1' entry, otherwise it will be a + 'gate1' table entry. Thus also for an X.400 domain we cannot have any + more two possible entries, one from 'table1' and another one from + 'gate1' table, and the action for a gateway results clearly stated. + + The MIXER 'gate1' table syntax is actually identical to MIXER + 'table1', and 'gate2' table syntax is identical to MIXER 'table2'. + Thus the same syntax translation rules from MIXER to DNS format can + be applied in both cases. However a gateway or any other application + must know if the answer it got from DNS contains some 'table1', + 'table2' or some 'gate1', 'gate2' table information. This is easily + obtained flagging with an additional ".G." post-fix the PX RDATA + value when it contains a 'gate1' or 'gate2' table entry. The example + in section 4.3 shows clearly the result. As any X.400 O/R domain must + end with a country code ("C-xx" in our DNS syntax) the additional + ".G." creates no conflicts or ambiguities at all. This postfix must + obviously be removed before using the MIXER 'gate1' or 'gate2' table + data. + +5. Finding MIXER mapping information from DNS + + The MIXER mapping information is stored in DNS both in the normal + RFC822 domain name space, and in the newly defined X.400 name space. + The information, stored in PX resource records, does not represent a + full RFC822 or X.400 O/R address: it is a template which specifies + the fields of the domain that are used by the mapping algorithm. + + When mapping information is stored in the DNS, queries to the DNS are + issued whenever an iterative search through the mapping table would + be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping + + + +Allocchio Standards Track [Page 18] + +RFC 2163 MIXER MCGAM January 1998 + + + B). Due to the DNS search mechanism, DNS by itself returns the + longest possible match in the stored mapping rule with a single + query, thus no iteration and/or multiple queries are needed. As + specified in MIXER, a search of the mapping table will result in + either success (mapping found) or failure (query failed, mapping not + found). + + When a DNS query is issued, a third possible result is timeout. If + the result is timeout, the gateway operation is delayed and then + retried at a later time. A result of success or failure is processed + according to the algorithms specified in MIXER. If a DNS error code + is returned, an error message should be logged and the gateway + operation is delayed as for timeout. These pathological situations, + however, should be avoided with a careful duplication and chaching + mechanism which DNS itself provides. + + Searching the nameserver which can authoritatively solve the query is + automatically performed by the DNS distributed name service. + +5.1 A DNS query example + + An MIXER mail-gateway located in the Internet, when translating + addresses from RFC822 to X.400, can get information about the MCGAM + rule asking the DNS. As an example, when translating the address + SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX + resource record. The DNS should contain a PX record like this: + + *.cce.nrc.it. IN PX 50 cce.nrc.it. O-cce.PRMD-nrc.ADMD-acme.C-it. + + The first query will return immediately the appropriate mapping rule + in DNS store format. + + There is no ".G." at the end of the obtained PX RDATA value, thus + applying the syntax translation specified in paragraph 4.2 the MIXER + Table 2 mapping rule will be obtained. + + Let's now take another example where a 'gate2' table rule is + returned. If we are looking for an RFC822 domain ending with top + level domain "MW", and the DNS contains a PX record like this, + + *.mw. IN PX 50 mw. O-cce.PRMD-nrc.ADMD-acme.C-it.G. + + DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a + 'gate2' table entry in DNS store format. Dropping the final ".G." and + applying the syntax translation specified in paragraph 4.2 the + original rule will be available. More over, the ".G." flag also tells + the gateway to use DDA encoding for the inquired RFC822 domain. + + + + +Allocchio Standards Track [Page 19] + +RFC 2163 MIXER MCGAM January 1998 + + + On the other hand, translating from X.400 to RFC822 the address + + C=de; ADMD=pkz; PRMD=nfc; O=top; + + the mail gateway should convert the syntax according to paragraph + 4.2, apply the 'Country code convention' described in 4.2.3 to derive + the appropriate DNS translation of the X.400 O/R name and then query + DNS for the corresponding PX resource record. The obtained record for + which the PX record must be queried is thus: + + O-top.PRMD-nfc.ADMD-pkz.X42D.de. + + The DNS could contain: + + *.ADMD-pkz.X42D.de. IN PX 50 pkz.de. ADMD-pkz.C-de. + + Assuming that there are not more specific records in DNS, the + wildcard mechanism will return the MIXER 'table1' rule in encoded + format. + + Finally, an example where a 'gate1' rule is involved. If we are + looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the + DNS contains a PX record like this, + + *.ADMD-PWT400.X42D.us. IN PX 50 intGw.com. ADMD-PWT400.C-us.G. + + DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a + 'gate1' table entry in DNS store format. Dropping the final ".G." and + applying the syntax translation specified in paragraph 4.2 the + original rule will be available. More over, the ".G." flag also tells + the gateway to use LHS encoding for the inquired X.400 domain. + +6. Administration of mapping information + + The DNS, using the PX RR, is able to distribute the MCGAM rules to + all MIXER gateways located on the Internet. However, not all MIXER + gateways will be able to use the Internet DNS. It is expected that + some gateways in a particular management domain will conform to one + of the following models: + + (a) Table-based, (b) DNS-based, (c) X.500-based + + Table-based management domains will continue to publish their MCGAM + rules and retrieve the mapping tables via the International Mapping + Table coordinator, manually or via some automated procedures. Their + MCGAM information can be made available also in DNS by the + appropriate DNS authorities, using the same mechanism already in + place for MX records: if a branch has not yet in place its own DNS + + + +Allocchio Standards Track [Page 20] + +RFC 2163 MIXER MCGAM January 1998 + + + server, some higher authority in the DNS tree will provide the + service for it. A transition procedure similar to the one used to + migrate from the 'hosts.txt' tables to DNS can be applied also to the + deployment phase of this specification. An informational document + describing the implementation phase and the detailed coordination + procedures is expected. + + Another distributed directory service which can distribute the MCGAM + information is X.500. Coordination with table-based domains can be + obtained in an identical way as for the DNS case. + + Coordination of MCGAM information between DNS and X.500 is more + complex, as it requies some kind of uploading information between the + two systems. The ideal solution is a dynamic alignment mechanism + which transparently makes the DNS mapping information available in + X.500 and vice versa. Some work in this specific field is already + being done [see Costa] which can result in a global transparent + directory service, where the information is stored in DNS or in + X.500, but is visible completely by any of the two systems. + + However we must remind that MIXER concept of MCGAM rules publication + is different from the old RFC1327 concept of globally distributed, + coordinated and unique mapping rules. In fact MIXER does not requires + any more for any conformant gateway or tool to know the complete set + of MCGAM: it only requires to use some set (eventually empty) of + valid MCGAM rules, published either by Tables, DNS or X.500 + mechanisms or any combination of these methods. More over MIXER + specifies that also incomplete sets of MCGAM can be used, and + supplementary local unpublished (but valid) MCGAM can also be used. + As a consequence, the problem of coordination between the three + systems proposed by MIXER for MCGAM publication is non essential, and + important only for efficient operational matters. It does not in fact + affect the correct behaviour of MIXER conformant gateways and tools. + +7. Conclusion + + The introduction of the new PX resource record and the definition of + the X.400 O/R name space in the DNS structure provide a good + repository for MCGAM information. The mapping information is stored + in the DNS tree structure so that it can be easily obtained using the + DNS distributed name service. At the same time the definition of the + appropriate DNS space for X.400 O/R names provide a repository where + to store and distribute some other X.400 MHS information. The use of + the DNS has many known advantages in storing, managing and updating + the information. A successful number of tests were been performed + under the provisional top level domain "X400.IT" when RFC1664 was + developed, and their results confirmed the advantages of the method. + Operational exeprience for over 2 years with RFC1664 specification + + + +Allocchio Standards Track [Page 21] + +RFC 2163 MIXER MCGAM January 1998 + + + confirmed the feasibility of the method, and helped identifying some + operational procedures to deploy the insertion of MCGAM into DNS. + + Software to query the DNS and then to convert between the textual + representation of DNS resource records and the address format defined + in MIXER was developed with RFC1664. This software also allows a + smooth implementation and deployment period, eventually taking care + of the transition phase. This software can be easily used (with + little or null modification) also for this updated specification, + supporting the new 'gate1' MIXER table. DNS software implementations + supporting RFC1664 also supports with no modification this memo new + specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 22] + +RFC 2163 MIXER MCGAM January 1998 + + + A further informational document describing operational and + implementation of the service is expected. + +8. Acknowledgements + + We wish to thanks all those who contributed to the discussion and + revision of this document: many of their ideas and suggestions + constitute essential parts of this work. In particular thanks to Jon + Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops, + TERENA wg-msg and IETF namedroppers groups. A special mention to + Christian Huitema for his fundamental contribution to this work. + + This document is a revision of RFC1664, edited by one of its authors + on behalf of the IETF MIXER working group. The current editor wishes + to thank here also the authors of RFC1664: + + Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it + CNUCE - CNR X.400: C=it;A=garr;P=cnr; + Reparto infr. reti O=cnuce;S=bonito; + Viale S. Maria 36 + I 56126 Pisa + Italy + + + Bruce Cole RFC822: bcole@cisco.com + Cisco Systems Inc. X.400: C=us;A= ;P=Internet; + P.O. Box 3075 DD.rfc-822=bcole(a)cisco.com; + 1525 O'Brien Drive + Menlo Park, CA 94026 + U.S.A. + + + Silvia Giordano RFC822: giordano@cscs.ch + Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs; + Calcolo Scientifico S=giordano; + Via Cantonale + CH 6928 Manno + Switzerland + + + Robert Hagens RFC822: hagens@ans.net + Advanced Network and Services X.400: C=us;A= ;P=Internet; + 1875 Campus Commons Drive DD.rfc-822=hagens(a)ans.net; + Reston, VA 22091 + U.S.A. + + + + + + +Allocchio Standards Track [Page 23] + +RFC 2163 MIXER MCGAM January 1998 + + +9. References + + [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling + Systems: System Model - Service Elements", October 1988. + + [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC + 822", RFC 1327, March 1992. + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, USC/Information Sciences Institute, November + 1987. + + [RFC 1035] Mockapetris, P., "Domain names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC + 1033, SRI International, November 1987. + + [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced + Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, + January 1998. + + [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and + Managing DNS Information in the X.500 Directory", Proceeding of + the 4th Joint European Networking Conference, Trondheim, NO, May + 1993. + +10. Security Considerations + + This document specifies a means by which DNS "PX" records can direct + the translation between X.400 and Internet mail addresses. + + This can indirectly affect the routing of mail across an gateway + between X.400 and Internet Mail. A succesful attack on this service + could cause incorrect translation of an originator address (thus + "forging" the originator address), or incorrect translation of a + recipient address (thus directing the mail to an unauthorized + recipient, or making it appear to an authorized recipient, that the + message was intended for recipients other than those chosen by the + originator) or could force the mail path via some particular gateway + or message transfer agent where mail security can be affected by + compromised software. + + + + + + + + +Allocchio Standards Track [Page 24] + +RFC 2163 MIXER MCGAM January 1998 + + + There are several means by which an attacker might be able to deliver + incorrect PX records to a client. These include: (a) compromise of a + DNS server, (b) generating a counterfeit response to a client's DNS + query, (c) returning incorrect "additional information" in response + to an unrelated query. + + Clients using PX records SHOULD ensure that routing and address + translations are based only on authoritative answers. Once DNS + Security mechanisms [RFC 2065] become more widely deployed, clients + SHOULD employ those mechanisms to verify the authenticity and + integrity of PX records. + +11. Author's Address + + Claudio Allocchio + Sincrotrone Trieste + SS 14 Km 163.5 Basovizza + I 34012 Trieste + Italy + + RFC822: Claudio.Allocchio@elettra.trieste.it + X.400: C=it;A=garr;P=Trieste;O=Elettra; + S=Allocchio;G=Claudio; + Phone: +39 40 3758523 + Fax: +39 40 3758565 + + + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 25] + +RFC 2163 MIXER MCGAM January 1998 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 26] + |