Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Table of Contents

1.  Abstract
2.  Background
3.  Mapping Domain Names into Distinguished Names
4.  Attribute Type Definition
5.  Object Class Definitions
5.1  The dcObject object class
5.2  The domain object class
6.  References (BOILERPLATE)
7.  Security Considerations
8.  Authors' Addresses (BOILERPLATE)
9.  Full Copyright Statement (BOILERPLATE)
§  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Abstract

The Lightweight Directory Access Protocol (LDAP) uses X.500- compatible distinguished names [3] for providing unique identification of entries.

This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name.

2. Background

The Domain (Nameserver) System (DNS) provides a hierarchical resource labeling system. A name is made up of an ordered set of components, each of which are short strings. An example domain name with two components would be "CRITICAL-ANGLE.COM".

LDAP-based directories provide a more general hierarchical naming framework. A primary difference in specification of distinguished names from domain names is that each component of an distinguished name has an explicit attribute type indication.

X.500 does not mandate any particular naming structure. It does contain suggested naming structures which are based on geographic and national regions, however there is not currently an established registration infrastructure in many regions which would be able to assign or ensure uniqueness of names.

The mechanism described in this document automatically provides an enterprise a distinguished name for each domain name it has obtained for use in the Internet. These distinguished names may be used to identify objects in an LDAP directory.

An example distinguished name represented in the LDAP string format [3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most significant component, closest to the root of the namespace, is written last.

This document does not define how to represent objects which do not have domain names. Nor does this document define the procedure to locate an enterprise's LDAP directory server, given their domain name. Such procedures may be defined in future RFCs.

3. Mapping Domain Names into Distinguished Names

This section defines a subset of the possible distinguished name structures for use in representing names allocated in the Internet Domain Name System. It is possible to algorithmically transform any Internet domain name into a distinguished name, and to convert these distinguished names back into the original domain names.

The algorithm for transforming a domain name is to begin with an empty distinguished name (DN) and then attach Relative Distinguished Names (RDNs) for each component of the domain, most significant (e.g. rightmost) first. Each of these RDNs is a single AttributeTypeAndValue, where the type is the attribute "DC" and the value is an IA5 string containing the domain name component.

Thus the domain name "CS.UCL.AC.UK" can be transformed into

        DC=CS,DC=UCL,DC=AC,DC=UK

Distinguished names in which there are one or more RDNs, all containing only the attribute type DC, can be mapped back into domain names. Note that this document does not define a domain name equivalence for any other distinguished names.

4. Attribute Type Definition

The DC (short for domainComponent) attribute type is defined as follows:

    ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

The value of this attribute is a string holding one component of a domain name. The encoding of IA5String for use in LDAP is simply the characters of the string itself. The equality matching rule is case insensitive, as is today's DNS.

5. Object Class Definitions

An object with a name derived from its domain name using the algorithm of section 3 is represented as an entry in the directory. The "DC" attribute is present in the entry and used as the RDN.

An attribute can only be present in an entry held by an LDAP server when that attribute is permitted by the entry's object class.

This section defines two object classes. The first, dcObject, is intended to be used in entries for which there is an appropriate structural object class. For example, if the domain represents a particular organization, the entry would have as its structural object class 'organization', and the 'dcObject' class would be an auxiliary class. The second, domain, is a structural object class used for entries in which no other information is being stored. The domain object class is typically used for entries that are placeholders or whose domains do not correspond to real-world entities.

5.1 The dcObject object class

The dcObject object class permits the dc attribute to be present in an entry. This object class is defined as auxiliary, as it would typically be used in conjunction with an existing structural object class, such as organization, organizationalUnit or locality.

The following object class, along with the dc attribute, can be added to any entry.

   ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )

An example entry would be:

   dn: dc=critical-angle,dc=com
   objectClass: top
   objectClass: organization
   objectClass: dcObject
   dc: critical-angle
   o: Critical Angle Inc.

5.2 The domain object class

If the entry does not correspond to an organization, organizational unit or other type of object for which an object class has been defined, then the "domain" object class can be used. The "domain" object class requires that the "DC" attribute be present, and permits several other attributes to be present in the entry.

The entry will have as its structural object class the "domain" object class.

( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
 MUST dc
 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
 x121Address $ registeredAddress $ destinationIndicator $
 preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
 telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
 street $ postOfficeBox $ postalCode $ postalAddress $
 physicalDeliveryOfficeName $ st $ l $ description $ o $
 associatedName ) )

The optional attributes of the domain class are used for describing the object represented by this domain, and may also be useful when searching. These attributes are already defined for use with LDAP [4].

An example entry would be:

   dn: dc=tcp,dc=critical-angle,dc=com
   objectClass: top
   objectClass: domain
   dc: tcp
   description: a placeholder entry used with SRV records

The DC attribute is used for naming entries of the domain class, and this can be represented in X.500 servers by the following name form rule.

    ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )

6. References (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "References."

7. Security Considerations

This memo describes how attributes of objects may be discovered and retrieved. Servers should ensure that an appropriate security policy is maintained.

An enterprise is not restricted in the information which it may store in DNS or LDAP servers. A client which contacts an untrusted server may have incorrect or misleading information returned (e.g. an organization's server may claim to hold naming contexts representing domain names which have not been delegated to that organization).

8. Authors' Addresses (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Author's Address."

9. Full Copyright Statement (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Full Copyright Statement."

References

Authors' Addresses

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.