RFC 1279

X.500 and Domains

📅 published November 1991, from ietf

RFC 1279: X.500 and Domains 🎀

  • RFC: 1279 🧾
  • Title: X.500 and Domains 💖
  • Author: S.E. Hardcastle-Kille, University College London ✍️
  • Group: Network Working Group 🧚
  • Status: Experimental Protocol (more on that below) 🔬
  • Date: November 1991 📅
  • Obsoletes / Updates: the title block doesn't list anything here, so this one stands on its own ✨

Status of This Memo 🌈

This memo defines an Experimental Protocol for the Internet community, and everyone is literally invited to discuss it and suggest improvements 💬. For the standardization state and status of this protocol, check the current edition of "IAB Official Protocol Standards" 📋. Distribution of this memo is unlimited 🦋.

Abstract 💜

So this RFC looks at X.500 next to Internet and UK Domains 👀. The main focus is a basic model of X.500 that gives you a higher-level, more descriptive naming structure (it's so emphasised, ngl 💅). It also maps domains onto X.500, which unlocks a bunch of new management and user facilities beyond what we have right now 🔥. The proposal is an experimental new way to access and manage domain info on the Internet and in the UK Academic Community 🎓. To be super clear though: there is no current plan to replace DNS with this 🙅.

1. The Domain Name System 🌸

The Domain (Nameserver) System, aka DNS, is a hierarchical way to label resources 🏷️ [Moc87a] [Moc87b] [Lar83]. Some example domains are:

MIT.EDU
VENERA.ISI.EDU
CS.UCL.AC.UK

Entries usually have a single name, but you may get pointers to entries (not subtrees) through CNAME records 🔗. Information, aka resource records, is attached to each entry 📦. Name components are typically kept shortish, like CS 💅.

RFC 822 mailbox names are closely related [Cro82] 💌. For example:

<S.Kille@CS.UCL.AC.UK>

The local-part of the RFC 822 mailbox can be considered as one level lower in the domain hierarchy 🧠.

2. X.500 🧚

The OSI Directory, usually called X.500, gives us a super general naming framework [CCI88] ✨. A basic use of X.500 is Organisationally Structured Names, and there's a schema for that defined inside the standard 📚. Name components usually have longish values, which is a whole different vibe from DNS 😌. Here's an example directory name in tabular form:

           Country              GB
           Organisation         University College London
           Organisational Unit  Computer Science
           Common Name          Stephen E. Hardcastle-Kille

It can also be written in the User Friendly Name notation defined in [HK91]. This syntax is what we'll use for names for the rest of this doc 💖:

    Stephen E. Hardcastle-Kille, Computer Science,
    University College London, GB

This type of structure is termed organisational X.500. It's a subset of the general capabilities 🫶.

3. The basic model 🦋

X.500 has as much relation to the DNS as DNS has to ARP. Paul Mockapetris

Honestly, that's the position adopted here 💯. The basic model is that organisational X.500 provides a layer of naming at the level above domain names. Those structured names can be considered to form a naming layer sitting above domain names 🪜. There are the following key differences:

  • Organisational X.500 tends to use longer and more descriptive values 📏
  • The organisational X.500 DIT is slightly shallower than the DNS tree 🌳
  • X.500 has a richer information framework than DNS ✨

These differences suggest that the following should NOT be done 🙅:

  • Represent X.500 information in the DNS
  • Have an algorithmic mapping between the two hierarchies

This note proposes representing DNS information in the DIT, with a loose coupling between the two trees 🤝. It does not propose equivalencing X.500 and Domains 🚫.

The proposed model is shown in Figure 1 🖼️. Both an organisational and a domain structure get represented in the DIT, using appropriate object classes and attribute types 🧩. A weak linkage between the two parts of the tree is provided by special attributes. Here the linkage is 1:1, but it may be more complex for some parts of the organisational DIT or domain namespace. The linkage is achieved with special attributes, as described in Section 11 🔗.

                  j jZ Z

               j j       ZZ
            jj              Z Z
        jjj                    ZZ

Domain Component=UK          Country Name=GB
                                |
                                |
                                |
Domain Component=AC       Organisation Name=Univeristy College London

                        *        BB
              ss                  BBB

Domain Component=UCL      Org Unit Name=Computer Science
      |                *

      ||     ss
Domain Component=CS       Common Name=Steve Kille

     |                  *
     |        ss

Domain Component=S.Kille
                    Figure 1:  Example X.500 tree

4. Representing Domains in X.500 🌷

Domains sit one level below the X.500 names from the last section 🪴. X.500 can also be used in other ways, though, and there are real benefits to representing Domains in X.500. This is very different from equivalencing, because no attempt is made to represent X.500 information within the domain scheme 🙌. There are the following potential advantages:

  • Domain Services (DNS and NRS) could be replaced with an OSI service (some may not view this as an advantage). This is particularly attractive for OSI services, where use of a non-OSI directory may be inappropriate. 🛸
  • For Internet sites, access to domain information (beyond MX records) could be provided for systems registered remotely. For UK Academic Community sites, access to domain information for domains not registered in the NRS could be given. For sites neither on the Internet nor in the UK Academic Community there will usually be even more of an advantage, as they usually have very limited information on domains. 🌍
  • Assuming that information is downloaded from an X.500 database into a DNS or NRS system, the remote management facilities of X.500 could be used. This is possible because of the extra security features of X.500. 🔐
Note: For initial work, the converse situation of information being mastered in Domain Databases and uploaded into the X.500 DIT is more likely.
  • User access to the domain data, and in particular searching, could be provided. This would let users browse the domain namespace and determine information associated with the domains. 🔍
  • The X.500 framework would allow additional management information to be stored, and to relate the domain names into a more complex structure of information. For example, this might allow the managers of a system to be identified, along with information on how to contact the manager. 📇
  • A facility to map an RFC 822 mailbox into a Directory Name (and thus access other user information on the basis of this key) could be provided. This may be useful for the user to determine information about a message originator. 💌
  • This technique may be useful to facilitate introduction of security, as it will enable certificates to be associated with domains and mailboxes. This may be very useful for the privacy enhanced mail work [Lin89]. 🪪

5. Representing Domain Names 🎀

A new attribute syntax is defined 🆕:

CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
    IA5String
    MATCHES FOR EQUALITY SUBSTRINGS ORDERING

A new attribute and two new object classes are defined too 💅:

DomainComponent ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax
    SINGLE VALUE

Domain OBJECT-CLASS
    SUBCLASS OF top
    MUST CONTAIN -DomainComponent"
    MAY CONTAIN -AssociatedName,
        organizationName,
        organizationalAttributeSet,
        manager"

RFC822Mailbox OBJECT-CLASS
    SUBCLASS OF Domain
    MAY CONTAIN -commonName,
       surname,
       description,
       telephoneNumber,
       postalAttributeSet,
       telecommunicationAttributeSet "

Note that the attribute AssociatedName is defined in Section 11. The manager attribute is defined in the COSINE and Internet naming architecture [BHK91] 🏛️. It lets a manager be associated with the domain, which is useful where the manager of the domain is different to the manager of the object defined by the AssociatedName 💼. This allows any domain to be represented in an X.500 hierarchy 🌈. The local part of an RFC 822 mailbox is treated as a special sort of domain component, so these can be represented in the tree as a natural extension of the hierarchy 🧩.

For example, consider the mailbox S.Kille@cs.ucl.ac.uk. This leads 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=UK

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 useful to define (e.g., Machine Type, Owner, Location etc.) 🖥️. This allows some information which truly belongs to the domain to be represented there. It also allows further information to be associated with the domain/mailbox when there isn't a relevant part of the organisationally structured DIT to point at. When there is an associated part of the DIT, information from that part of the DIT should not be duplicated in the domain entry 🙅.

6. Wildcards 🃏

Wildcards are supported by having "*" as a special domain component name ⭐. If there is a need to emulate wildcard matching using the directory, the following algorithm must be employed 🧮. For example, the wildcard entry for *.*.PODUNK.COM would be represented in the DIT as:

    DomainComponent=*, DomainComponent=*,
    DomainComponent=MIT, DomainComponent=COM

If A.B.PODUNK.COM is looked up in the directory, the query will fail and indicate that two components are matched. A substitution should be made, and *.*.PODUNK.COM looked up explicitly to identify the associated information 🔍.

7. DNS Information 📜

DNS information can be associated with an entry in the DIT 💾. It is important that this is done in a manner which is exactly equivalent to the information stored in the DNS 🎯. This allows the DIT to have information loaded from the DNS, or vice versa 🔄. All (authoritative) records associated with a domain will be stored in the DIT. There is no attempt made by the OSI Directory to emulate DNS caching or TTL handling 🙅. It is assumed that the master entries are maintained by use of DNS Zone Transfer (or equivalent), and that they can be treated as authoritative 👑. There is a need to define an attribute syntax which represents a DNS record, and that's what lets DNS records get stored in the DIT 🧃. There are three possible encodings of this record:

okay so there are three ways we could store this record, and one of them is clearly the winner 💅

  • ASN.1 Encoded 🎀 This is the most natural approach in terms of X.500. ngl, it would make every user of this service handle the new syntax, which is kinda awkward. There's also a problem with handling the resource format in a general manner.
  • DNS Binary Encoded 🌸 This uses the formally defined record syntax. It would be super convenient for DNS related software to get at the data, but it would be an awkward encoding for independent X.500 DUAs.
  • Text encoded 🦋 This uses a text encoding derived from the DNS specifications. It's straightforward to map onto the 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 uses the definitions of section 5.1 of RFC 1035. It looks like this:

<rr> [ ";" <comment> ]

Three examples of this (for domain C.ISI.EDU) might be:

500 A   10.1.0.52                        ; Basic address record
IN 600 MX  10 VENERA.ISI.EDU.                ; MX record
600 IN MX  10 VENERA.ISI.EDU.                ; MX record - other order

Note that:

  • The class and TTL may be in either order (following RFC 1035) 🌈
  • The class defaults to IN
  • Domains must always be fully specified (i.e., master file abbreviate rules are not used).
  • The TTL for a record must always be present (this saves looking at the parent entry to find the SOA record).
  • Records (e.g., SOA) may be multiline. Lines should be separated with the two IA5 characters <CR><LF>.

CNAME records are mapped symmetrically onto Directory Aliases. 🫶

This is now defined in terms of attribute and object class definitions. A single record type is defined, as opposed to one attribute type per record type. This means the definition doesn't need extending when new DNS Record types are defined. However, there is some loss of efficiency if only a single record type is needed, as filtering must be done by the DUA. 🙈

Similarly, no distinction is made on the basis of DNS class. This means that if there are two class hierarchies, they must be represented in a single DIT, and information for different classes must be separated by DUA filtering. 💜

DNSDomain OBJECT-CLASS
    SUBCLASS OF Domain
    MAY CONTAIN -
        DNSRecord "

DNSRecord ATTRIBUTE
    ATTRIBUTE-SYNTAX IA5String
    MATCHES FOR EQUALITY

Lookup of a domain is achieved by translating it algorithmically to a Distinguished Name (DN), and reading back the attributes you want. This information can be managed and searched in a straightforward fashion. 👑

The information may also be downloaded into a DNS database. This should be done by use of zone transfer. A tool to perform zone transfer (in both directions) between a DNS Server and a DSA would seem to be both straightforward and useful. It would be a key tool in a transition to X.500 based management of the DNS, and it would also let a large part of the DNS namespace be rapidly made available in an X.500 pilot. 🔥

Inverse information can be derived by the usual IN-ADDR domain, which will be represented in the same manner in the DIT. 🧚

8. NRS Information 🌸

Information associated with the UK NRS (Name Registration Scheme) can be handled in a similar manner [Lar83]. This is being developed in a separate document by Alan Turland. 💅

9. Application Entity Titles 🦋

In many cases, Application entities will be closely related to domains. In some cases, it may be appropriate to give Application Entities names which are related to the DNS part of the DIT. In this case, the Domain Name will be used to identify the application, and the entry for the domain will also be of object class Application Process. The children of this entry will identify Application Entities, with names such as “FTAM Service”. ✨

10. Networks 🌈

It's clearly useful to represent networks within the DIT. A short note on how to do this is given here. It is likely that this specification will later be evolved in a separate document. This defines an Object Class for a general network, and shows how it can be subclassed to define technology specific networks. 🎀

Network OBJECT-CLASS
    SUBCLASS OF TOP
    MAY CONTAIN -
      Manager,
      Locality,
      Description "

IPNetwork OBJECT-CLASS
    SUBCLASS OF Network
    MUST CONTAIN -AssociatedDomain"

The Network Object Class lets networks be defined, and useful attributes to be associated with the entry. A network will often appear in more than one organisational structure, and this linkage should be achieved by use of aliases. This grouping can make networks easier to manage. 🌸

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 be represented in the Object Class. For example, a network might have the (user friendly) name:

UCL-Ethernet, University College London, GB

This would have associated domains 0.0.40.128.IN-ADDR.ARPA and UCL-ETHERNET.UCL.AC.UK. These would both have the analogous DIT representations. For example:

DomainComponent=0, DomainComponent=0, DomainComponent=40,
DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=ARPA

11. Linkage 🔗

There's a need to associate the organisational X.500 DIT and the DNS tree. The objects represented are different (Domain ≠ Organisation; Person ≠ RFC 822 Mailbox). Therefore aliasing is not an appropriate linkage. However, in many cases there is a linkage which is rather stronger than that implied by the seeAlso attribute. Therefore, we define new attributes, which represent this stronger cross-linkage. The same mechanism can be used to link a domain with an Application Entity or an Application Process. 🍓

Links from the organisational X.500 DIT to the DNS tree are provided by a new attribute, which could be present in Organisation or Organisational Unit entries.

ObjectWithAssociatedDomain OBJECT-CLASS
  SUBCLASS OF top
  MUST CONTAIN -AssociatedDomain"

AssociatedDomain ATTRIBUTE
  WITH ATTRIBUTE-SYNTAX ia5StringSyntax

For example, the organisational entry:

University College London, GB

would have an attribute:

AssociatedDomain = UCL.AC.UK

Similarly, an RFC 822 mailbox attribute is used to link entries of Person Object Class to their associated DNS entry. This attribute is defined in the Cosine and Internet Naming Architecture [BHK91]. Conversely, there are pointers from the DNS represented tree into the organisational X.500 DIT:

AssociatedName ATTRIBUTE
  WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax

This attribute is associated with the Domain object class. 💖

This entry is used to provide linkage from the DNS X.500 Hierarchy into the organisational X.500 hierarchy. Where such entries do not exist, attributes in the DNS entry (such as phone number) may be used. It is recommended that information is not duplicated. The preferred setup is for the DNS attributes to be rather skeletal, with pointers into the organisational X.500 DIT. 🫶

For example, the domain UCL.AC.UK would be represented in the DIT as:

DomainComponent=UCL, DomainComponent=AC,
DomainComponent=UK

This entry would have in it an AssociatedName attribute with value:

University College London, GB

This example shows a simple case with 1:1 linkage. There are cases where a domain might be associated with multiple organisations, or an organisation with multiple domains. 🧚

12. Conclusions and proposals for evaluation 👑

Experiments should be undertaken to determine the practicality and utility of this scheme, in a pilot environment. A possible approach to this experimentation is described in Appendix A. Object Identifiers have been assigned for this purpose in the Cosine and Internet Naming Architecture [BHK91]. 🌈

References 🫶

[BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet X.500 schema. Request for Comments RFC 1274, Department of 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 text messages. Request for Comments 822, University of Delaware, August 1982.

[HK91] S.E. Hardcastle-Kille. Using the OSI directory to achieve user friendly naming. Request for Comments in preparation, Department of Computer Science, University College London, November 1991.

[Lar83] J. Larmouth. JNT name registration technical guide, April 1983.

[Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail: Part 1 --- Message Encipherment and Authentication Procedures. Request for Comments 1113, Bolt, Beranek, and Newman, August 1989.

[Moc87a] P. Mockapetris. Domain names - concepts and facilities. Request for Comments RFC 1034, USC/Information Sciences Institute, November 1987.

[Moc87b] P. Mockapetris. Domain names - implementation and specification. Request for Comments RFC 1035, USC/Information Sciences Institute, November 1987.

[Moc89] P. Mockapetris. DNS encoding of network names and other types. Request for Comments RFC 1101, USC/Information Sciences Institute, April 1989.

13. Security Considerations 💀

This memo does not directly address security issues. However, due to the facilities of X.500, this proposal could lead to a more secure way to access and manage domain information. Ngl, that's a big deal, so treat it seriously 🔒

14. Author's Address 💜

Steve Hardcastle-Kille, Department of Computer Science, University College London, Gower Street, WC1E 6BT, England

Phone: +44-71-380-7294

EMail: S.Kille@CS.UCL.AC.UK

A. Possible Deployment Approach 🍓

This appendix notes a possible approach to deploying an experiment to evaluate this mechanism. The following components of a possible experiment are noted.

  1. User tool. This will take a domain or mailbox as input. It will be looked up in the DIT. This tool should be capable of:
    • Attempting to correct user input
    • Helping browsing
    • Looking up information associated with the domain (or mailbox) and associated name, in particular the manager (of both domain and associated name) and information on the manager (e.g., phone number and mailbox)
    • Supplying DNS records
    • Handling IN-ADDR.ARPA inverse lookups if supplied with an IP Address
    • Looking up networks
  2. A procedural library to allow user interfaces to make easy use of these facilities.
  3. Zone transfer tool. This will use the zone transfer protocol to transfer information between a DSA and Domain Nameserver. When writing to the DSA, attributes in an entry which are not DNS records should remain untouched.
  4. Linkage patching tool. When the organisational DIT is established, associated domain pointers are usually inserted. A tool can be written to search the DIT and insert the reverse pointers.
  5. DNS Manager Tool. This will allow user addition of additional information into the DNS part of the DIT. A standard DUA can probably be used for this.
  6. Mailbox download tool. This will allow download of local mailboxes, with pointers to the user entries.
  7. Emulation DNS Server 🪞, using the Directory as a database. Bestie, this server should keep a permanent connection to its local DSA 🫶. There's no OSI bind, so the response of this server can be at least as fast as a normal DNS server ⚡. There can be two variants, and they're both giving main character energy 💅:
    • (a) Using a local DSA as a local database but using DNS distributed operations.
    • (b) Do all lookups in the directory (using Directory Distributed Operations).

An initial experiment is straightforward 🌸. The Zone Transfer Tool (3) can download a large part of the DNS space into a single DSA. Ngl, there are some restrictions, because parts of the DNS hierarchy do not permit zone transfer 💀. You can repeat this to keep the information fresh 🔄. The linkage patching tool (4) can put in pointers to parts of the DIT 🧚. Then the user tool can be used, by all sites participating in the directory pilot, to look up domain information 🔍. This lets everyone see how useful the approach actually is 👑. The manager tool (5) lets extra information get added to parts of the DNS tree 🎀.

The next stage is to distribute the DNS part of the DIT over multiple DSAs using Directory distribution techniques 🦋. The emulation DNS Server (7) is going to be super useful here, because it makes sure the Directory is offering equivalent functionality. It can also be used 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 entirely transparent to the DNS user 🌈. Management benefits can then be examined 💜.

Hardcastle-Kille Page 15

📦 where this page comes from