As per Relevance of the word distribute, we have this rfc below:
Network Working Group C.
Request for Comments: 1664 A.
Category: Experimental GARR-
B.
Cisco Systems Inc
S.
Centro Svizzero Calcolo
R. Advanced Network &
August 1994
Using the Internet DNS to
RFC1327 Mail Address Mapping
This memo defines how to store in the Internet Domain Name System
mapping information needed by e-mail gateways and other tools to
RFC822 domain names into X.400 O/R names and vice versa. information can be managed in a distributed rather than a
way. Gateways located on Internet hosts can retrieve the information querying the DNS instead of having fixed tables
need to be centrally updated and distributed. This memo is a
effort of X400 operation working group (x400ops) and RARE Mail Messaging working group (WG-MSG).
1.
The connectivity between the Internet SMTP mail and other services, including the Internet X.400 mail and the commercial X.400
service providers, is assured by the Mail eXchanger (MX) informationdistributed via the Internet Domain Name System (DNS).
number of documents then specify in details how to convert or addresses from/to RFC822 style to the other mail system syntax
However, only conversion methods provide, via some algorithm or a
of mapping rules, a smooth translation, resulting in
indistinguishable from the native ones in both RFC822 and
world
RFC1327 describes a set of mappings which will enable
between systems operating the CCITT X.400 (1984/88)
This approach requires many efforts to maintain the correct mapping
all the gateways need to get coherent tables to apply the mappings, the conversion tables must be distributed among all operationalgateways, and also every update needs to be distributed
This static mechanism requires quite a long time to be
modifying and distributing the information, putting heavy
on the time schedule of every update. In fact it does not
efficient compared to the Internet Domain Name Service (DNS).
over it does not look feasible to distribute the database to a
number of other useful applications, like local address converters
e-mail User Agents or any other tool requiring the mapping rules
produce correct results
A first proposal to use the Internet DNS to store, retrieve maintain those mappings was introduced by two of the authors (B.
and R. Hagens) adopting two new DNS resource record (RR) types: TO
X400 and TO-822. This new proposal adopts a more completestrategy
and requires one new RR only. The distribution of the RFC1327
rules via DNS is in fact an important service for the whole community: it completes the information given by MX resource
and it allows to produce clean addresses when messages are
among the Internet RFC822 world and the X.400 one (both Internet
Public X.400 service providers).
A first experiment in using the DNS without expanding the current
of RR and using available ones was in the mean time deployed by
of the authors. The existing PTR resource records were used to
the mapping rules, and a new DNS tree was created under the ".it"
level domain. The result of the experiment was positive, and a
test applications ran under this provisional set up. This test
also very useful in order to define a possible migration
during the deployment of the new DNS containing the new RR. Internet DNS nameservers wishing to provide this mapping
need in fact to be modified to support the new RR type, and in
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 information. The RFC822 to X.400 mapping rules (including the
RFC 1664 Internet DNS for Mail Mapping Tables August 1994
called 'gate' rules) will be stored in the ordinary DNS tree,
the definition of a new branch of the name space defined under national top level domain is envisaged in order to contain the X.400
to RFC822 mappings. A "two-way" mapping resolution schema is
fully implemented
The definitions, however, are detailed only until a certain level
and below it self-explaining character text strings will be used
2.
Implementations of RFC1327 gateways require that a database
address mapping information for X.400 and RFC822. This
must be disseminated to all RFC1327 gateways. In the community, the DNS has proven to be a practical mean for providing distributed name service. Advantages of using a DNS based system
a table based approach for mapping between O/R addresses and
names are
- It avoids fetching and storing of entire mapping tables by
host that wishes to implement RFC1327 gateways and/or
- Modifications to the DNS based mapping information can be available in a more timely manner than with a table approach
Also many other tools, like address converters and User Agents
take advantage of the real-time availability of RFC1327 tables
allowing a much easier maintenance of the information
3. The domain space for X.400 O/R name
Usual domain names (the ones normally used as the global part of
RFC822 e-mail address) and their associatedinformation, i.e.,
IP addresses, mail exchanger names, etc., are stored in the DNS as distributeddatabase under a number of top-level domains. Some top
level domains are used for traditional categories or
organisations (EDU, COM, NET, ORG, INT, MIL...). On the other
any country has its own two letter ISO country code as top-
domain (FR, DE, GB, IT, RU, ...), including "US" for USA.
special top-level/second-level couple IN-ADDR.ARPA is used to
the IP address to domain name relationship. Our proposal defines
the above structure the appropriate way to locate the X.400 O/R
space, thus enabling us to store in DNS the RFC1327 mapping data
The RFC1327 mapping information is composed by three tables: 'table1'
gives the translation from X.400 to RFC822 while 'table2' and 'gate
tables map RFC822 into X.400. Each mapping table is composed
mapping rules, and a single mapping rule is composed by a
(the argument of the mapping function derived from the address to
translated) and a translator (the mapping functionparameter):
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 environment, thus they should not be included in DNS. If 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 'gate' table entry is a valid RFC822
domain; thus the usual domain name space can be used without
to store these entries
RFC 1664 Internet DNS for Mail Mapping Tables August 1994
On the other hand, the keyword of a 'table1' entry belongs to
X.400 O/R name space. The X.400 O/R name space does not usually
into the usual domain name space, although there are a number
similarities; a new name structure is thus needed to represent it
This new name structurecontains 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
way which respects the existing name hierarchy
The X.400 two letter ISO country codes, however, are the same
for the RFC822 country top-level domains and this gives us appropriate hook to insert the new branches. Our proposal is,
fact, to create under each national top level ISO country code a
branch in the name space. This branch represents exactly the X.400
O/R name structure as defined in each single country, following
ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is
under each country top-level domain, and hence the national X.400
name space derives its own structure
The DNS name space thus contains completely the information
by an e-mail gateway or tool to perform the X.400-RFC822 mapping:
simple query to the nearest nameserverprovides it. Moreover there
no more any need to store, maintain and distribute manually
mapping table. The new X.400 name space can also contain information about the X.400 community, as DNS allows for it
4. The new DNS resource record for RFC1327 mapping rules:
The specification of the Internet DNS (RFC1035) provides a number specificresource records (RRs) to contain specific pieces information. In particular they contain the Mail eXchanger (MX)
and the host Address (A) records which are used by the Internet
mailers. As we will store the RFC822 to X.400 mapping information
the already existing DNS name tree, we need to define a new DNS RR
order to avoid any possible clash or misuse of already existing
structures. The same new RR will also be used to store the
from X.400 to RFC822. More over the mapping information, i.e.,
RFC1327 mapping rules, has a specific format and syntax which
an appropriate data structure and processing. A further advantage defining a new RR is the ability to include flexibility for
eventual future development
[] []
When we store in DNS a 'table1' entry, then will be an X.400
mail domain name in DNS syntax (see sect. 4.2). When we store
'table2' or a 'gate' table entry, will be an RFC822
domain name, including both fully qualified DNS domains and mail
domains (MX-only domains). All normal DNS conventions, like
values, wildcards, abbreviations and message compression, apply
for all the components of the PX RR. In particular, MAP822
MAPX400, as elements, must have the final "." (root
when they are fully qualified
covers any RFC822 domain ending with 'net2.it', unless more
rules for some subdomain in 'net2.it' are present. Thus there is
possibility to specify explicitly an RFC1327 entry as an exact
only rule. In DNS an entry
*.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it
specify the usual wildcard match as for RFC1327 tables. However
entry
ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it
RFC 1664 Internet DNS for Mail Mapping Tables August 1994
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
allow the (ASCII decimal 32) character within these fields
making unneeded the use of an explicit delimiter as required in
RFC1327 original syntax
Another extension to the RFC1327 specifications is the
value defined as part of the PX RDATA section. This numeric value
exactly the same meaning than the similar one used for the MX RR.
is thus possible to specify more than one single mapping for a
(both from RFC822 to X.400 and vice versa), giving as the
order. In RFC1327 static tables, however, you cannot specify
than one mapping per each RFC822 domain, and the same
apply for any X.400 domain mapping to an RFC822 one
More over, in the X.400 recommendations a note suggests than
ADMD= should be reserved for some special cases. nationalfunctional profile specifications for an X.400 MHS
that if an X.400 PRMD is reachable via any of its national ADMDs
independently of its actual single or multipleconnectivity
them, it should use ADMD= to advertise this fact. Again, if
PRMD has no connections to any ADMD it should use ADMD=0 to
its status, etc. However, in most of the current real situations,
ADMD service providers do not accept messages coming from
subscribers if they have a blank ADMD, forcing them to have their
ADMD value. In such a situation there are problems in
properly the actually working mappings for domains with connectivity. The PX RDATA 'PREFERENCE' extension was introduced
take in consideration these problems
The syntax definition of the RFC1327 mapping rules is defined appendix F of that document. However that syntax is not very oriented and contains a number of characters which have a
RFC 1664 Internet DNS for Mail Mapping Tables August 1994
meaning in other fields of the Internet DNS. Thus in order to
any possible problem, especially due to some old DNS
still being used in the Internet, we define a syntax for the X.400
part of any RFC1327 mapping rules (and hence for any X.400 O/R name
which makes it compatible with a element, i.e.,
