using DNS for rfc1327 mapping rules, new I-D summary

[[e-mail]]

Hallo,
Please, do not use REPLY to my address above, if possible, but send at
my usual adress: [e-mail]
(sorry for the inconvenience!)
------------------------------

Well,
working home gives really a quiet environment and a lot of time to think,
(one should consider doing it more often...).

Thus I also had time (finally) to put together all the suggestion and 
discussions I had with many of you, expecially with Christian Huitema,
about the new version of the I-D "using the internet DNS for rfc1327
mapping rules distribution". I also remind you that the other draft,
dealing with x.400 routing rules has been currently left out, waiting for
long-bud tests and results, and its ideas will probably contribute to
long-bud itself.

Before editing the new version of the I-D in its "readable" form, I'd just
like to summarize here the important chenges/ideas which came out of the
discussions.

The basic idea of using DNS to distribute mapping informations for RFC1327
gateways can be seen in a similar perspect as the use of MX records: it
gives the Internet mail community a way to communicate smoothly with the
GO-MHS community and also with the X.400 commercial service providers. In fact
the MX records pointing to the appropriate RFC1327 gateway(s) are not enough
to obtain a "clean" addressing, and using tables (we all know) is not adequate.
Thus the addition of the RFC1327 mapping information to DNS is anadditional
service which the Internet community delivers to its members via its powerful
DNS system and to the GO-MHS community members, too. This means that it is not
something like using the Internet DNS to serve a community "outside" the
Internet itself, but an additional internal service.

This way of providing mapping rules to the Internet community also offers
services to many possible tools/programs (like address converters, or
Internet mailers accepting X.400 native addresses) for end users' benefit.

Thus, the architecture behind the whole system must be solid, as the solution
is not a temporary bypass, but it is likely to become one of the important
Internet services.

Two major objections were moved to the first version of the proposal:
the use (misuse?) of PTR DNS resource records and the creation from the
DNS root of a totally new X.400 tree. During the discussions new solutions
were identified which removes these objections (see later). More over a
smooth transition and deployment plan has been identified to reach the
"final state" of the implementation which will give transparently the service
to the users "now" and keep it running during the creation of the service.

Creating a new x.400 tree starting from the DNS root was seen as a major
organizational burden (and source of troubles): in fact it would have
required central coordination while identifying, per each X.400 country
code, the correct authority to delegate the national tree. The delegation
of such a duty to the GO-MHS coordination service was not seen appropriate
either due to still lacking presence of many public ADMDs in the community
itself. It was thus suggested to "move down" the origin of the new x.400
name tree at national level, delegating each country authority to keep
contacts with the local GO-MHS mapping authority and the other public
service providers. This is also in line with the "regionalization and authority
delegation" process currently going on in the Internet itself for many other
purpouses (like assigning ip networks). Thus there will be, at second level,
the origin of the new tree in each country where mapping rules exists.
The new draft about "mapping authorities" being prepared by wg-msg will also
help a lot the task of identifying the national bodies which can actually
"write" RFC1327 mapping rules and hence insert them in DNS, too.

An attempt was also done to check if it is viable just not to create at all
a new national x.400 naming tree, just using some methods in order to
store in the existing tree also the X.400 names. A statistic done on the
current RFC1327 mapping tables, however, shows that the number of exceptions
(i.e. non similarities between RFC822 domain and X.400 O/R name) is a very
high percentage. Indeed the RFC1327 mapping rules probably represent a long
list of exceptions to the "normal case" where RFC822 domain and X.400 O/R
address are similar, and probably most of the real e-mail addresses are
similar in RFC822 and X.400... but the "data set" we are dealing with are
the RFC1327 rules themselves, hence a high percentage of dissimilarities
in this data set implies a large number of query failures to DNS and a really
complex management of the required aliases in DNS. Thus such x.400 new branch
at national level to cover the X.400 to RFC822 mapping (table 1 rules) seems
needed. On the other hand, the existing domain tree is usable to store table 2
rules, even if a new resource record (see later on) is foreseen.

(As a side effect of the statistical study we discovered also still a really
large number of "unauthorized" mappings, like prmd=edu; admd=garr; c=it, still
around... )

For each country (.edu, .mil etc. are out as we will use .us!) top domain
thus, table 1 will be under the special new tree,and table 2 will be in the
ordinary domain tree. The problem of building the structure and delegating
authority is considered later in the "transition and implementation".

The naming of the new national branch (BTW: proposal for its label?
X400.it ? RFC1327.it ? it must be unique and a RESERVED name) will follow
X.400 O/R names structure, but the DNS syntax proposed in version 1 of the
draft will still be used: it is more clean and easy to understand a domain
like O-mitsou.PRMD-inria.ADMD-red.C-fr than a line filled with "$" and "@"...
More over it is less likely to break any old DNS implementation not supporting
these special characters.

The old draft suggested PTR as possible candidates to store the mapping data.
Even if, creating a totally new tree there would have not been any clash
with different use of PTR records, this would have made impossible the use
of the normal domain tree to store table 2 mapping, and would have required
multiple queries to DNS to identify the correct mapping rule. During the
discussion the proposal to define a new DNS RR was stongly supported mainly
due to the following reasons: 

it avoids any possible confusion/clash with other implementations/uses of PTRs;
it requires one query only to DNS to obtain the mapping rule;
it can support special syntax/features, making it flexible for the future;
it makes possible to use the normal domain tree for table 2 rules;
it is the appropriate method to ensure a solid DNS architecture, enabling it
to follow the standard track.

This will require, of course, the modification of the existing DNS implemen-
tations (tipically BIND), making slower the installation process. However
the use of DNS to store/obtain mapping rules already requires additional s/w
installation; thus a new public domain version of some DNS application will
be provided jointly with the remaining s/w. More over the installation of the
new DNS application can be done gradually, allowing time for transition (see
again later).

The new proposed DNS RR (named XA) has the following structure:

     Class:  IN

     RR:     XA   (X.400 address mapping)

             +------------------------+
             |  preference (1 octet)  |
             +------------------------+
             /  RFC1327 mapping rule  /
             /     in DNS syntax      /
             +------------------------+

The RFC1327 and the X.400 standards states that there is only one possible
mapping from RFC822 to X.400, and if a customer subscribes to more than
one X.400 service provider, then its ADMD value must be a blank. However
currently many public ADMDs force their customers to have their own ADMD
value when connecting via them of when delivering mails via the ADMD backbone:
it often happens that ADMD=<blank> is refused, too. The "preference" value
allows to specify one or more possible mappings (i.e. one or more ADMD
values in the above example). This is totally not foreseen curently, and thus
the implementation coudl require just one possible mapping, forcing the
preference filed to be a dummy field. However it came out to be quite
reasonable to forsee such a chance since now. Here is an example of how the
new records will look in a DNS config table:

*.inria.fr.   IN  XA  10   inria.fr#PRMD-inria.ADMD-red.C-fr

on the other way...

*.PRMD-inria.ADMD-red.C-fr.X400.fr. IN XA 10  PRMD-inria.ADMD-red.C-fr#inria.fr

or better (C-fr is just redundant!)

*.PRMD-inria.ADMD-red.X400.fr.      IN XA 10  PRMD-inria.ADMD-red.C-fr#inria.fr

Of course the whole DNS name compression and abbreviation remains valid, and
no additional processing is required by this XA resource record.

Installation and configuration: the creation of this new system should give
users the service "now" and let then work during the whole deployment phase
smoothly. This can be obtained in variuos steps.

Step 1: the whole structure is centralised. This step will last very shortly
and should be supported by the DNS query software as a temporary feature
which can be disabled or removed totally in the future.

The first national tree is created (one is already existing as X400.it) and
the whole table 1 structure is stored there. Those using the DNS to obtain
the mapping rules have, of course, installedthe new DNS s/w and the appropriate
query routine library. The first query will be the standard one: XA record
in the appropriate country (i.e. in X400.fr if we look for something in C=fr).
If this query fails, and the temporary behaviour is enabled, a new query for 
the pre-fixed central tree is issued, and you get the ansewer. For table 2
the same mechanism applies: a first query for XA record to the correct branch.
if it fails, then a new query to the centralized tree (wherer for example we
have both the provisional PRMD-inria.ADMD-red.C-fr.X400.it and inria.fr.X400.it
recods) to get the correct answer.

Step 2: each country is delgate for its own mappings in DNS (this can be on
a per county bases, it does not need to be at once).
Each top level domain (country code only, no .edu etc...) creates its
nationally centralised tree: x400.fr containes the whole c-fr in its standard
final format, but authority is not distributed yet. Also the table 2 rules
are centralised at top level, in their standard final format, i.e. the
.fr is authoritative for the whole XA records of .fr, and no delegation is
done. This requres installation of the new DNS implementation at national
level.

Step 3: final national delegation of authority. This is done in the usual
DNS delegation style (SOA for both the X.400 new tree and insertion of the
XA values for the normal domain tree). this is done while the new DNS
implementation is widespread...

Well, it is a long summary... I'm preparing the new I-D for Houston, but
I wanted to give you already the ideas in it.

Thanks since now to all those who contributed to the discussion, in particular
to Christian Huitema, Jon Postel, Paul Mockapretis, Rob Austin and the whole
x400ops, wg-msg and namedroppers groups.

regards
Claudio