Domains in LDAP DNs: Using Domains in LDAP/X.500 Distinguished Names
How to turn a DNS domain name into an LDAP distinguished name, one DC component at a time.
Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, DOI 10.17487/RFC2247, January 1998, <https://www.rfc-editor.org/info/rfc2247>.
@misc{rfc2247,
series = {Request for Comments},
number = 2247,
howpublished = {RFC 2247},
publisher = {RFC Editor},
doi = {10.17487/RFC2247},
url = {https://www.rfc-editor.org/info/rfc2247},
author = {S. Kille and M. Wahl and A. Grimstad and R. Huber and S. Sataluri},
title = {{Using Domains in LDAP/X.500 Distinguished Names}},
pagetotal = 7,
year = 1998,
month = jan,
} RFC text
Contents
Network Working Group S. Kille
Request for Comments: 2247 Isode Ltd.
Category: Standards Track M. Wahl
Critical Angle Inc.
A. Grimstad
AT&T
R. Huber
AT&T
S. Sataluri
AT&T
January 1998
Using Domains in LDAP/X.500 Distinguished Names
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.
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
[1] The Directory: Selected Attribute Types. ITU-T Recommendation
X.520, 1993.
[2] Mockapetris, P., " Domain Names - Concepts and Facilities,"
STD 13, RFC 1034, November 1987.
[3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol
(v3): UTF-8 String Representation of Distinguished Names", RFC
2253, December 1997.
[4] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAP", RFC 2256, December 1997.
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
Steve Kille
Isode Ltd.
The Dome
The Square
Richmond, Surrey
TW9 1DT
England
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
Mark Wahl
Critical Angle Inc.
4815 W. Braker Lane #502-385
Austin, TX 78759
USA
Phone: (1) 512 372 3160
EMail: M.Wahl@critical-angle.com
Al Grimstad
AT&T
Room 1C-429, 101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
EMail: alg@att.com
Rick Huber
AT&T
Room 1B-433, 101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
EMail: rvh@att.com
Sri Sataluri
AT&T
Room 4G-202, 101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
EMail: sri@att.com
9. 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 assigns.
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.
AI ELI5
On this page
§2Why Domain Names Can Name Directory Entries
The Lightweight Directory Access Protocol (LDAP) identifies each entry by an X.500-compatible distinguished name. The Domain Name System (RFC 1034) also labels things hierarchically, as an ordered set of short string components, such as CRITICAL-ANGLE.COM.
A key difference is that every component of a distinguished name carries an explicit attribute type, while a domain name component does not. X.500 itself does not require any particular naming structure. It suggests structures based on geographic and national regions, but the RFC notes that in many regions there was no established registration infrastructure that could assign names or ensure they were unique.
The mechanism in this memo gives an enterprise a distinguished name for each domain name it has already obtained for use in the Internet. As in a domain name, the most significant component, closest to the root, is written last: DC=CRITICAL-ANGLE,DC=COM.
The memo does not say how to name objects that have no domain name, and does not say how to find an enterprise's LDAP server from its domain name. It leaves such procedures to possible future RFCs.
Everyone who owns a web-style name already has a unique name. This memo reuses that name so a directory does not need a new naming system.
§3Mapping a Domain Name to a Distinguished Name
The algorithm starts with an empty distinguished name and attaches one relative distinguished name (RDN) for each component of the domain, most significant (rightmost) first. Each RDN is a single attribute type and value pair. The type is the attribute DC, and the value is an IA5 string holding the domain name component.
The mapping works in both directions. Any Internet domain name can be transformed into a distinguished name, and a distinguished name made of one or more RDNs that all contain only the attribute type DC can be mapped back to a domain name.
The memo defines no domain name equivalence for any other kind of distinguished name.
You read the web name from right to left and write each piece after a label that says DC. You can undo it just as easily.
CS.UCL.AC.UK
--> DC=CS,DC=UCL,DC=AC,DC=UK§4The dc Attribute Type
The DC attribute (short for domainComponent) is defined with the object identifier 0.9.2342.19200300.100.1.25 and the name dc. It uses the IA5 string syntax, case-insensitive equality and substring matching rules, and it is SINGLE-VALUE.
The value is a string holding one component of a domain name. In LDAP the encoding of an IA5String is simply the characters of the string. The equality rule ignores case, matching the case-insensitive behavior of DNS at the time.
The label DC is a labeled slot that holds exactly one piece of a web name, and it does not care about capital letters.
§5The dcObject and domain Object Classes
An object whose name is derived from its domain name using the algorithm above is an entry in the directory, with the DC attribute present and used as its RDN. An LDAP server only holds an attribute in an entry when the entry's object class permits it, so the memo defines two object classes.
dcObject is an auxiliary class (object identifier 1.3.6.1.4.1.1466.344) that requires dc. It is meant to be added to an entry that already has a suitable structural class, such as organization, organizationalUnit or locality.
domain is a structural class (object identifier 0.9.2342.19200300.100.4.13) that also requires dc. It is for entries where no other information is stored, typically placeholders or domains that do not correspond to real-world entities. It permits a list of optional descriptive attributes, including description, telephoneNumber and postalAddress, which are already defined for LDAP in RFC 2256.
For X.500 servers, the memo also gives a name form rule, domainNameForm, that lets the domain class be named by dc.
An entry can wear a small badge saying it has a web-name piece (dcObject), or it can be a plain placeholder card (domain) when there is nothing else to say.
§5.1Example Entries
For an organization, the entry has organization as its structural class and dcObject as an auxiliary class. The RFC's example is the entry dc=critical-angle,dc=com with o: Critical Angle Inc..
For a placeholder, the RFC's example is dc=tcp,dc=critical-angle,dc=com with the structural class domain and the description a placeholder entry used with SRV records.
A company gets a card with its name on it. A placeholder gets a plain card that just says what it is for.
§7Security Considerations
The memo says it describes how attributes of objects may be discovered and retrieved, so servers should maintain an appropriate security policy.
It also warns that an enterprise is not restricted in what it may store in DNS or LDAP servers. A client that contacts an untrusted server may be given incorrect or misleading information. For example, an organization's server might claim to hold naming contexts for domain names that were never delegated to that organization.
Just because a directory says it holds a name does not make it true, so be careful which servers you believe.