Internet DRAFT - draft-ietf-x400ops-dnsx400
draft-ietf-x400ops-dnsx400
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 09:09:37 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:39:00 GMT
ETag: "3dde40-b73a-2b257864"
Accept-Ranges: bytes
Content-Length: 46906
Connection: close
Content-Type: text/plain
X400 Operations Working Group September 1992
Request for Comments: DRAFT v3.0
Using the Internet DNS to maintain RFC1327 Address Mapping Tables
and X.400 Routing Informations
Claudio Allocchio (Allocchio@elettra.trieste.it)
A. Blasco Bonito (blasco@cnuce.cnr.it)
Bruce Cole (cole@cs.wisc.edu)
Silvia Giordano (Giordano@cnuce.cnr.it)
Robert Hagens (hagens@cs.wisc.edu)
GARR-Italy & Wisconsin University CC-US
0. Status of this memo
This memo proposes a method of storing in the Internet Domain Name
System the information needed by RFC1327 e-mail gateways to map RFC822
domain names into X.400 OR-names and viceversa. Mapping information
can be managed in a distributed rather than a centralized way.
Gateways 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. A proposal about storing
also X.400 routing informations into the Internet DNS is presented,
too. This document specify an experimental standard proposal.
Distribution of this memo is unlimited.
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.
0.1 Document Expiration Date
This document was submitted on September 23rd, 1992 and its validity
will expire on March 23rd 1993.
1. Introduction
RFC1327 describes a set of mappings between the X.400 (1984/88) series
of protocols and 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 RFC1327: the mechanism
for mapping between X.400 O/R addresses and RFC822 domain names. As
described in Appendix F of RFC1327, implementation of the mappings
requires a database which maps between X.400 O/R addresses and domain
names, and this database is statically defined.
This approach requires many efforts to maintain the correct mapping:
all the gateways need to get coherent tables to apply the same
mappings, the conversion tables must be distributed among all the
operational gateways, and also every update needs to be distributed.
This static mechanism requires quite a long time to be spent in
modifying and distributing these informations, putting heavy
constraints on the time schedule of every update. In fact it does not
appear efficient compared to the Internet distributed name service.
A first proposal to use the Internet DNS to store, retrieve and
maintain those mappings was introduced by two of the authors (B. Cole
and R. Hagens) adopting two new DNS resource record types: TO-X400
and TO-822. However there was a critical point: the Internet DNS
nameservers wishing to provide this mapping information needed to be
modified to support those new resource record types and a new address
class. In the real Internet, those modifications cold not really be
accomplished on a significant number of operational DNS servers within
a reasonable time period. This new proposal tries to bypass the above
problem.
The basic idea is to use an already defined, commonly available DNS
resource- records type to store the mapping information. In addition,
the use of a new domain name space is envisaged in order to fully
implement a "two-way" mapping resolution scheme.
The creation of the new domain name space also gives the chance to use
the DNS to distrubute dynamically the X.400 routing informations,
solving thus another efficiency problem currently affecting the X.400
MHS implementations.
In this paper we will adopt the RFC1327 mapping rules syntax, showing
how it can be stored into the Internet DNS, and the DOMAIN and WEP
document definitions from Urs Eppenberger's 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 serveral 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 RFC1327 gateways require that a database store
address mapping information for X.400 and RFC822. This information
must be disseminated to all RFC1327 gateways. In the internet
community, the DNS has proven to be a practical means for providing a
distributed nameservice. 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 RFC1327.
- Modifications to the DNS based mapping 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
RFC1327 gateways.
- One can determine the mappings in use by a remote gateway by
querying the DNS (remote debugging).
Also the distribution via DNS of the current statically defined X.400
MHS routing information will take the same advantages listed above.
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
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
RFC1327 mapping informations in a new branch of the DNS name space
(under the already defined top-level domain "ARPA") using the PTR
resource-record. 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 informations concerning X.400, like routing,
responsible people, etc.
This name space is thus used to contain completely the informations:
the data required by an e-mail gateway to perform the X.400-RFC822
mapping can be easily found with a simple query to the nearest
nameserver, thus avoiding a long search in complex, statically
defined, mapping tables. 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, organization, ...). The fully-qualified PTR value is
constructed starting from the original RFC1327 mapping rule, and
chaining the string ".X400.ARPA" at the end.
The construction of the new domain space tree will follow the same
procedures used when organizing 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 mapping tables. At first, however, the informations will be
stored in a quite centralized way, and distribution of authority will
be gradually achieved. A seprate document will describe the
implementation phase.
4. Detailed storage proposal for RFC1327 mapping rules.
Among the resource-record types that can be associated to a domain
name in the DNS, the PTR is generically defined as a pointer to
another part of the domain name space. The only use of the PTR record
being well known is in the IN-ADDR.ARPA domain space: in that context
it provides the IP address to domain name resolution (or "inverse name
resolution"). PTR in the new "X400.ARPA" name space will instead be
used for storing RFC1327 mapping informations.
The PTR format, as defined in the RFC 1034, section 3.3 is as follows:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PTRDNAME |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME A <domain-name> which points to some location
in the domain name space.
These resource records are used in special domains to point to some
other location in the domain space. These records are simple data,
and do not imply any special processing.
The PTR value, as defined in the RFC 1034, must be a domain name, i.e.
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <label>.<subdomain>
<label> ::= <alphanum> {<alphanumhyphen>} <alphanum>
<alphanum> ::= "0".."9" | "A".."Z" | "a".."z"
<alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
As you will notice, the legal character set for <label> does not
correspond to the IA5 Printablestring one. However a very simple
"escape mechanism" can be applied in order to bypass the problem. We
can simply describe the mapping rule format as:
<map-rule> ::= <map-element> | <map-element> { "." <map-element> }
<map-element> ::= <attr-label> "$" <attr-value>
<attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
<attr-value> ::= " " | "@" | IA5-Printablestring
In our model we define the following logical equivalences:
<domain> == <map-rule> + "X400.ARPA"
<label> == <map-element>
i.e. we will use insert the <map-rule> information where usually the
<domain> one is, and the <map-element> will replace the <label>
element.
4.1 IA5-Printablestring to <alphanumhyphen> mappings
The problem of unmatching IA5-Printablestring and <label> character
set definition is solved by a simple character mapping rule: whenever
an IA5 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 used in RFC1327
rules are also mapped as special cases.
Let's then define the following simple rules:
RFC1327 rule DNS store translation conditions
-------------------------------------------------------------------
<attr-label>$@ <attr-label> missing attribute
<attr-label>$ <attr-label>"b" blank attribute
<attr-label>$xxx <attr-label>-xxx elsewhere
Non <alphanumhyphen> characters in <attr-value>:
RFC1327 rule DNS store 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:
RFC1327 rule DNS store translation condition
------------------------------------------------------------------
PRMD$@ PRMD missing attribute
ADMD$ ADMDb blank attribute
ADMD$400-net ADMD-400-h-net hyphen mapping
PRMD$UK\.AC PRMD-UK-d-AC quoted dot mapping
O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen
PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping
O$-123-b O--h-123-h-b hyphen mapping
OU$123-x OU-123-h-x hyphen mapping
Thus, a complete RFC1327 mapping rule like
OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
translates to
OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
another example:
OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
translates to
OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
4.1.1 Flow chart
In order to achieve the proper DNS store translations of the RFC1327
mapping rules some software tools will be used. It is in fact evident
that the above rules for converting mapping table from RFC1327 to DNS
format (and viceversa) are not user friendly enough to think of a
human made conversion.
To help in designing such tools, a small flow chart will be described.
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 tranlsated left
section of the string in subsequent analysis."
Flow chart 1 - Translation from rfc1327 to DNS format:
parse single attribute
(enclosed in . separators)
|
(yes) <label>$@ ? (no)
| |
map to <label> (no) <label>$ ? (yes)
| | |
next elem. map to <label>- map to <label>"b"
| |
map "\." to -d- next elem.
|
map "-" to -h-
|
map non A/N char
|
remove (if any) last "-"
|
next elem.
Flow chart 2 - Translation from DNS to rfc1327 format:
parse single attribute
(enclosed in . separators)
|
(yes) <label> ? (no)
| |
map to <label>$@ (no) <label>"b" ? (yes)
| | |
next elem. map to <label>- map to <label>$
| |
map -d- to "\." next elem.
|
map -h- to "-"
|
map -<3digit> to non A/N char
|
next elem.
Using RFC1327's assumption of an asymmetric mapping between X.400 and
RFC822 addresses, two separate relations are required to store the
mapping database: RFC1327 Table 1 and RFC1327 Table 2; thus also in
DNS we will mantain the two different sections, even if they will both
belong to the PTR section. More over RFC1327 also specify a third
table: RFC1327 Gate Table. This additional table, however, has the
same syntax rules than RFC1327 Table 2 and thus the same tranlsation
procedure as Table 2 will be applied; some details about the RFC1327
Gate table are discussed in section 4.2.
A file containing the RFC1327 mappig rules and RFC1327 Gate table
written in DNS format will look like the following example:
!
! RFC1327 table 1: X.400 --> RFC822
!
ADMD-garr.C-it.X400.ARPA. IN PTR it.X400.ARPA.
PRMD-switch.ADMD-arcom.C-ch.X400.ARPA. IN PTR switch.ch.X400.ARPA.
O-uw-h-madison.PRMD-xnren.ADMDb.C-us.X400.ARPA. IN PTR cs.wisc.edu.X400.ARPA.
!
! RFC1327 table 2: RFC822 --> X.400
!
cnr.it.X400.ARPA. IN PTR PRMD-CNR.ADMD-garr.C-it.X400.ARPA.
infn.it.X400.ARPA. IN PTR O.PRMD-infn.ADMD-garr.C-it.X400.ARPA.
ac.uk.X400.ARPA. IN PTR PRMD-uk-d-ac.ADMDb.C-gb.X400.ARPA.
!
! RFC1327 Gate Table
!
my.G.X400.ARPA. IN PTR OU-cosine-h-gw.O.PRMD-infn.ADMD-garr.C-it.X400.ARPA.
edu.G.X400.ARPA. IN PTR O-mhs-h-relay.PRMD-xnren.ADMDb.C-us.X400.ARPA.
which corresponds to the following RFC1327 table:
#
# RFC1327 table 1: X.400 --> RFC822
#
ADMD$garr.C$it#it#
PRMD$switch.ADMD$arcom.C$ch#switch.ch#
O$uw-madison.PRMD$xnren.ADMD$ .C$us#cs.wisc.edu#
#
# RFC1327 table 2: RFC822 --> X.400
#
cnr.it#PRMD$CNR.ADMD$garr.C$it#
infn.it#O.PRMD$infn.ADMD$garr.C$it#
ac.uk#PRMD$uk\.ac.ADMD$ .C$gb#
#
# RFC1327 Gate table
#
my#OU$cosine-gw.O$@.PRMD-infn.ADMD$garr.C$it#
edu#O$mhs-relay.PRMD$xnren.ADMD$ .C$us#
4.2 Storing the RFC1327 Gate table
The RFC1327 Gate table syntax is identical to RFC1327 Table 2. Thus
the same syntax translation rules from RFC1327 to DNS format can be
applied. However, as the three RFC1327 tables are stored into the
same DNS PTR section, we must distinguish between Table 2 and Gate
Table informations. This is easily obtained adding and additional "G"
third level pseudo-domain (i.e. "G.X400.ARPA" as a whole) to the
RFC822 domain part of the table. The example in section 4.1.1 shows
clearly the result. As "G" is an illegal RFC822 top level domain
there are no comflicts or ambiguities in using it as a special
identifier. To be more explicit, the left hand side (RFC822 domain)
of a Table 2 rule adds ".X400.ARPA", wheareas the left hand side of a
Gate table entry adds ".G.X400.ARPA". The right hand side (O/R domain
address) adds ".X400.ARPA" in both cases.
5. Finding RFC1327 mapping information from DNS
The RFC1327 mapping information is stored in PTR resource records
located in nodes of the the DNS tree. The resource record associated
with a particular node is identified by the concatenation of labels
encountered while traversing the tree to that node. As defined above,
a PTR record is identified by elements derived from an X.400 O/R
address (Table 1) or by an RFC-822 domain name (Table 2 and Gate
table).
Moreover, placing our PTR mapping records under the same new X400.ARPA
root will provide a good facility for management of the mappings,
distribution of the zones of the DNS, and minimize zone transfer
resource consumption.
The mapping information stored in PTR resource records does not
represent a full O/R address. It is a template which specifies the
fields of the O/R address 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 (RFC1327: section 4.3.4, State I; section 4.3.5, mapping
B). A recursive set of queries to the DNS will be issued trying to
find a PTR record with the longest possible match. As specified in
RFC1327, a search of the mapping table will result in either success
(mapping found) or failure (all queries 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 RFC 1327. If a DNS error
code is returned, an error message should be logged and the gateway
operation is delayed as for timeout.
Searching the name-server which can authoritatively solve the query is
automatically performed by the DNS distributed name-service.
5.1 A DNS query example
An RFC1327 mail-gateway located in the Internet, when traslating
addresses from RFC822 to X.400, can get information about the RFC1327
mapping rule asking the DNS. As an example, when translating the
address SUN.CNUCE.CNR.IT, the gateway will append "X400.ARPA" and then
query DNS for the associated PTR record. The DNS should contain a PTR
record like this:
cnuce.cnr.it.X400.ARPA. IN PTR O-cnuce.PRMD-cnr.ADMD-garr.C-it.X400.ARPA.
The first query will fail. Then 'SUN' will be dropped and a new
query will be issued, returning the mapping rule is DNS store format.
Applying the syntax translation specified in paragraph 4.1 and
dropping "X400.ARPA" the RFC1327 mapping rule will be obtained.
Translating from X.400 to RFC822 the address
C=de; ADMD=dbp; PRMD=dfn; O=gmd;
the mail gateway should convert the syntax according to paragraph 4.1,
append "X400.ARPA" and then query DNS for the corresponding PTR
record. The DNS should contain:
ADMD-dbp.C-de.X400.ARPA. IN PTR dbp.de.X400.ARPA.
Assuming that there are not more specific PTR records in DNS, the
first two queries will fail; then the PTR record value is found,
"X400.ARPA" is dropped and the RFC1327 rule is available.
When looking for an entry in the RFC1327 Gate table, the gateway will
append "G.X400.ARPA" to the RFC822 domain and then query DNS for the
associated PTR record. If we are looking for the Gate table entry
representing top level domain "MY", then the DNS should contain a PTR
record like this:
my.G.X400.ARPA. IN PTR O-cnuce.PRMD-cnr.ADMD-garr.C-it.X400.ARPA.
DNS will return, possibly after some recursive iterations, the rule in
DNS store format. Applying the syntax translation specified in
paragraph 4.1 and dropping "X400.ARPA" the RFC1327 Gate table entry
rule will be obtained.
6. Administration of mapping information
Not all RFC1327 gateways will be able to use the Internet DNS to map
between O/R addresses and RFC822 domain names. It is expected that
gateways 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 mapping tables from the International Mapping Table coordinator.
DNS-based countries and management domains will store their mapping
information in the DNS. The DNS Mapping coordinator will be
responsible for operating authoritative nameservers for resource
records pertinent to management domains in Table- based communities.
Also, the DNS Mapping coordinator will be responsible for generating
the table form of mappings based in the DNS and transmitting it to the
International Mapping Table coordinator. X.500-based storage is not
yet fully defined.
As of this writing, the International Mapping Table coordinator is the
COSINE MHS Project Team and the DNS Mapping coordinator is the COSINE
Gateway Service.
A set of coordination procedures to keep aligned the three mapping
distribution services will be published in the implementation phase
document.
7. Storing and finding X.400 routing informations
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). As we created a new domain space under X400.ARPA
top level domain, we can now use the MX resource records in it to
store informations about routing in the X.400 MHS, using the same
principles adopted by SMTP mailers. A document defining the X.400 MHS
routing strategy has been defined by Urs Eppenberger from
SWITCH/COSINE MHS project team. In this document the approach to the
routing problem is again table driven, using the so called "DOMAIN"
and "WEP" documents (section 3). However the data defined in the
DOMAIN document closely resembles the MX approach, allowing an easy
use of DNS MX resource records for storing X.400 MHS routing data.
Some other DNS resource records will then be used to store the
additional data present in the WEP document.
The definition of the usual MX record in DNS is:
<domain> <class> MX <prio> <dest-host-domain>
where <dest-host-domain> is then resolved via an "A" resource record
into an IP host address: in fact the only transport forseen in DNS
for SMTP protocol is TCP/IP, and the socket number 25 is already
reserved. Also DDCMP and X.25 transports are used for SMTP (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:
<MHS-subtree> <Default-Priority> <UniqueMTAkey> <Delay>
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:
<Service-type> <P-address> <Priority>
On the other hand, the MTA connection data are much more complex than
a simple 4-byte IP address. For each connection stack we have in
fact:
<password> <called-connection> <calling connection>
and both <called-connection> and <calling-connection> is a set of
complex data. Thus we will need additional store to keep these data.
7.1 Detailed storage proposal for routing informations 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 (note
however that the X.400 MHS priority values must be interpreted in the
opposite direction than SMTP ones). Other available DNS resource
record types will be then used for the remaining WEP data; in
particular the HINFO resource record can be used for the WEP
connection and system data.
Let us define the <MHS-route-record> object which can be inserted into
a DNS MX reseource record:
<MHS-route-record> ::= <MHS-ORdomain> "IN" "MX" <Defualt-Priority> \
<WEP-data>
where:
<MHS-ORdomain> ::= DNS translation of <MHS-subtree> (sect. 7.1.1)
<WEP-data> ::= { <DNS-Service-key> "-" <DNS-Priority> "." } \
<DNS-Delay> "." <DNS-MTAkey>
<DNS-MTAkey> ::= DNS translation of <UniqueMTAkey> (sect. 7.1.2)
<DNS-Delay> ::= DNS translation of <Delay> (sect. 7.1.3)
<DNS-Priority> ::= DNS translation of <Priority> (sect. 7.1.4)
<DNS-Service-key> ::= A unique keywork to identify a <WEP-call-data>
and <WEP-clng-data> record (sect. 7.1.5)
The additional data for a WEP connection are stored into HINFO DNS
resource records. In particular we need to store informations about
the WEP itself (password, system, supported stacks) and about the
network connectivity (service type, MTS, P- address). We define thus
three records, which will be stored into three different DNS HINFO
records:
<WEP-host_data> ::= <DNS-MTAkey> "IN" "HINFO" "<password> <system>" \
"<DNS-Service-key> { [ "." <DNS-Service-key> ] }"
<WEP-call-data> ::= "C." <DNS-Serivce-key> "." <DNS-MTAkey> \
"IN" "HINFO" "<Service-type> <MTS>" "<P-address>"
<WEP-clng-data> ::= "R." <DNS-Serivce-key> "." <DNS-MTAkey> \
"IN" "HINFO" "<Service-type>" "<P-address>"
Note that the <DNS-Service-key> list contained into the
<WEP-host-data> record must contain exactly the same elements used for
any couple of <WEP-call-data> and <WEP-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 <WEP-host-data>
record.
The HINFO resource record can hold up to twice 256 octet strings,
allowing thus enough available space even for complex <P-address>
data.
The concept of routing records in the DOMAIN document has an implicit
wildcard specification: anything ending up with the stated
<MHS-subtree> is to be routed as indicated, unless a more specific
routing record is found. In DNS MX records this must be specified
using explicitly wildcards, as it allows to specify fully qualified
domains, too. This feature could eventually be used to obtained more
detailed X.400 MHS routing rules with DNS (see an example in section
7.2).
7.1.1 DNS translation of <MHS-subtree>
The allowed character set for an <MHS-ORdomain> is the same described
in section 4, as its definition corresponds in DNS to a <domain>
element. Thus we will follow the same approach described in section
4.1 for non {alphanumhypehn} elements, and a similar solution for the
general tranlsation.
The definition of <MHS-subtree> in the DOMAIN document is:
<MHS-subtree> ::= "Domain: " \
"C=" 'Two Character Contry Code ISO-3166' \
";ADMD=" 'ADMDname' \
[ ";PRMD=" 'PRMDname' ] \
[ ";O=" 'Organization-name' ] \
[ { ";OU=" 'Org-unit-name' } ]
i.e. a label ("Domain:") followed by a string made up by Attribute
Labels ("C", "ADMD", "PRMD", "O", "OU") 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 translaion of
<MHS-subtree> and <UniqueMTAkey>, using the same placeholder ("@")
defined in RFC1327.
An equivalent definition of <MHS-subtree> is:
<MHS-subtree> ::= "Domain: " <addr-element> [ { ";" <addr-element> } ]
<addr-element> ::= <attr-label> "=" <attr-value>
<attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
<attr-value> ::= IA5-Printablestring
To obtain our <DNS-ORdomain> we will follow these rules:
- drop the "Domain: " label;
- revert the order of <addr-element>;
- insert eventually missing intermediate attributes as
<attr-label> "=" "@";
- "quote" all dots (".") in <attr-value>;
- build <DNS-ORdomain> as:
<DNS-ORdomain> ::= <d-addr-elem> [ { "." <d-addr-elem> } ] ".X400.ARPA"
<d-addr-elem> ::= <attr-label> "-" <mapped-attribute-value>
Substituing the "$" sign with the "=" sign and the "." separator with
the ";" one, the same rules specified in sections 4.1 and 4.1.1 can be
thus used to translate <attr- value> into <mapped-attribute-value>.
Let's have some examples:
Domain: C=CH;ADMD=ARCOM;PRMD=WHO;
is translated in <DNS-ORdomain> as
PRMD-WHO.ADMD-arcom.C-ch.X400.ARPA
Another one:
Domain: C=GB;ADMD= ;PRMD=UK.AC;OU=ACME Inc.;
is translated in <DNS-ORdomain> as
OU-ACME-b-Inc-d.O.PRMD-UK-d-AC.ADMDb.C-GB.X400.ARPA
7.1.2 DNS translation of <UniqueMTAkey>
The character set and syntax allowed for a <DNS-MTAkey> is again the
one corresponding in DNS to a <domain> element. Thus sections 4 and
4.1 already give us the correct solution.
More over <UniqueMTAkey> syntax is very close to the <MHS-subtree>
one:
<UniqueMTAkey> ::= "C=" 'Two Character Contry Code ISO-3166' \
";ADMD=" 'ADMDname' \
[ ";PRMD=" 'PRMDname' ] \
[ ";O=" 'Organization-name' ] \
[ { ";OU=" 'Org-unit-name' } ] \
";MTAname=" 'MTAname'
i.e. an <MHS-subtree> definition, locating exactly the MTA within its
management domain, plus the MTA name itself. An equivalent definition
is again
<UniqueMTAkey> ::= <addr-element> [ { ";" <addr-element> } ]
<addr-element> ::= <attr-label> "=" <attr-value>
<attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU" | "MTAname"
<attr-value> ::= IA5-Printablestring
To obtain our <DNS-MTAkey> we will follow these rules:
- revert the order of <addr-element>;
- insert eventually missing intermediate attributes as
<attr-label> "=" "@";
- "quote" all dots (".") in <attr-value>;
- replace "MTAname=" with "MTA="
- build <DNS-MTAkey> as:
<DNS-MTAkey> ::= <d-addr-elem> [ { "." <d-addr-elem> } ] ".X400.ARPA"
<d-addr-elem> ::= <attr-label> "-" <mapped-attribute-value>
Substituing the "$" sign with the "=" sign and the "." separator with
the ";" one, the same rules specified in sections 4.1 and 4.1.1 can be
thus used to translate <attr- value> into <mapped-attribute-value>.
Let's have some examples:
C=it;ADMD=garr;PRMD=infn;OU=cosine-gw;MTAname=cosine-gw.infn.it
is translated in <DNS-MTAkey> as
MTA-cosine-h-gw-d-infn-d-it.OU=cosine-h-gw.O.PRMD-infn. \
ADMD-garr.c-it.X400.ARPA
Another one:
C=GB;ADMD= ;PRMD=UK.AC;MTAname=uk.ac.mhs-relay
is translated in <DNS-MTAkey> as
MTA-uk-d-ac-d-mhs-h-relay.PRMD-UK-d-AC.ADMDb.C-GB.X400.ARPA
7.1.3 DNS translation of <Delay>
As <Delay> is a pure number, we need to apply a label to it in order
to be conformant with RFC1034 and also to distinguish it from the
other elements. Thus our definition of <DNS-delay> is
<DNS-delay> ::= "D" <Delay>
If <Delay> is defined as "25", then its DNS translation will be "D25".
7.1.4 DNS translation of <Priority>
As <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 from
the other elements. Thus our definition of <DNS-priority> is
<DNS-priority> ::= "P" <Priority>
If <Priority> is defined as "5", then its DNS translation will be
"P5".
7.1.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-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' RARE-IXI
'L' RARE-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 "RARE-IXI/CONS/TP0" produces <DNS-Service-key> = RO0.
7.2 An example of DNS stored Domain and WEP 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.
;
; document it.garr
;
; Community: COSINE-MHS
; Update: DATE=920806
;
*.ADMD-GARR.C-it.X400.ARPA. IN MX 10 \
RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
IN MX 20 \
RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
;
*.PRMD-Y-h-net.ADMD-Master400.C-it.X400.ARPA. IN MX 10 \
RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
IN MX 20 \
RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
;
; WARNING the next record routes ONLY C=it;ADMD=Master400;PRMD=ssgrr;
; OR address, excluding any subdomain.
;
PRMD-ssgrr.ADMD-Master400.C-it.X400.ARPA. IN MX 10 \
RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
IN MX 20 \
RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
;
*.PRMD=isanet.ADMD-0.C-is.X400.ARPA. \
IN MX 10 D5.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
IN MX 20 D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
;
; Now infn.it WEP host data
;
MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"Password: not used; COM=VAX4000; OPS=VMS5.5; MHS=MRX2.2-000" \
"RX0.XX0"
;
; Now infn.it WEP connection data
;
C.RX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"RARE-IXI/X.25/TP0; MTS-TP-84" \
"INFN/TELEX+00728722+X25(80)+04+20432240000+CUDF+03010100"
;
R.RX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"RARE-IXI/X.25/TP0" \
"INFN/TELEX+00728722+X25(80)+04+20432240000"
;
C.XX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"Public-X.25/X.25/TP0; MTS-TP-84" \
"INFN/TELEX+00728722+X25(80)+01+22225110072+CUDF+03010100"
;
R.XX0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"Public-X.25/X.25/TP0" \
"INFN/TELEX+00728722+X25(80)+01+22225110072"
;
; Now cosine-gw.infn.it WEP host data
;
MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"Password: not used; COM=VAX9210; OPS=VMS5.5; MHS=MRX2.2-000" \
"RX0.XX0"
;
; Now cosine-gw.infn.it WEP connection data
;
C.RX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"RARE-IXI/X.25/TP0; MTS-TP-84" \
"INFN/TELEX+00728722+X25(80)+04+20432240009008+CUDF+03010100"
;
R.RX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"RARE-IXI/X.25/TP0" \
"INFN/TELEX+00728722+X25(80)+04+20432240009008"
;
C.XX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"Public-X.25/X.25/TP0; MTS-TP-84" \
"INFN/TELEX+00728722+X25(80)+01+22225110072082+CUDF+03010100"
;
R.XX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA. IN HINFO \
"Public-X.25/X.25/TP0" \
"INFN/TELEX+00728722+X25(80)+01+22225110072082"
Note that the above lines have been wrapped for clarity reasons, using
"\" to show continuation on the same line.
7.3 An example of query to DNS for routing data
In this example we will assume that the routing data those defined in
section 7.2; let's see how it works.
Case 1: OR address C=it;ADMD=garr;PRMD=infn;S=helpdesk;
After translation of the routing part of the OR address in DNS syntax,
a first query for an MX records list will be issued for
PRMD-infn.ADMD-garr.C-it.X400.ARPA; DNS will match the query with the
first couple of MX records listed in our above example, i.e.
IN MX 10 RX0-P9.XX0-P7.D0.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
IN MX 20 RX0-P9.XX0-P7.D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
The answer contains already a choice between 2 possible WEPs and again
2 available connection stacks per each WEP, identified by RX0 and XX0
keyworks and with different priorities. Note that the RX0 key of the
first records has nothing to do with the identical one in the second
record: they just happen to look the same, but a <DNS- service-key>
is meaningful and must be uniqe only within a <DNS-MTAkey>.
As priority 20 indicated the preferred WEP, and we already have also
the preferred connection stack (identified by RX0 key) we can query
directly for connection data, looking an HINFO record like:
C.RX0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
and attempt connection to the remote WEP. If this fails, according to
Eppenberger's document, we will then query for the next supported
stack connecton record (identified by XX0 key plus <DNS-MTAkey>) and
continue like that.
Case 2: OR address C=is;ADMD=0;PRMD=isanet;O=mgr;S=postmaster;
After translation of the routing part of the OR address in DNS syntax,
a first query for an MX records list will be issued for
O-mgr.PRMD-isanet.ADMD-0.C-is.X400.ARPA
DNS will match the query with:
IN MX 10 D5.MTA-infn-d-it.ADMD-garr.C-it.X400.ARPA.
IN MX 20 D0.MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
In this case the answer only indicates 2 possible WEPs with their
priority, but gives no preference about possible connection stacks,
nor informs us about the availble connection stacks. We will then
query for an HINFO record containing the WEP host informations for the
preferred 'cosine-gw.infn.it' one, i.e. query for
MTA-cosine-h-gw-d-infn-d-it.ADMD-garr.C-it.X400.ARPA.
HINFO record. The result will be:
"Password: not used; COM=VAX9210; OPS=VMS5.5; MHS=MRX2.2-000" \
"RX0.XX0"
We can now choose, at our discrection about 2 possible connecton
stacks, identified by RX0 and XX0 keywords, querying for the
respective <WEP-call-data> records and continuing as for the case 1
example.
8. Conclusion
The use of the PTR resource-record and a new name space tree promises
to provide a good possible repository for mapping informations. 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 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 informations, including the routing 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 further study to define a
storage detailed strategy for routing informations is expected when
the table-driven routing strategy for X.400 MHS becomes stable.
Software to query the DNS and then to convert between the textual
representation of DNS resource records and the address format defined
in RFC1327 needs to be developed. Also some tools to derive DNS
format from DOMAIN and WEP documents will be needed to help the
implementation of this specification.
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", RFC 1034, USC/Information Sciences Institute, November
1987.
[RFC 1035] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, USC/Information Sciences Institute, November
1987.
[Internet draft] Eppenberger, U., "Routing Coordination for X.400
MHS services within a multi protocol / multi network environment",
March 1992.
10. Document Expiration Date
This document was submitted on September 23rd, 1992 and its validity
will expire on March 23rd 1993.
