mail us  |  mail this page

contact us
training  | 
tech stuff  | 

Appendix A - LDAP: Root Name Angst

The top entry in a LDAP DIT (Directory Information Tree) is, in the LDAP world, variously referred to as the root, the base or the suffix depending on the document, its author, day of the week or some other variable unknown to us.

The term Root DSE defines a kinda super root that contains all the DITs supported by the LDAP server as well as operational objects.

In the documentation the subject of the root (a.k.a. suffix or base) is treated in one of two ways. It's assumed to be an automagic thing that is the beyond the scope of mere mortals to understand and is treated in a ritualistic way as if it had been handed down from one generation to another and certainly no attempt is made to explain it. Conversely the other camp handles it at extreme length usually accompanied by much wailing and gnashing of teeth and incantations to the twin gods of the ITU and IETF.

Our advice - unless you need to make the directory globally available define the root as an ou with a name of gobbledegook and spend no more time on the subject. Defining a simple root or suffix.

Now for the serious stuff.

The angst stems for the original and laudable goal of X.500 - apparently continued by the IETF - to have a global hierarchy of directories not dissimilar to the DNS system.

In this context the root (a.k.a. suffix, base), which would be exposed globally plays a significant role - it should be unique. Back to our advice, unless you will expose the directory at some stage in the future - forget it - give it whatever name you want - meaningful or humourous as you desire. Defining a simple root or suffix.

If you have, or may in the future have, global ambitions then read on.

X.500 chose a root standard based on ou=organisation name,c=country code, such as ou=Example Inc., c=us, for the reason - perhaps - it seemed like a good idea at the time or it was Thursday. More on ou definitions. Defining an X.500 format root or suffix.

The IETF (through the INFORMATIONAL only status RFC 2247) chose to use a domain name structure, for instance dc=example, dc=com. Partly because it was based on DNS domain names which are globally unique and partly on a somewhat more specious argument that says - given either a DNS SRV record or an LDAP server name - you can discover the suffix. Thus if the LDAP server name is (obtained directly or via an SRV RR) then it would be resonable to assume that the suffix would be dc=example,dc=com. Not terribly convincing. Defining an RFC 2247 format root or suffix.

And if you don't have a domain name - well that's just too bad. If you have multiple domain names which one should you choose - it does not matter (you can even use all of them) since every domain name is unique.

In summary choose the one you are most comfortable with. If you really want to you can have multiple DITs in the same server so you could define both formats and use referral between them.

In the diagram below - all three are valid root entries. Two of which could be globally unique - one certainly is not. Phew!

DNs and RDNs - Tree Hierarchy

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.


tech info
guides home
1 objectives
big picture
2 concepts
3 ldap objects
4 install ldap
5 samples
6 configuration
7 replica & refer
8 ldif
9 protocol
10 ldap api
11 howtos
12 trouble
13 performance
14 ldap tools
15 security
notes & info
ldap resources
rfc's & x.500
ldap objects
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox




share page via facebook tweet this page


email us Send to a friend feature print this page Decrease font size Increase font size Display full width page



Debian Linux


GNU-Free SW Foundation


Open Source Initiative
Creative Commons


Ibiblio - Library
Open Book Project
Open Directory


CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2015 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
Hosted by
web-master at zytrax
Page modified: October 21 2015.