rfc2163.txt

bind 9.3结合mysql数据库

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.