As per Relevance of the word associate, we have this rfc below:
Network Working Group S.E. Hardcastle-
Requests for Comments 1279 University College
November 1991
X.500 and
Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement
requested. Please refer to the current edition of the ``
Official Protocol Standards'' for the standardization state
status of this protocol. Distribution of this memo is unlimited
This RFCconsiders X.500 in relation to Internet and UK Domains
A basic model of X.500 providing a higher level and
descriptive naming structure is emphasised. In addition,
mapping of domains onto X.500 is proposed, which gives a range
new management and user facilities over and above those
available. This specification proposes an experimental
mechanism to access and manage domain information on the
and in the UK Academic Community. There is no current
to provide an operational replacement for DNS
RFC 1279 X.500 and Domains November 1991
1 The Domain Name
The Domain (Nameserver) System (DNS) provides a hierarchical
labelling system [Moc87a] [Moc87b] [Lar83]. Example domains are
MIT.
VENERA.ISI.
CS.UCL.AC.
Entries usually have a single name, although pointers to entries (
subtrees) may be provided by CNAME records. Information (
records) is associated with each entry. Name components are
chosen to be shortish (e.g., ``CS'').
RFC 822 mailbox names are closely related [Cro82]. For example
The local-part of the RFC 822 mailbox can be considered as one
lower in the domain hierarchy
2 X.500
The OSI Directory, usually known as X.500, provides a very
naming framework [CCI88]. A basic usage of X.500 is to
Organisationally Structured Names. A Schema for this is
within the standard. Name components will typically have
values. This is an example directory name represented in
form
Country
Organisation University College
Organisational Unit Computer
Common Name Stephen E. Hardcastle-
This can also be written in the ``User Friendly Name''
defined in [HK91]. This syntax is used for names in the rest of
document
Stephen E. Hardcastle-Kille, Computer Science
Hardcastle-Kille Page 1
RFC 1279 X.500 and Domains November 1991
University College London,
This type of structure is termed ``organisational X.500''. This is
subset of the general capabilities
3 The basic
X.500 has as much relation to the DNS as DNS has to ARP.
This is, essentially, the position adopted here. The basic model
that organisational X.500 is providing a layer of naming at the
above domain names. These structured names can be considered to
a naming layer above domain names. There are the following
differences
o Organisational X.500 tends to use longer and more
o The organisational X.500 DIT is slightly shallower than the
o X.500 has a richer information framework than
These differences suggest that the following should NOT be done
o Represent X.500 information in the
o Have an algorithmic mapping between the two
This note proposes to represent DNS information in the DIT, and
provide for a loose coupling between the two trees. This note
not propose an equivalencing of X.500 and Domains
The proposed model is illustrated in Figure 1. Both an
and domain structure is represented in the DIT, by use of
object classes and attribute types. A weak linkage is
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
organisational DIT or domain namespace. The linkage is achieved
use of special attributes, as described in Section 11.
Hardcastle-Kille Page 2
RFC 1279 X.500 and Domains November 1991
j jZ
j j
jj Z
jjj
Domain Component=UK Country Name=
|
|
|
Domain Component=AC Organisation Name=Univeristy College
*
ss
Domain Component=UCL Org Unit Name=Computer
| *
||
Domain Component=CS Common Name=Steve
| *
|
Domain Component=S.
Figure 1: Example X.500
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
the previous section. However, it is also possible to use X.500
other ways. In particular, there are benefits from
Domains in X.500. Note that this is very different to equivalencing
as no attempt is made to represent X.500 information within the
scheme. There are the following potential advantages
o Domain Services (DNS and NRS) could be replaced with an
service (some may not view this as an advantage). This
particularly attractive for OSI services, where use of a non-
directory may be inappropriate
o For Internet sites, access to domain information (beyond
records) could be provided for systems registered remotely.
UK Academic Community sites, access to domain information
domains not registered in the NRS could be given. For
neither on the Internet nor in the UK Academic Community
will usually be even more of an advantage, as they usually
very limited information on domains
o Assuming that information is downloaded from an X.500
into a DNS or NRS system, the remote management facilities
X.500 could be used. This is possible because of the
security features of X.500.
Note: For initial work, the converse situation of
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,
be provided. This would allow users to browse the
namespace, and to determine information associated with
domains
o The X.500 framework would allow for additional
information to be stored, and to relate the domain names into
more complex structure of information. For example, this
allow for the managers of a system to be identified,
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
access other user information on the basis of this key) could
provided. This may be useful for the user to
information about a message originator
o This technique may be useful to facilitate introduction
security, as it will enable certificates to be associated
domains and mailboxes. This may be very useful for the
enchanced mail work [Lin89].
5 Representing Domain
A new attribute syntax is defined
CaseIgnoreIA5StringSyntax ATTRIBUTE-
IA5
MATCHES FOR EQUALITY SUBSTRINGS
A new attribute and two new object classes are defined
DomainComponent
WITH ATTRIBUTE-SYNTAX caseIgnoreIA5
SINGLE
Domain OBJECT-
SUBCLASS OF
MUST CONTAIN -DomainComponent
MAY CONTAIN -AssociatedName
organizationName
organizationalAttributeSet
manager
RFC822Mailbox OBJECT-
SUBCLASS OF
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.
manager attribute is defined in the COSINE and Internet
architecture [BHK91]. It allows a manager to be associated with
domain, which is useful where the manager of the domain is
to the manager of the object defined by the AssociatedName. This
allow any domain to be represented in an X.500 hierarchy. The
part of an RFC 822 mailbox is treated as a special sort of
component, and so these can be represented in the tree as a
extension of the hierarchy
For example, consider the mailbox S.Kille@cs.ucl.ac.uk. This
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=
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
to define (e.g., Machine Type, Owner, Location etc.). This
some information which truly belongs to the domain to be
there. It also allows for further information to be associated
the domain/mailbox when there is not a relevant part of
organisationally structure DIT to be pointed at. When there is
associated part of the DIT, information from that part of the
should not be duplicated in the domain entry
6
Wildcards are supported by having "*" as a special domain
name. If there is a need to emulate wildcard matching using
directory, the following algorithm must be employed. For example,
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=
If A.B.PODUNK.COM is looked up in the directory, the query will
and indicate that two components are matched. A substitution
be made, and *.*.PODUNK.COM looked up explicitly to identify
associated information
7 DNS
DNS information can be associated with an entry in the DIT. It
important that this is done in a manner which is exactly equivalent
the information stored in the DNS. This will allow the DIT to
information loaded from the DNS or vice versa. All (authoritative
records associated with a domain will be stored in the DIT. There
no attempt made by the OSI Directory to emulate DNS caching or
handling. It is assumed that the master entries are maintained by
of DNS Zone Transfer (or equivalent), and that they can be treated
authoritative. There is a need to define an attribute syntax
represents a DNS record. This then allows DNS records to be stored
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
new syntax, which would be awkward. There is a problem
handling the resource format in a general manner
DNS Binary Encoded Use the formally defined record syntax.
would be convenient for access to the data by DNS
software, but would be an awkward encoding for independent X.500
DUAs
Text encoded Use of a text encoding derived from the
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
the definitions of section 5.1 of RFC 1035. It
Hardcastle-Kille Page 7
RFC 1279 X.500 and Domains November 1991
[ ";" ]
Three examples of this (for domain C.ISI.EDU) might be
500 A 10.1.0.52 ; Basic address
IN 600 MX 10 VENERA.ISI.EDU. ; MX
600 IN MX 10 VENERA.ISI.EDU. ; MX record - other
Note that
o The class and TTL may be in either order (following RFC 1035)
o The class defaults to
o Domains must always be fully specified (i.e., master
abbreviate rules are not used).
o The TTL for a record must always be present (this saves looking
the parent entry to find the SOA record).
o Records (e.g., SOA) may be multiline. Lines should be
with the two IA5 characters .
CNAME records are mapped symmetrically onto Directory Aliases
This is now defined in terms of attribute and object
definitions. A single record type is defined, as opposed to
attribute type per record type. This allows the definition to
require extension when new DNS Record types are define. However
there is some loss of efficiency if only a single record type
needed, as filtering must be done by the DUA
Similarly, no distinction is made on the basis of DNS class.
means that if there are two class hierarchies, that they must
represented in a single DIT, and that information for
classes must be separated by DUA filtering
DNSDomain OBJECT-
SUBCLASS OF
MAY CONTAIN -
DNSRecord "
Hardcastle-Kille Page 8
RFC 1279 X.500 and Domains November 1991
DNSRecord
ATTRIBUTE-SYNTAX IA5
MATCHES FOR
Lookup of a domain is achieved by translating it algorithmically to
Distinguished Name (DN), and reading back attributes desired.
information can be managed and searched in a straightforward fashion
The information may also be downloaded into a DNS database.
should be done by use of zone transfer. A tool to perform
transfer (in both directions) between a DNS Server and a DSA
seem to be both straightforward and useful. This would be a key
in a transition to X.500 based management of the DNS. It would
allow a large part of the DNS namespace to be rapidly made
in an X.500 pilot
Inverse information can be derived by the usual IN-ADDR domain,
will be represented in the same manner in the DIT
8 NRS
Information associated with the UK NRS (Name Registration Scheme)
be handled in a similar manner [Lar83]. This is being developed in
separate document by Alan Turland
9 Application Entity
In many cases, Application entities will be closely related
domains. In some cases, it may be appropriate to give
Entities names which are related to the DNS part of the DIT. In
case, the Domain Name will be used to identify the application,
the entry for the domain will also be of object class
Process. The children of this entry will identify
Entities, with names such as ``FTAM Service''.
10
It is clearly useful to represent networks within the DIT. A
note on how to do this is given here. It is likely that
specification will later be evolved in a separate document.
Hardcastle-Kille Page 9
RFC 1279 X.500 and Domains November 1991
defines an Object Class for a general network, and shows how it can
subclassed to define technology specific networks
Network OBJECT-
SUBCLASS OF
MAY CONTAIN -
Manager
Locality
Description "
IPNetwork OBJECT-
SUBCLASS OF
MUST CONTAIN -AssociatedDomain
The Network Object Class allows networks to be defined, and for
attributes to be associated with the entry. A network will
appear in more than one organisational structure, and this
should be achieved by use of aliases. This grouping can
management of networks
The subclass IPNetwork mandates linkage into the DNS part of the DIT
This will be represented in the DIT using the structures of RFC 1101
[Moc89]. Both of the domains which identify the network should
represented in the Object Class. For example, a network might
the (user friendly) name
UCL-Ethernet, University College London,
This would have associated domains 0.0.40.128.IN-ADDR.ARPA
UCL-ETHERNET.UCL.AC.UK. These would both have the analogous
representations. For example
DomainComponent=0, DomainComponent=0, DomainComponent=40,
DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=
11
There is a need to associate the organisational X.500 DIT and the
tree. The objects represented are different (Domain 6= Organisation
Person 6= RFC 822 Mailbox). Therefore aliasing is not an
linkage. However, in many cases, there is a linkage which is
Hardcastle-Kille Page 10
RFC 1279 X.500 and Domains November 1991
stronger than that implied by the seeAlso attribute. Therefore,
define new attributes, which represent this stronger cross-linkage
The same mechanism can be used to link a domains with an
Entity or an Application Process
Links from the organisational X.500 DIT to the DNS tree are
by a new attribute, which could be present in Organisation
Organisational Unit entries
ObjectWithAssociatedDomain OBJECT-
SUBCLASS OF
MUST CONTAIN -AssociatedDomain
AssociatedDomain
WITH ATTRIBUTE-SYNTAX ia5
For example, the organisational entry
University College London,
would have an attribute
AssociatedDomain = UCL.AC.
Similarly, an RFC 822 mailbox attribute is used to link entries
Person Object Class to their associated DNS entry. This attribute
defined in the Cosine and Internet Naming Architecture [BHK91].
Conversely, there are pointers from the DNS represented tree into
organisational X.500 DIT
AssociatedName
WITH ATTRIBUTE-SYNTAX
This attribute is associated with the Domain object class
This entry is used to provide linkage from the DNS X.500
into the organisational X.500 hierarchy. Where such entries do
exist, attributes in the DNS entry (such as phone number) may be used
It is recommended that information is not duplicated. The
setup is for the DNS attributes to be rather skeletal, with
into the organisational X.500 DIT
Hardcastle-Kille Page 11
RFC 1279 X.500 and Domains November 1991
For example, the domain UCL.AC.UK would be represented in the DIT as
DomainComponent=UCL, DomainComponent=AC
DomainComponent=
This entry would have in it an AssociatedName attribute with value
University College London,
This example shows a simple case with 1:1 linkage. There are
where a domain might be associated with multiple organisations, or
organisation with multiple domains
12 Conclusions and proposals for
Experiments should be undertaken to determine the practicality
utility of this scheme, in a pilot environment. A possible
to this experimentation is described in Appendix A
Object Identifiers have been assigned for this purpose in the
and Internet Naming Architecture [BHK91].
[BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and
X.500 schema. Request for Comments RFC 1274, Department
Computer Science, University College London, November 1991.
[CCI88] The Directory --- overview of concepts, models and services
December 1988. CCITT X.500 Series Recommendations
[Cro82] D.H. Crocker. Standard of the format of ARPA internet
messages. Request for Comments 822, University of Delaware
August 1982.
[HK91] S.E. Hardcastle-Kille. Using the OSI directory to
user friendly naming. Request for Comments in preparation
Department of Computer Science, University College London
November 1991.
Hardcastle-Kille Page 12
RFC 1279 X.500 and Domains November 1991
[Lar83] J. Larmouth. JNT name registration technical guide,
1983.
[Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail
Part 1 --- Message Encipherment and
Procedures. Request for Comments 1113, Bolt, Beranek,
Newman, August 1989.
[Moc87a] P. Mockapetris. Domain names - concepts and facilities
Request for Comments RFC 1034, USC/Information
Institute, November 1987.
[Moc87b] P. Mockapetris. Domain names - implementation
specification. Request for Comments RFC 1035,
USC/Information Sciences Institute, November 1987.
[Moc89] P. Mockapetris. DNS encoding of network names and
types. Request for Comments RFC 1101, USC/
Sciences Institute, April 1989.
13 Security
This memo does not directly address security issues. However, due
the facilities of X.500, this proposal could lead to a more secure
to access and manage domain information
14 Author's
Steve Hardcastle-
Department of Computer
University College
Gower
WC1E 6
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.
Hardcastle-Kille Page 13
RFC 1279 X.500 and Domains November 1991
A Possible Deployment
This appendix notes a possible approach to deploying an experiment
evaluate this mechanism. The following components of a
experiment are noted
1. User tool. This will take a domain or mailbox as input.
will be looked up in the DIT. This tool should be capable of
o Attempting to correct user
o Helping
o Looking up information associated with the domain (or mailbox
and associated name, in particular the manager (of both
and associated name) and information on the manager (e.g.,
phone number and mailbox).
o Supply DNS
o Handle IN-ADDR.ARPA inverse lookups if supplied with an
o Look up
2. A procedural library to allow user interfaces to make easy use
these facilities
3. Zone transfer tool. This will use the zone transfer protocol
transfer information between a DSA and Domain Nameserver.
writing to the DSA, attributes in an entry which are not
records should remain untouched
4. Linkage patching tool. When the organisational DIT
established, associated domain pointers are usually inserted.
tool can be written to search the DIT and insert the
pointers
5. DNS Manager Tool. This will allow user addition of
information into the DNS part of the DIT. A standard DUA
probably be used for this
Hardcastle-Kille Page 14
RFC 1279 X.500 and Domains November 1991
6. Mailbox download tool. This will allow download of
mailboxes, with pointers to the user entries
7. Emulation DNS Server, using the Directory as a database.
server should maintain a permanent connection to its local DSA.
there is no OSI bind, the response of this server can be at
as fast as a normal DNS server. There can be two variants of
server
(a) Using a local DSA as a local database but using
distributed operations
(b) Do all lookups in the directory (using Directory
Operations).
An initial experiment is straightforward. The Zone Transfer Tool (3)
can be used to download a large part of the DNS space into a
DSA (there will be some restrictions, as parts of the DNS hierarchy
not permit zone transfer). This can be used repeatedly to
the information. The linkage patching tool (4) can be used to put
pointers to parts of the DIT. The user tool can then be used (by
sites participation the the directory pilot) to look up
information. This will allow the utility of the approach to
evaluated. The manager tool (5) will allow extra information to
added to parts of the DNS tree
The next stage will be to distribute the DNS part of the DIT
multiple DSAs using Directory distribution techniques
The emulation DNS Server (7) will be useful to ensure that
functionality is being offered by the Directory. It can also be
to examine performance differences
A final step is to master some parts of the DNS hierarchy in the DIT
Because of the zone transfer technique, this will be
transparent to the DNS user. Management benefits can then
examined
Hardcastle-Kille Page 15
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
