RFC 2247

Using Domains in LDAP/X.500 Distinguished Names 🎀

okay bestie, this is RFC 2247 💖 It's a Standards Track doc, so it's a real spec that people build stuff against ✨

• Network Working Group
• Request for Comments: 2247
• Category: Standards Track
• Date: January 1998
• Authors: S. Kille (Isode Ltd.), M. Wahl (Critical Angle Inc.), A. Grimstad (AT&T), R. Huber (AT&T), S. Sataluri (AT&T)
• Obsoletes / Updates: none listed in the header, so this one doesn't obsolete or update anything 🙈

---

Status of this Memo 📋

this is an Internet standards track protocol for the whole Internet community, and they're literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright Notice 🦋

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

1. Abstract ✨

LDAP (the Lightweight Directory Access Protocol) uses X.500-compatible distinguished names [3] to give every entry a unique identity 🔑

This doc defines an algorithm for turning a name registered with the Internet Domain Name Service [2] into an LDAP distinguished name. It's giving translation layer energy 💅

2. Background 🌸

okay so the Domain (Nameserver) System, aka DNS, is a hierarchical labeling system. A name is an ordered set of components, and each one is a short string. An example with two components is CRITICAL-ANGLE.COM 💖

LDAP directories have a more general hierarchical naming framework. The big difference is that every component of a distinguished name has an explicit attribute type indication. Main character energy 👑

X.500 doesn't mandate any particular naming structure. It does suggest structures based on geographic and national regions. The catch is that there isn't an established registration infrastructure in many regions that could assign names or make sure they're unique 🙃

The mechanism in this doc automatically gives an enterprise a distinguished name for each domain name it has obtained for use on the Internet. Those distinguished names can be used to identify objects in an LDAP directory 🧚

An example distinguished name in the LDAP string format [3] is DC=CRITICAL-ANGLE,DC=COM. Just like with a domain name, the most significant component (the one closest to the root of the namespace) is written last ✨

Things this doc does not cover: representing objects that don't have domain names, and the procedure for locating an enterprise's LDAP directory server from its domain name. Those 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 representing names allocated in the Internet Domain Name System. It's possible to algorithmically transform any Internet domain name into a distinguished name, and to convert those distinguished names back into the original domain names 🦄

The transform starts with an empty distinguished name (DN). Then you attach Relative Distinguished Names (RDNs) for each component of the domain, most significant (e.g. rightmost) first. Each RDN is a single AttributeTypeAndValue, where the type is the attribute "DC" and the value is an IA5 string containing that domain name component 💅

So "CS.UCL.AC.UK" becomes:

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

Distinguished names with 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 like this:

    ( 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 is a string holding one component of a domain name. For LDAP, the IA5String encoding 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 whose name is derived from its domain name using the algorithm from section 3 is represented as an entry in the directory. The "DC" attribute is present in that entry and used as the RDN 🎀

An attribute can only show up in an entry held by an LDAP server when that attribute is permitted by the entry's object class. No sneaking attributes in 🙅‍♀️

This section defines two object classes:

• dcObject is for entries that already have an appropriate structural object class. For example, if the domain represents an organization, the entry's structural object class would be 'organization', and 'dcObject' would be an auxiliary class.
• domain is a structural object class for entries that don't store any other information. It's typically used for placeholder entries or for domains that don't 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. It's defined as auxiliary, since it would typically be used alongside an existing structural object class like 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 doesn't correspond to an organization, an organizational unit, or some other type of object that already has an object class defined, you can use the "domain" object class. The "domain" object class requires the "DC" attribute to be present, and it permits several other attributes too 💖

The entry will have the "domain" object class as its structural 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 describe the object this domain represents, and they can also be handy 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. X.500 servers can represent this with 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 one is serious, bestie 😭 This memo describes how attributes of objects may be discovered and retrieved. Servers should make sure an appropriate security policy is maintained.

An enterprise isn't restricted in the information it may store in DNS or LDAP servers. A client that contacts an untrusted server may get incorrect or misleading information back. For example, an organization's server may claim to hold naming contexts for domain names that have never been delegated to that organization. Don't trust a server just because it sounds confident 💀

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 handed out to others. Derivative works that comment on or explain it, or help with implementing it, may be written, copied, published and distributed, in whole or in part, with no restriction of any kind. The one condition is that the copyright notice and this paragraph stay on every copy and derivative work 🎀 The document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, and translating it into languages other than English.

The permissions above are perpetual and won't 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.