rfc2163.txt

bind 9.3结合mysql数据库


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.