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 element containing , the
RFC822 part of the MCGAM;
MAPX400 A element containing the value of
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:
[] []
When we store in DNS a 'table1' or a 'gate1' entry, then 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, will be an RFC822
mail domain name, including both fully qualified DNS domains and mail
only domains (MX-only domains). All normal DNS conventions, like
default values, wildcards, abbreviations and message compression,
apply also for all the components of the PX RR. In particular ,
MAP822 and MAPX400, as elements, must have the final
"." (root) when they are fully qualified.
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 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 (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= should be reserved for some special cases. Various
national functional profile specifications for an X.400 MHS states
that if an X.400 PRMD is reachable via any of its national ADMDs,
independently of its actual single or multiple connectivity with
them, it should use ADMD= to advertise this fact. Again, if a
PRMD has no connections to any ADMD it should use ADMD=0 to notify
its status, etc. However, in most of the current real situations, the
ADMD service providers do not accept messages coming from their
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 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 element, i.e.,
::= | " "
::=
RFC, FYI, BCP