rfc2163.txt

bind 9.3结合mysql数据库

   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: [e-mail]
     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: [e-mail]
     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: [e-mail]
     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: [e-mail]
     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: [e-mail]
   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
   S=Allocchio;G=Claudio;
   Phone:  [phone]
   Fax:    [phone]


























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]