rfc1279.txt

RFC 的详细文档！

Network Working Group                            S.E. Hardcastle-Kille
Requests for Comments 1279                   University College London
                                                         November 1991







                          X.500 and Domains









Status of this Memo
    This memo defines an Experimental Protocol for the Internet
    community.  Discussion and suggestions for improvement are
    requested.  Please refer to the current edition of the ``IAB
    Official Protocol Standards'' for the standardization state and
    status of this protocol.  Distribution of this memo is unlimited.
Abstract

    This RFCconsiders X.500 in relation to Internet and UK Domains.
    A basic model of X.500 providing a higher level and more
    descriptive naming structure is emphasised.  In addition, a
    mapping of domains onto X.500 is proposed, which gives a range of
    new management and user facilities over and above those currently
    available.  This specification proposes an experimental new
    mechanism to access and manage domain information on the Internet
    and in the UK Academic Community.  There is no current intention
    to provide an operational replacement for DNS.




RFC 1279                X.500 and Domains                November 1991


1  The Domain Name System

The Domain (Nameserver) System (DNS) provides a hierarchical resource
labelling system [Moc87a] [Moc87b] [Lar83].  Example domains are:

MIT.EDU
VENERA.ISI.EDU
CS.UCL.AC.UK


Entries usually have a single name, although pointers to entries (not
subtrees) may be provided by CNAME records.  Information (resource
records) is associated with each entry.  Name components are typically
chosen to be shortish (e.g., ``CS'').
RFC 822 mailbox names are closely related [Cro82].  For example:


    <[e-mail]>

The local-part of the RFC 822 mailbox can be considered as one level
lower in the domain hierarchy.


2  X.500

The OSI Directory, usually known as X.500, provides a very general
naming framework [CCI88].  A basic usage of X.500 is to provide
Organisationally Structured Names.  A Schema for this is defined
within the standard.  Name components will typically have longish
values.  This is an example directory name represented in Tabular
form:


           Country              GB
           Organisation         University College London
           Organisational Unit  Computer Science
           Common Name          Stephen E. Hardcastle-Kille

This can also be written in the ``User Friendly Name'' notation
defined in [HK91].  This syntax is used for names in the rest of this
document:


    Stephen E. Hardcastle-Kille, Computer Science,

Hardcastle-Kille                                                Page 1




RFC 1279                X.500 and Domains                November 1991


    University College London, GB

This type of structure is termed ``organisational X.500''.  This is a
subset of the general capabilities.


3  The basic model

    X.500 has as much relation to the DNS as DNS has to ARP. Paul
    Mockapetris


This is, essentially, the position adopted here.  The basic model is
that organisational X.500 is providing a layer of naming at the level
above domain names.  These structured names can be considered to form
a naming layer above domain names.  There are the following key
differences:

 o  Organisational X.500 tends to use longer and more descriptive
    values

 o  The organisational X.500 DIT is slightly shallower than the DNS
    tree

 o  X.500 has a richer information framework than DNS


These differences suggest that the following should NOT be done:

 o  Represent X.500 information in the DNS

 o  Have an algorithmic mapping between the two hierarchies

This note proposes to represent DNS information in the DIT, and to
provide for a loose coupling between the two trees.  This note does
not propose an equivalencing of X.500 and Domains.

The proposed model is illustrated in Figure 1.  Both an organisational
and domain structure is represented in the DIT, by use of appropriate
object classes and attribute types.  A weak linkage is provided
between the two parts of the tree by use of special attributes.  Here,
the linkage is 1:1, but it may be more complex for some parts of the
organisational DIT or domain namespace.  The linkage is achieved by
use of special attributes, as described in Section 11.

Hardcastle-Kille                                                Page 2




RFC 1279                X.500 and Domains                November 1991










                  j jZ Z

               j j       ZZ
            jj              Z Z
        jjj                    ZZ

Domain Component=UK          Country Name=GB
                                |
                                |
                                |
Domain Component=AC       Organisation Name=Univeristy College London

                        *        BB
              ss                  BBB

Domain Component=UCL      Org Unit Name=Computer Science
      |                *

      ||     ss
Domain Component=CS       Common Name=Steve Kille

     |                  *
     |        ss

Domain Component=S.Kille
                    Figure 1:  Example X.500 tree











Hardcastle-Kille                                                Page 3




RFC 1279                X.500 and Domains                November 1991


4  Representing Domains in X.500

Domains are at the level below X.500 names of the form illustrated in
the previous section.  However, it is also possible to use X.500 in
other ways.  In particular, there are benefits from representing
Domains in X.500.  Note that this is very different to equivalencing,
as no attempt is made to represent X.500 information within the domain
scheme.  There are the following potential advantages:


 o  Domain Services (DNS and NRS) could be replaced with an OSI
    service (some may not view this as an advantage).  This is
    particularly attractive for OSI services, where use of a non-OSI
    directory may be inappropriate.

 o  For Internet sites, access to domain information (beyond MX
    records) could be provided for systems registered remotely.  For
    UK Academic Community sites, access to domain information for
    domains not registered in the NRS could be given.  For sites
    neither on the Internet nor in the UK Academic Community there
    will usually be even more of an advantage, as they usually have
    very limited information on domains.

 o  Assuming that information is downloaded from an X.500 database
    into a DNS or NRS system, the remote management facilities of
    X.500 could be used.  This is possible because of the extra
    security features of X.500.

    Note: For initial work, the converse situation of information
        being mastered in Domain Databases and uploaded into the X.500
        DIT is more likely.

 o  User access to the domain data, and in particular searching, could
    be provided.  This would allow users to browse the domain
    namespace, and to determine information associated with the
    domains.

 o  The X.500 framework would allow for additional management
    information to be stored, and to relate the domain names into a
    more complex structure of information.  For example, this might
    allow for the managers of a system to be identified, and
    information on how to contact the manager.



Hardcastle-Kille                                                Page 4




RFC 1279                X.500 and Domains                November 1991


 o  A facility to map RFC 822 mailbox into a Directory Name (and thus
    access other user information on the basis of this key) could be
    provided.  This may be useful for the user to determine
    information about a message originator.

 o  This technique may be useful to facilitate introduction of
    security, as it will enable certificates to be associated with
    domains and mailboxes.  This may be very useful for the privacy
    enchanced mail work [Lin89].


5  Representing Domain Names

A new attribute syntax is defined:


CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
    IA5String
    MATCHES FOR EQUALITY SUBSTRINGS ORDERING


A new attribute and two new object classes are defined:


DomainComponent ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax
    SINGLE VALUE

Domain OBJECT-CLASS
    SUBCLASS OF top
    MUST CONTAIN -DomainComponent"
    MAY CONTAIN -AssociatedName,
        organizationName,
        organizationalAttributeSet,
        manager"

RFC822Mailbox OBJECT-CLASS
    SUBCLASS OF Domain
    MAY CONTAIN -commonName,
       surname,
       description,
       telephoneNumber,
       postalAttributeSet,
       telecommunicationAttributeSet "

Hardcastle-Kille                                                Page 5




RFC 1279                X.500 and Domains                November 1991


Note that the attribute AssociatedName is defined in Section 11.  The
manager attribute is defined in the COSINE and Internet naming
architecture [BHK91].  It allows a manager to be associated with the
domain, which is useful where the manager of the domain is different
to the manager of the object defined by the AssociatedName.  This will
allow any domain to be represented in an X.500 hierarchy.  The local
part of an RFC 822 mailbox is treated as a special sort of domain
component, and so these can be represented in the tree as a natural
extension of the hierarchy.
For example, consider the mailbox [e-mail].  This will
lead to the following structure in the DIT:

             ___________________________________________
             |_Object_Class__|RDN_Type________|RDN_Value_|
             | Domain        |DomainComponent |UK        |
             | Domain        |DomainComponent |AC        |
             | Domain        |DomainComponent |UCL       |
             | Domain        |DomainComponent |CS        |
             |_RFC822Mailbox_|DomainComponent_|S.Kille__ |

This can be represented in User Friendly Name format as:


DomainComponent=S.Kille, DomainComponent=CS, DomainComponent=UCL,
DomainComponent=AC, DomainComponent=UK

Note that the RFC822Mailbox Object Class is a subclass of Domain.
Some attributes are allowed to be associated with these objects.
There may be other additional management attributes which it is useful
to define (e.g., Machine Type, Owner, Location etc.).  This allows
some information which truly belongs to the domain to be represented
there.  It also allows for further information to be associated with
the domain/mailbox when there is not a relevant part of the
organisationally structure DIT to be pointed at.  When there is an
associated part of the DIT, information from that part of the DIT
should not be duplicated in the domain entry.


6  Wildcards


Wildcards are supported by having "*" as a special domain component
name.  If there is a need to emulate wildcard matching using the
directory, the following algorithm must be employed.  For example, the

Hardcastle-Kille                                                Page 6




RFC 1279                X.500 and Domains                November 1991


wildcard entry for *.*.PODUNK.COM would be represented in the DIT as:

    DomainComponent=*, DomainComponent=*,
    DomainComponent=MIT, DomainComponent=COM


If A.B.PODUNK.COM is looked up in the directory, the query will fail
and indicate that two components are matched.  A substitution should
be made, and *.*.PODUNK.COM looked up explicitly to identify the
associated information.


7  DNS Information

DNS information can be associated with an entry in the DIT. It is
important that this is done in a manner which is exactly equivalent to
the information stored in the DNS. This will allow the DIT to have
information loaded from the DNS or vice versa.  All (authoritative)
records associated with a domain will be stored in the DIT. There is
no attempt made by the OSI Directory to emulate DNS caching or TTL
handling.  It is assumed that the master entries are maintained by use
of DNS Zone Transfer (or equivalent), and that they can be treated as
authoritative.  There is a need to define an attribute syntax which
represents a DNS record.  This then allows DNS records to be stored in
the DIT. There are three possible encodings of this record:

ASN.1 Encoded This is the most natural approach in terms of X.500.
    However, it would require all users of this service to handle the
    new syntax, which would be awkward.  There is a problem with
    handling the resource format in a general manner.

DNS Binary Encoded Use the formally defined record syntax.  This
    would be convenient for access to the data by DNS related
    software, but would be an awkward encoding for independent X.500
    DUAs.

Text encoded Use of a text encoding derived from the DNS
    specifications.  This is straightforward to map onto DNS protocol,
    and easy to support in a naive X.500 DUA. This approach is chosen.


The syntax is defined in IA5 characters.  The BNF of the record uses
the definitions of section 5.1 of RFC 1035.  It is


Hardcastle-Kille                                                Page 7




RFC 1279                X.500 and Domains                November 1991