revised draft, accordin to RELAY-MTA terminology.
ALLOCCHIO@elettra-ts.infn.it Wed, 24 March 1993 14:52 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18904; 24 Mar 93 9:52 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18900; 24 Mar 93 9:52 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa08106; 24 Mar 93 9:52 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Wed, 24 Mar 1993 08:50:19 +0000
Date: Wed, 24 Mar 1993 08:50:19 +0000
X400-Originator: cargille@cs.wisc.edu
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/; mhs-relay..314:24.02.93.14.50.19]
Priority: Non-Urgent
DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Wed, 24 Mar 1993 08:50:17 +0000;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: ALLOCCHIO@elettra-ts.infn.it
Message-ID: <"10345142303991/17329 INFN*"@MHS>
To: ietf-osi-x400ops@cs.wisc.edu
Subject: revised draft, accordin to RELAY-MTA terminology.
Network Working Group March 1993
Request for Comments: Internet-DRAFT v4.2
Using the Internet DNS to maintain X.400 MHS Routing Informations
Claudio Allocchio (Allocchio@elettra.trieste.it)
Antonio Blasco Bonito (bonito@cnuce.cnr.it)
Bruce Cole (bcole@cisco.com)
Silvia Giordano (giordano@cscs.ch)
Robert Hagens (hagens@ans.net)
GARR-Italy
Cisco Systems Inc.
Centro Svizzero Calcolo Scientifico
Advanced Network & Services
0. Status of this memo
This memo proposes a method of storing in the Internet Domain Name
System the routing information needed by X.400 MTAs within an X.400
MHS. Routing information can be managed in a distributed rather than
a centralized way. MTAs located on Internet hosts can retrieve the
routing information querying the DNS instead of having fixed tables
which need to be centrally updated and distributed. This document
specifies a prototype standard proposal. This memo is a joint effort
of X400 operation working group and RARE Mail and Messaging working
group.
Distribution of this memo is unlimited.
Another document by the same authors describes a method to store and
distribute the RFC1327 mapping information using the Internet DNS.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 1]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
1. Introduction
The routing informations are an essential element to implement an
efficient e-mail service within any community. In the Internet Domain
Name System the "A" and "MX" records are used to store and distribute
dynamically the routing information used by mailers to transport and
deliver e-mail messages. In X.400 MHS usually static tables contain
the routing data.
In the early X.400 times, the MHS configurations were quite simple:
a few well managed MTAs (often called "Well known Entry Point" or
"WEP") were taking care of the whole routing for one or more
communities; all the traffic was managed by static point-to-point
connections among the WEPs, and often there was only one network
transport available (usually X.25 or TCP with RFC1006). In this
situation static tables proved to be enough to run such initial
service.
The rapid growth of X.400 Message Handling Systems, however, made
very soon inadequate the use of a simple statically defined database:
in fact the X.400 addresses tree grows daily adding new branches and
many new MTAs show up either. More over a large number of X.400
implementations now support multiple transport stacks, allowing a
real and global connectivity.
Many efforts have been done in order to take in account this new
situation, and a document defining the X.400 MHS routing strategy has
been defined by Urs Eppenberger from SWITCH/COSINE MHS project team
[EPPEN V3]. In that document the approach to the routing problem is
again table driven, using the so called "DOMAIN" and "RELAY-MTA"
tables (section 4). Two additional tables, "COMMUNITY" and "PERSON",
complete the data about the X.400 MHS. That document, however, has
been carefully designed to allow easily the store of the information
it defines in distributed databases like DNS or X.500: our aim is to
define the use of DNS to store those routing information.
A first proposal to use the Internet DNS to store, to retrieve and to
maintain X.400 related information (the RFC1327 mapping tables) was
introduced by two of the authors (B. Cole and R. Hagens). However it
required modifications to the actual Internet DNS nameservers and,
due to the large variety of currently available implementations, this
was unfeasible within a reasonable time.
A different approach, using already defined, commonly available DNS
resource-record types to store the information is proposed now. In
addition, the use of a new domain name space is envisaged in order to
fully implement a distributed X.400 routing information tree: again
the MX resource-records will be used, jointly with some other ones
needed to store the more complex X.400 routing data.
The creation of the new domain name space also provides the chance to
use the DNS to distribute dynamically the X.400 to/from RFC822
Allocchio et. al. (Doc. expiration date: August 1993) [Page 2]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
mapping information described in RFC1327, thus solving another
efficiency problems currently affecting the X.400 MHS
implementations.
In this paper we will adopt the DOMAIN and RELAY-MTA document
definitions from [EPPEN V3] routing coordination document.
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
The implementation of a fully meshed connectivity among MTAs, and the
ability to use at best the available network transport stacks require
to disseminate complete and up to date routing data to all MTAs. 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 routing tables by every
MTA wishing to use full connectivity.
- Modifications to the DNS based routing information can be made
available in a more timely manner than with a table driven
approach.
- Table management is not necessarily required for DNS-based X.400
MTAs.
- One can determine the routing in use by a remote MTA by querying
the DNS (remote debugging).
Routing decisions taken by the MTAs involved in delivering an X.400
message will also be more likely to result correct, if the routing
information is updated in real time.
3. Proposal: the new "X400.ARPA" domain space
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 et. al. (Doc. expiration date: August 1993) [Page 3]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
distributed database under a number of top-level domains (EDU, COM,
countries like UK, IT, FR, etc.). The special top-level/second-level
couple IN-ADDR.ARPA is used to store the IP address to domain name
relationship.
Our proposal, which closely resembles the above model, is to store
the X.400 routing data in a new branch of the DNS name space (under
the already defined top-level domain "ARPA") using the MX and HINFO
resource records. In particular in this new name space "X400.ARPA"
we will have a complete set of existing resource records available
to store any other useful information concerning X.400, like
RFC1327 mappings, responsible people, etc.
This name space is thus used to contain completely the information:
the data required by an MTA to route an X.400 message to destination
can be easily found with a simple query to the nearest nameserver.
Moreover there is no more any need to store, maintain and distribute
manually those tables.
The special name space begins at the top-level "X400.ARPA" and should
have a structure following the X.400 hierachical structure (country,
ADMD, PRMD, organisation, ...). The fully qualified MX and HINFO
resource-records are constructed starting from the information
contained in the DOMAIN and RELAY-MTA documents.
The construction of the new domain space tree will follow the same
procedures used when organising at first the already existing DNS
space: authoritative information about the X400.ARPA top-level domain
is maintained by the root servers while a central nameserver in each
country is delegated by the root servers to hold the national part of
the routing tables. At first, however, 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.
4. Storing X.400 routing information
In the usual domain name space the MX records are used to store
information for SMTP mailers; their content is a list of possible
Mail eXchanger and a pure number stating the preferred order of these
mailers (priority). The creation of a new domain space under
X400.ARPA top level domain, enables now us to use the MX resource
records in it to store information about routing in the X.400 MHS,
using the same principles adopted by SMTP mailers. Some other DNS
resource records will then be used to store the additional data
present in the RELAY-MTA and DOMAIN documents described in sect.
5.3 and 5.4 of [EPPEN V3] document.
The syntax form of the usual MX record in DNS is:
<domain> <class> MX <prio> <dest-host-domain>
Allocchio et. al. (Doc. expiration date: August 1993) [Page 4]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
where <dest-host-domain> is then resolved via an "A" resource record
into an IP host address: in fact the only transport foreseen in DNS
for SMTP protocol is TCP/IP, and the socket number 25 is already
reserved. Also NJE, DDCMP and X.25 transports are used for SMTP
(BSMTP, DSMTP and XSMTP), but their connection data are not included
and distributed via DNS.
In the X.400 MHS routing document we can identify these elements:
<OR-matching><MHS-subtree> <RELAY-MTA-Priority> <UniqueRELAY-MTAkey>
which can be somehow equivalenced to the usual DNS elements. However
the routing can be done on different protocol stacks, and each stack
can have a different priority. Thus we have additional data for each
specific stack like <Service-type>, <P-address>, <Service-priority>,
<MTS>.
On the other hand, the MTA connection data are much more complex
than a simple 4-byte IP address. We have in fact <RTS>, <password>,
<called-connection>, <calling connection>, etc. and many of these
elements are themselves a set of complex data. Thus we will need
additional resource records to store these data.
4.1 Detailed storage proposal for routing information in DNS
To implement in the most convenient way the storage of X.400 MHS
routing data we can take advantage of the DNS MX records; in fact
they already provide wildcard support and a priority mechanism.
Other available DNS resource record types will be then used for the
remaining RELAY-MTA data; in particular the HINFO resource record
can be used for the RELAY-MTA connection and system data.
Let us define the <MHS-route-record> object which can be inserted
into a DNS MX resource record:
<MHS-route-record> ::= <MHS-ORdomain> "IN" "MX" <RELAY-MTA-priority> \
<RELAY-MTA-data>
where:
<MHS-ORdomain> ::= DNS translation of <OR-matching><MHS-subtree>
(sect. 4.3.1)
<RELAY-MTA-priority> ::= <Number 0..99> (see [EPPEN V3] sect. 5.4)
<RELAY-MTA-data> ::= {<DNS-Service-key> ["-" <DNS-Priority>] "."} \
<DNS-RELAY-MTAkey>
<DNS-Service-key> ::= A unique keyword to identify a
<RELAY-MTA-call-data> and
<RELAY-MTA-clng-data> record (sect. 4.3.5)
Allocchio et. al. (Doc. expiration date: August 1993) [Page 5]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
<DNS-Priority> ::= DNS translation of <Service-priority>
(sect. 4.3.4)
<DNS-RELAY-MTAkey> ::= DNS translation of
<UniqueRELAY-MTAkey><local-domain> (sect. 4.3.2)
The presence of <OR-matching> element in the DOMAIN document
determines the distinction between wildcard and exact matching of an
O/R address with <MHS-subtree>: in DNS this will be implemented with
the provided MX wildcard mechanism (see an example in section 4.3.1).
The <DNS-RELAY-MTAkey>, as you can see, is the translation of the
combination of <UniqueRELAY-MTAkey> and <local-domain>; this requires
the mandatory presence of the <local-domain> information, even if
this information is defined as optional in [EPPEN V3]. The
<DNS-RELAY-MTAkey> must in fact be located in the correct branch of
the X400.ARPA DNS tree, i.e. exactly where the authority managing the
RELAY-MTA lies. A similar situation occurs also for the location of
the MTA object within the X.500 tree. As a consequence, for a
community wishing to distribute its routing information via DNS, the
<local-domain> element becomes mandatory.
The additional data for a RELAY-MTA connection are stored into HINFO DNS
resource records. In particular we need to store information about
the RELAY-MTA itself (<status>, <password>, <RTS>, <system>) and
about the network connectivity (<service-type>, <MTS> and
<P-address>). We define thus three records, which will be stored into
three different DNS HINFO records:
<RELAY-MTA-host-data> ::= <DNS-RELAY-MTAkey> "IN" "HINFO" \
"<status> <password> <DNS-RTS> [<system>]" \
"<DNS-Service-key> { [ "." <DNS-Service-key> ] }"
<RELAY-MTA-call-data> ::= "C."<DNS-Service-key>"."<DNS-RELAY-MTAkey>\
"IN" "HINFO" "<password> <DNS-RTS> <MTS>" \
"<P-address>"
<RELAY-MTA-clng-data> ::= "R."<DNS-Service-key>"."<DNS-RELAY-MTAkey>\
"IN" "HINFO" "<password> <DNS-RTS>" \
"<P-address>"
where:
<DNS-RTS> ::= DNS translation of <RTS> (sect. 4.3.3)
and <status>, <password>, <system>, <MTS>, <P-address> are defined in
[EPPEN V3], sect. 5.1 and 5.3.
Note that the <DNS-Service-key> list contained into the
<RELAY-MTA-host-data> record must contain exactly the same elements
used for any couple of <RELAY-MTA-call-data> and
<RELAY-MTA-clng-data> records, i.e. is we have 3 couples of
connection information records using "XX0", "RX0" and "IT6" keys,
then this list must be present in the <RELAY-MTA-host-data> record.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 6]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
The HINFO resource record can hold up to twice 256 octet strings,
allowing thus enough available space even for complex <P-address>
data.
We can understand better the reason of the three HINFO resource
records defined previously if we think of the multiple stacks
available for an X.400 MHS: an MTA has some data which are
independent from the network stack being used (stored into
<RELAY-MTA-host-data>) and on the contrary some other information
depending upon it (stored into <RELAY-MTA-call-data> and
<RELAY-MTA-clng-data>).
4.2 Basic mappings
The formal definition of an MX resource record is (RFC1035, sect.
3.3.9):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE A 16 bit integer which specifies the preference given
to this RR among others at the same "owner name".
EXCHANGE A <domain-name> which specifies a host willing to act
as a mail exchange for the "owner name".
and also the "owner name" is a <domain-name> element.
At the same time the formal definition of an HINFO resource record
is (RFC1035, sect. 3.3.2)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CPU and OS area both of <character-string> type and the "owner name"
is a <domain-name> element.
In our proposal, <MHS-ORdomain>, <RELAY-MTA-data>,
<RELAY-MTA-host-data>, <RELAY-MTA-call-data> and
<RELAY-MTA-clng-data> must thus be conformant with
Allocchio et. al. (Doc. expiration date: August 1993) [Page 7]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
the <domain-name> syntax rules, i.e.
<domain-name> ::= <subdomain> | " "
<subdomain> ::= <label> | <label>.<subdomain>
<label> ::= <alphanum> {<alphanumhyphen>} <alphanum>
<alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
<alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
The definition of <character-string> is simpler: a contiguous set
of characters without interior spaces, or a 'quoted string', i.e.
beginning and ending with " (double quotes). Inside a quoted
string any character can occur, except for a " itself, which must
be quoted using \ (backslash).
As you will notice, the legal character set for <label> does not
correspond to the IA5 Printablestring one which is used in
<MHS-subtree>; even worse for <uniqueRELAY-MTAkey> which can use any
ASCII character from (032) up to (126) decimal. However a very
simple "escape mechanism" can be applied in order to bypass the
problem.
4.3 IA5 Printablestring and ASCII to <alphanumhyphen> mappings
The problem of unmatching character set definition is solved by a
simple character mapping rule: whenever a character does not belong
to <alphanumhyphen>, then it is mapped using its 3 digit decimal
ASCII code, enclosed in hyphens. A small set of special rules is
also defined for the most frequent cases. Moreover some frequent
characters combinations are also mapped as special cases.
In <MHS-subtree> and <uniqueREALYkey> we can identify a common
structure: a sequence of <addr-element>
<addr-element> ::= <attr-label> "=" <attr-value>
<attr-label> ::= "C" | "A" | "P" | "O" | \
"OU1" | "OU2" | "OU3" | "OU4" | \
"MTAname"
<attr-value> ::= IA5-Printablestring | ASCII(032)..ASCII(127)
The label values differ from those defined in RFC1327 for the mapping
rules. However both the mapping and routing rules share the same
X400.ARPA name space, and thus the sub-trees must have consistent and
coherent definitions. For this reason in the following table we also
define the appropriate equivalencies.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 8]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
Let's then define the following simple rules:
Original syntax DNS translation conditions
--------------------------------------------------------------------
missing <attr-label> <attr-label> missing seq. element
<attr-label>"="<blank> <attr-label>"b" blank attribute
"C=" "C-" country code
"A=" "ADMD-" administration domain
"P=" "PRMD-" private domain
"O=" "O-" organization
"OU1=" "OU2=" "OU3=" "OU4=" "OU-" organization unit
"MTAname=" "MTA-" MTA name
Non <alphanumhyphen> characters in <attr-value>:
Original character DNS translation conditions
--------------------------------------------------------------------
- -h- hyphen
. -d- quoted dot
<blank> -b- blank
non A/N character -<3digit-decimal>- elsewhere
If the DNS store translation of <attr-value> happens to end with an
hyphen, then this last hyphen is omitted.
Let's now have some examples:
Original syntax DNS store translation condition
------------------------------------------------------------------
missing PRMD PRMD missing attribute
A=<blank> ADMDb blank attribute
A=400-net ADMD-400-h-net hyphen mapping
P=UB.AC PRMD-UB-d-AC quoted dot mapping
O=ACME Inc. O-ACME-b-Inc-d blank & final hyphen
P=main-400-a PRMD-main-h-400-h-a hyphen mapping
O=-123-b O--h-123-h-b hyphen mapping
OU1=123-x OU-123-h-x hyphen mapping
More complete examples are shown in sect 4.3.1 and 4.3.2
In order to achieve the proper DNS store translations of the X.400
routing data some software tools will be used. It is in fact evident
that the above conversion rules are not user friendly enough to think
of a human made conversion.
In the next paragraphs we will show for each translation a "step by
step" procedure which can be interpreted as a small flow chart to
help in designing the tools. The fundamental rule to be applied
during translation is, however, the following:
"A string must be parsed from left to right, moving appropriately the
pointer in order not to consider again the already translated left
section of the string in subsequent analysis."
Allocchio et. al. (Doc. expiration date: August 1993) [Page 9]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
4.3.1 DNS translation of <OR-matching><MHS-subtree>
The syntax for <MHS-ORdomain> corresponds in DNS to a <domain-name>
element, while the <OR-matching> can fit into the wildcard
specification preceding the <domain-name>. Thus we will follow the
approach described in the previous section for non <alphanumhypehn>
elements, and a similar solution for the general translation.
The definition of <MHS-subtree> in [EPPEN V3] sect. 5.1 is:
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
[[[["OU1="'OrganizationalUnit-name'"; "]\
"OU2=" 'OrganizationalUnit-name' "; "] \
"OU3=" 'OrganizationalUnit-name' "; "] \
"OU4=" 'OrganizationalUnit-name' "; "] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" 'Two Character Country Code ISO-3166' ";"
i.e. a string made up by Attribute Labels ("C", "A", "P", "O", "OU1",
"OU2", "OU3", "OU4") plus Attribute-Values and ";" as separators.
This definition allows in its syntax to skip eventually missing
intermediate address elements, instead of substituting them with a
standard placeholder ("@") as defined in RFC1327 for mapping rules
syntax. The new DNS tree under top level domain "X400.ARPA", however,
must be coherent in order to allow a correct distribution of
authority and a correct sequence of queries along its branches. Thus
we will insert again the skipped attributes into our DNS translation
of <MHS-subtree> and <UniqueRELAY-MTAkey>.
An equivalent definition of <MHS-subtree> is:
<MHS-subtree> ::= <addr-element> [ { ";" <addr-element> } ]
<addr-element> ::= <attr-label> "=" <attr-value>
<attr-label> ::= "C" | "A" | "P" | "O" | \
"OU1" | "OU2" | "OU3" | "OU4"
<attr-value> ::= IA5-Printablestring
To obtain our <DNS-ORdomain> we will use the above translation tables
and use the rules described hereunder, along with a detailed example.
Let us suppose:
<MHS-subtree> = OU1=NYC; OU2=saled dpt.; P=AC-me; A= ; C=it;
<OR-matching> = "* "
1) insert the missing attribute elements in <MHS-subtree> and reorder
them as OU4, OU3, OU2, OU1, O, P, A, C:
OU2=saled dpt.; OU1=NYC; O; P=AC-me; A= ; C=it;
Allocchio et. al. (Doc. expiration date: August 1993) [Page 10]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
2) translate <attr-label> as defined above:
OU=saled dpt.; OU=NYC; O; PRMD=AC-me; ADMD= ; C=it;
3) translate <attr-value> as defined above and convert = into -:
OU-saled-b-dpt-d; OU-NYC; O; PRMD-AC-h-me; ADMDb; C-it;
4) replace ";" separators and eventual remaining blanks into ".":
OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.
5) add the top level domain "X400.ARPA" at the end:
OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.X400.ARPA.
6) if <OR-matching> is "* ", then add "*." in front of the string:
*.OU-saled-b-dpt-d.OU-NYC.O.PRMD-AC-h-me.ADMDb.C-it.X400.ARPA.
The final result is then used in DNS as selector to find the
appropriate X.400 routing RELAY-MTA on a best match basis, exactly
as for the RFC822 domains.
Let's have some other examples:
<MHS-subtree> = P=WHY;A=mycom;C=ch;
<OR-matching> = "* "
is translated in <DNS-ORdomain> as
*.PRMD-WHY.ADMD-mycom.C-ch.X400.ARPA.
Another one:
<MHS-subtree> = OU1=ACME Inc.;P=UB.AC;A= ;C=GB;
<OR-matching> = "= "
is translated in <DNS-ORdomain> as
OU-ACME-b-Inc-d.O.PRMD-UB-d-AC.ADMDb.C-GB.X400.ARPA.
4.3.2 DNS translation of <UniqueRELAY-MTAkey><local-domain>
The character set and syntax allowed for a <DNS-RELAY-MTAkey> is
again the one corresponding in DNS to a <domain-name> element. Thus
we will approach the problem as we did for <MHS-subtree>.
Before looking into the translation algorhytm, we must point out
again that the <DNS-RELAY-MTAkey> need to be placed into the correct
branch of the X400.ARPA tree. <UniqueRELAY-MTAkey> contains already
some keys which could help us in this definition; however they are
Allocchio et. al. (Doc. expiration date: August 1993) [Page 11]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
not detailed enough to assure the correct result. Thus we need to
make compulsory the presence of <local-domain> which locates fully
and unambiguously the RELAY-MTA in the DNS tree.
The <UniqueRELAY-MTAkey> and <local-domain> elements are defined in
sect. 5.1 and 5.3 of [EPPEN V3]:
<UniqueRELAY-MTAkey> ::= (["P="'PRMDname'"; "]["A="'ADMDname'"; "] \
"C=" 'Two Character Country Code ISO-3166' "; " \
"MTAname=" 'MTAname' | <DirectoryName> )
<local-domain> ::= "LocalDomain: " <MHS-subtree>
The <MHS-subtree> is local to the RELAY-MTA.
Note that <UniqueRELAY-MTAkey> can also be a <DirectoryName>; however
we need to specify completely the information in DNS, avoiding
queries to other directory services like X.500. We will thus use the
actual data in place of the <DirectoryName> distinguished object to
define our <DNS-RELAY-MTAkey>.
To define <DNS-RELAY-MTAkey> we will take "MTAname=" 'MTAname' from
<UniqueRELAY-MTAkey> joining it with <MHS-subtree> from
<local-domain>:
"MTAname=" 'MTAname' "; " <MHS-subtree>
Let us see in details the steps to obtain <DNS-RELAY-MTAkey>. We
suppose:
<UniqueRELAY-MTAkey> = P=ninf;A=rdnet;C=it;MTAname=int-gw.ninf.it
<MHS-subtree> = OU1=int-gw;P=ninf;A=rdnet;C=it;
1) add MTAname in front of <MHS-subtree>:
MTAname=int-gw.ninf.it; OU1=int-gw; P=ninf; A=rdnet; C=it;
2) insert the missing attribute elements in <MHS-subtree>:
MTAname=int-gw.ninf.it; OU1=int-gw; O; P=ninf; A=rdnet; C=it;
3) translate <attr-label> as defined above:
MTA=int-gw.ninf.it; OU=int-gw; O; PRMD=ninf; ADMD=rdnet; C=it;
4) translate <attr-value> as defined above and convert = into -:
MTA-int-h-gw-d-ninf-d-it; OU-cosine-h-gw; O; PRMD-ninf; \
ADMD-rdnet; C-it;
5) replace ";" separators and eventual remaining blanks into ".":
MTA-int-h-gw-d-ninf-d-it.OU-cosine-h-gw.O.PRMD-ninf.ADMD-rdnet.\
C-it.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 12]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
6) add the top level domain "X400.ARPA" at the end:
MTA-int-h-gw-d-ninf-d-it.OU-cosine-h-gw.O.PRMD-ninf.\
ADMD-rdnet.C-it.X400.ARPA.
This element is then ready to be used into DNS resource records.
Let us have another example:
<UniqueRELAY-MTAkey> = P=UB.AC;A= ;C=GB;MTAname=UB.AC.mhs-relay
<MHS-subtree> = P=UB.AC;A= ;C=GB;
is translated in <DNS-RELAY-MTAkey> as
MTA-ub-d-ac-d-mhs-h-relay.PRMD-UB-d-AC.ADMDb.C-GB.X400.ARPA.
4.3.3 DNS translation of <RTS>
The definition of <RTS> in [EPPEN V3], sect. 5.3 is
<RTS> ::= <dialogue-mode> [<checkpoint-size> <window-size>]
<dialogue-mode> ::= "RTS-dialog-mode: " ("TWA" | "MONOLOGUE")
<checkpoint-size> ::= "RTS-checkpoint-size: " 'checkpoint size'
<window-size> ::= "RTS-window-size: " 'window size'
These data will be stored in DNS into HINFO resource records, and
thus there is no limitation to the format or character set to use.
However the information stored in DNS are for machine use;
therefore we will define <DNS-RTS> as a short encoding of these data.
In particular:
<DNS-RTS> ::= <k-dialogue> [ <k-checkpoint> <k-window> ]
with:
<k-dialogue> ::= "T" | "M"
<k-checkpoint> ::= "C" 'checkpoint size'
<k-window> ::= "W" 'window size'
Some examples:
A connection with dialogue=TWA, checkpoint=19 and window=10 will
result into TC19W10;
A connection with dialogue=MONOLOGUE, checkpoint=5 and window=20
will result into MC5W20.
4.3.4 DNS translation of <Service-priority>
As <Service-priority> is a pure number, we need to apply a label to
it in order to be conformant with RFC1034 and also to distinguish it
Allocchio et. al. (Doc. expiration date: August 1993) [Page 13]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
from the other elements. Thus our definition of <DNS-priority> is
<DNS-priority> ::= "P" <Service-priority>
If <Service-priority> is defined as "5", then its DNS translation
will be "P5".
4.3.5 Defining the <DNS-Service-key>
The <DNS-Service-key> is just a label to identify a DNS resource
record where the relevant MTA connection data are stored. Thus its
only requirement is to be unique within an MTA identified by
<DNS-RELAY-MTAkey>. However it could be very useful to define some
criteria and common abbreviations in order to have short keys and
also some "guessable" keys for the most common cases. Our suggestion
is to adopt a three characters key:
<DNS-Service-key> ::= <k-name> <k-service> <k-protocol>
<k-name> ::= one A/N character identifying the network name,
adopting the following abbreviations:
'X' Public-X.25
'I' Internet
'R' EMPB-X25
'L' Int-CLNS
<k-service> ::= "X" | "O" | "L" | "T"
standing respectively for X.25, CONS, CLNS, TCP
<k-protocol> ::= "0" | "2" | "4" | "6"
standing respectively for TP0, TP2, TP4, RFC1006
Thus "Internet/TCP/RFC1006" will produce a <DNS-Service-key> = IT6,
while "EMPB-X25/CONS/TP0" produces <DNS-Service-key> = RO0.
4.4 An example of DNS stored DOMAIN and RELAY-MTA documents
As said in the previous sections, the X.400 MHS routing data can be
stored in DNS using MX and HINFO reseouce records and the set of
defined mapping rules. Let's see an example containing the routing
data of a management domain. In particular we will consider a DOMAIN
document with 2 RELAY-MTAs.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 14]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
DOMAIN document (part):
Community: MY-MHS
#
Domain: * P=INT-Co; A=RDnet; C=CH;
Domain: = P=WHY; A=RDnet; C=CH;
Domain: * P=Net Lab; A=Pub400; C=CH;
#
RELAY-MTA: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one; 10
RELAY-MTA: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch; 60
RELAY-MTA document 1 (part):
Community: MY-MHS
#
RELAY-MTA: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one
#
Status: primary
Password: none
RTS-dialog-mode: TWA
RTS-checkpoint-size: 10
RTS-window-size: 19
#
Called-address: Public-X.25/X.25/TP0;
Int-X25(80)=22225971014110; MTS-TP-84; 30
Calling-address: Public-X.25/X.25/TP0;
Int-X25(80)=22225971014
#
Called-address: Internet/TCP/RFC1006;
Internet-RFC-1006=140.105.1.1; MTS-TP-84; 10
Calling-address: Internet/TCP/RFC1006;
Internet-RFC-1006=140.105.1.1
#
System: HW=DEC VAX3100; OS=VMS 5.5; SW=EAN V2.2+
LocalDomain: O=LocDpt; P=INT-Co; A=RDnet; C=CH;
#
RELAY-MTA document 2 (part):
Community: MY-MHS
#
RELAY-MTA: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch
#
Status: secondary
Password: value="call-me"
RTS-dialog-mode: MONOLOGUE
#
Called-address: EMPB-X25/X.25/TP0;
Int-X25(80)=20432240004110; MTS-TP-84
Calling-address: EMPB-X25/X.25/TP0;
Int-X25(80)=20432240004
#
Allocchio et. al. (Doc. expiration date: August 1993) [Page 15]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
Called-address: Int-CLNS/CLNS/TP4;
"88"/NS+39756f11112222223333aa00040005e100; MTS-TP
Calling-address: Int-CLNS/CLNS/TP4;
"88"/NS+39756f11112222223333aa00040005e100
#
System: HW=Sun 3; OS=SunOS 5-2; SW=PP 6.0
LocalDomain: O=managment; P=Nat Sa; A=RDnet; C=CH;
#
The routing information contained in the above DOMAIN document will
result into 3 couples of MX record, 2 couples with a wildcard
specification and one couple with exact matching only.
;
; Domain: * P=INT-Co; A=RDnet; C=CH; ---------------------------
;
*.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN MX 10 \
XX0-P30.IT6-P10.\
MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
;
*.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN MX 60 \
RX0.LL4.\
MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.
;
; Domain: = P=WHY; A=RDnet; C=CH; ------------------------------
;
P-WHY.A-RDnet.C-CH.X400.ARPA. IN MX 10 \
XX0-P30.IT6-P10.\
MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
;
P-WHY.A-RDnet.C-CH.X400.ARPA. IN MX 60 \
RX0.LL4.\
MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.
;
; Domain: * P=Net Lab; A=Pub400; C=CH; --------------------------
;
*.P-Net-b-Lab.A-Pub400.C-CH.X400.ARPA. IN MX 10 \
XX0-P30.IT6-P10.\
MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
;
*.P-Net-b-Lab.A-Pub400.C-CH.X400.ARPA. IN MX 60 \
RX0.LL4.\
MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.
;
The above records just specify the available RELAY-MTAs and
connection stacks, but does not yet contain the needed data to
establish MTA to MTA links. These data are stored into the below
HINFO resource records.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 16]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
;
; RELAY-MTA: P=INT-Co; A=RDnet; C=CH; MTAname=mta.one ------------
;
MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. IN HINFO \
"primary none TC10W19 HW=DEC VAX3100; OS=VMS 5.5; SW=EAN V2.2+" \
"XX0.IT6"
;
C.XX0.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
IN HINFO "none TC10W19 MTS-TP-84" "Int-X25(80)=22225971014110"
R.XX0.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
IN HINFO "none TC10W19" "Int-X25(80)=22225971014"
;
C.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
IN HINFO "none TC10W19 MTS-TP-84" "Internet-RFC-1006=140.105.1.1"
R.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA. \
IN HINFO "none TC10W19" "Internet-RFC-1006=140.105.1.1"
;
; RELAY-MTA: P=Nat Sa; A=RDnet; C=CH; MTAname=bck-relay.ch --------
;
MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.X400.ARPA.\
IN HINFO \
"secondary value=\"call-me\" M HW=Sun 3; OS=SunOS 5-2; SW=PP 6.0" \
"RX0.LL4"
;
C.RX0.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
X400.ARPA. IN HINFO "value=\"call-me\" M MTS-TP-84" \
"Int-X25(80)=20432240004110"
R.RX0.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
X400.ARPA. IN HINFO "value=\"call-me\" M" "Int-X25(80)=20432240004"
;
C.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
X400.ARPA. IN HINFO "value=\"call-me\" M MTS-TP"
"\"88\"/NS+39756f11112222223333aa00040005e100"
R.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.A-RDnet.C-CH.\
X400.ARPA. IN HINFO "value=\"call-me\" M"
"\"88\"/NS+39756f11112222223333aa00040005e100"
Note that the above lines have been wrapped for clarity reasons,
using "\" to show continuation on the same line. Only inside the
HINFO value the "\" is used to quote the " character and is actual
part of the syntax.
4.5 An example of query to DNS for routing data
In this example we will assume that the routing data those defined
in section 4.4; let's see how it works.
OR address: C=ch;A=RDnet;P=Int-Co;O=mgt;S=helpdesk;
After translation of the routing part of the OR address in DNS
Allocchio et. al. (Doc. expiration date: August 1993) [Page 17]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
syntax, a first query for an MX records list will be issued for
O-mgt.PRMD-Int-h-Co.ADMD-RDnet.C-ch.X400.ARPA.
DNS will match the query with the first couple of MX records listed
in our above example, i.e.
IN MX 10 XX0-P30.IT6-P10.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.\
C-CH.X400.ARPA.
IN MX 60 RX0.LL4.MTA-bck-h-relay-d-ch.O-managment.P-Nat-b-Sa.\
A-RDnet.C-CH.X400.ARPA.
The answer contains already a choice between 2 possible RELAY-MTAs
and again 2 available connection stacks per each RELAY-MTA,
identified by XX0, IT6, RX0 and LL4 keywords and with different
priorities. Note that the <DNS-service-key> contained in each MX
record is meaningfuland must be unique only within a
<DNS-RELAY-MTAkey>.
As priority 10 indicated the preferred RELAY-MTA, and we already have
also the preferred connection stack (identified by IT6 key, service
priority 10) we can query directly for connection data, looking for
an HINFO record like:
C.IT6.MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
and attempt connection to the remote RELAY-MTA. If this fails,
according to [EPPEN V3] document, we will then query for the next
supported stack connection record (identified by XX0 key with
priority 30 and by the same <DNS-RELAY-MTAkey>). If also this
connection fails we will eventually use the other available
RELAY-MTA, and continue like that.
On the other hand we can also query information about a specific
RELAY-MTA starting from the <DNS-RELAY-MTAkey>:
MTA-mta-d-one.O-LocDpt.P-INT-h-Co.A-RDnet.C-CH.X400.ARPA.
It is thus possible to reconstruct the RELAY-MTA table data starting
from DNS.
5. Administration of routing information
Not all MTAs will be able to use the Internet DNS to obtain the
X.400 routing information. It is in fact expected that MTAs in a
particular country or management domain will conform to one of the
following models:
Table-based DNS-based X.500-based
Table-based countries and management domains will submit and receive
their routing documents from the International MHS coordinator. DNS
Allocchio et. al. (Doc. expiration date: August 1993) [Page 18]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
based countries and management domains will store their routing
information in the DNS. The DNS Routing coordinator will be
responsible for operating authoritative nameservers for resource
records pertinent to management domains in Table-based communities.
Also, the DNS Routing coordinator will be responsible for generating
the table form of routing data based in the DNS and transmitting it
to the International Routing Table coordinator. X.500 based storage
is not yet fully defined.
As of this writing, the International Routing Table coordinator is
the COSINE MHS Project Team and the DNS Routing coordinator is the
COSINE Gateway Service.
A set of coordination procedures to keep aligned the three routing
distribution services will be published in the implementation phase
document.
6. Conclusion
The use of the MX and HINFO resource-records and a new name space
tree promise to provide a good possible repository for X.400 MHS
routing information. The 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 introduction of the new "X400.ARPA" domain name
space allows us also to use the DNS to store and distribute many
other X.400 MHS information, including the mapping ones. The use of
the DNS has many advantages in storing, managing and updating
information. Using the existing resource records in the new name
tree does not even require the introduction of new types. A
successful number of tests have been performed under the provisional
top level domain "X400.IT", and their results confirmed the
advantages of the method.
Software to query the DNS and then to convert between the textual
representation of DNS resource records and the address format defined
in [EPPEN V3] needs to be developed. Also some tools to derive DNS
format from DOMAIN and RELAY-MTA documents will be needed to help
the implementation of this specification.
7. 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",
RFC 1034, USC/Information Sciences Institute, February
1987.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 19]
I-d v4.2 Internet DNS for X.400 MHS routing data March 1993
[RFC 1035] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, USC/Information Sciences
Institute, November 1987.
[EPPEN V3] Eppenberger, U., "Routing coordination for X.400 MHS
services within a multi protocol / multi network
environment - Table Format V3 for static routing",
Internet-Draft, COSINE-MHS/SWITCH, March 1993.
8. Authors addresses:
Claudio Allocchio RFC822: Claudio.Allocchio@elettra.trieste.it
Sincrotrone Trieste X.400: C=it;A=garr;P=infn;OU=elettra-ts;
c/o Area di Ricerca S=Allocchio;G=Claudio;
Padriciano 99 Phone: +39 40 3758523
I 34012 Trieste Fax: +39 40 226338
Italy
Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it
CNUCE - CNR X.400: C=it;A=garr;P=cnr;O=cnuce;S=bonito;
Reparto infr. reti Phone: +39 50 593246
Viale S. Maria 36 Fax: +39 50 589354
I 56126 Pisa
Italy
Bruce Cole RFC822: bcole@cisco.com
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 Phone: +1 415 6888245
Menlo Park, CA 94026 Fax: +1 415 6884575
U.S.A.
Silvia Giordano RFC822: giordano@cscs.ch
Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs;
Calcolo Scientifico S=giordano;
Via Cantonale Phone: +41 91 508213
CH 6928 Manno Fax: +41 91 506711
Switzerland
Robert Hagens RFC822: hagens@ans.net
Advanced Network X.400: C=us;A= ;P=Internet;
and Services DD.rfc-822=hagens(a)ans.net;
1875 Campus Commons Phone: +1 703 7587700
Drive
Reston, VA 22091
U.S.A.
Allocchio et. al. (Doc. expiration date: August 1993) [Page 20]