7 Network Working Group S.E. Hardcastle-Kille
8 Requests for Comments 1279 University College London
28 This memo defines an Experimental Protocol for the Internet
29 community. Discussion and suggestions for improvement are
30 requested. Please refer to the current edition of the ``IAB
31 Official Protocol Standards'' for the standardization state and
32 status of this protocol. Distribution of this memo is unlimited.
35 This RFCconsiders X.500 in relation to Internet and UK Domains.
36 A basic model of X.500 providing a higher level and more
37 descriptive naming structure is emphasised. In addition, a
38 mapping of domains onto X.500 is proposed, which gives a range of
39 new management and user facilities over and above those currently
40 available. This specification proposes an experimental new
41 mechanism to access and manage domain information on the Internet
42 and in the UK Academic Community. There is no current intention
43 to provide an operational replacement for DNS.
48 RFC 1279 X.500 and Domains November 1991
51 1 The Domain Name System
53 The Domain (Nameserver) System (DNS) provides a hierarchical resource
54 labelling system [Moc87a] [Moc87b] [Lar83]. Example domains are:
61 Entries usually have a single name, although pointers to entries (not
62 subtrees) may be provided by CNAME records. Information (resource
63 records) is associated with each entry. Name components are typically
64 chosen to be shortish (e.g., ``CS'').
65 RFC 822 mailbox names are closely related [Cro82]. For example:
68 <S.Kille@CS.UCL.AC.UK>
70 The local-part of the RFC 822 mailbox can be considered as one level
71 lower in the domain hierarchy.
76 The OSI Directory, usually known as X.500, provides a very general
77 naming framework [CCI88]. A basic usage of X.500 is to provide
78 Organisationally Structured Names. A Schema for this is defined
79 within the standard. Name components will typically have longish
80 values. This is an example directory name represented in Tabular
85 Organisation University College London
86 Organisational Unit Computer Science
87 Common Name Stephen E. Hardcastle-Kille
89 This can also be written in the ``User Friendly Name'' notation
90 defined in [HK91]. This syntax is used for names in the rest of this
94 Stephen E. Hardcastle-Kille, Computer Science,
96 Hardcastle-Kille Page 1
101 RFC 1279 X.500 and Domains November 1991
104 University College London, GB
106 This type of structure is termed ``organisational X.500''. This is a
107 subset of the general capabilities.
112 X.500 has as much relation to the DNS as DNS has to ARP. Paul
116 This is, essentially, the position adopted here. The basic model is
117 that organisational X.500 is providing a layer of naming at the level
118 above domain names. These structured names can be considered to form
119 a naming layer above domain names. There are the following key
122 o Organisational X.500 tends to use longer and more descriptive
125 o The organisational X.500 DIT is slightly shallower than the DNS
128 o X.500 has a richer information framework than DNS
131 These differences suggest that the following should NOT be done:
133 o Represent X.500 information in the DNS
135 o Have an algorithmic mapping between the two hierarchies
137 This note proposes to represent DNS information in the DIT, and to
138 provide for a loose coupling between the two trees. This note does
139 not propose an equivalencing of X.500 and Domains.
141 The proposed model is illustrated in Figure 1. Both an organisational
142 and domain structure is represented in the DIT, by use of appropriate
143 object classes and attribute types. A weak linkage is provided
144 between the two parts of the tree by use of special attributes. Here,
145 the linkage is 1:1, but it may be more complex for some parts of the
146 organisational DIT or domain namespace. The linkage is achieved by
147 use of special attributes, as described in Section 11.
149 Hardcastle-Kille Page 2
154 RFC 1279 X.500 and Domains November 1991
171 Domain Component=UK Country Name=GB
175 Domain Component=AC Organisation Name=Univeristy College London
180 Domain Component=UCL Org Unit Name=Computer Science
184 Domain Component=CS Common Name=Steve Kille
189 Domain Component=S.Kille
190 Figure 1: Example X.500 tree
202 Hardcastle-Kille Page 3
207 RFC 1279 X.500 and Domains November 1991
210 4 Representing Domains in X.500
212 Domains are at the level below X.500 names of the form illustrated in
213 the previous section. However, it is also possible to use X.500 in
214 other ways. In particular, there are benefits from representing
215 Domains in X.500. Note that this is very different to equivalencing,
216 as no attempt is made to represent X.500 information within the domain
217 scheme. There are the following potential advantages:
220 o Domain Services (DNS and NRS) could be replaced with an OSI
221 service (some may not view this as an advantage). This is
222 particularly attractive for OSI services, where use of a non-OSI
223 directory may be inappropriate.
225 o For Internet sites, access to domain information (beyond MX
226 records) could be provided for systems registered remotely. For
227 UK Academic Community sites, access to domain information for
228 domains not registered in the NRS could be given. For sites
229 neither on the Internet nor in the UK Academic Community there
230 will usually be even more of an advantage, as they usually have
231 very limited information on domains.
233 o Assuming that information is downloaded from an X.500 database
234 into a DNS or NRS system, the remote management facilities of
235 X.500 could be used. This is possible because of the extra
236 security features of X.500.
238 Note: For initial work, the converse situation of information
239 being mastered in Domain Databases and uploaded into the X.500
242 o User access to the domain data, and in particular searching, could
243 be provided. This would allow users to browse the domain
244 namespace, and to determine information associated with the
247 o The X.500 framework would allow for additional management
248 information to be stored, and to relate the domain names into a
249 more complex structure of information. For example, this might
250 allow for the managers of a system to be identified, and
251 information on how to contact the manager.
255 Hardcastle-Kille Page 4
260 RFC 1279 X.500 and Domains November 1991
263 o A facility to map RFC 822 mailbox into a Directory Name (and thus
264 access other user information on the basis of this key) could be
265 provided. This may be useful for the user to determine
266 information about a message originator.
268 o This technique may be useful to facilitate introduction of
269 security, as it will enable certificates to be associated with
270 domains and mailboxes. This may be very useful for the privacy
271 enchanced mail work [Lin89].
274 5 Representing Domain Names
276 A new attribute syntax is defined:
279 CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
281 MATCHES FOR EQUALITY SUBSTRINGS ORDERING
284 A new attribute and two new object classes are defined:
287 DomainComponent ATTRIBUTE
288 WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax
293 MUST CONTAIN -DomainComponent"
294 MAY CONTAIN -AssociatedName,
296 organizationalAttributeSet,
299 RFC822Mailbox OBJECT-CLASS
301 MAY CONTAIN -commonName,
306 telecommunicationAttributeSet "
308 Hardcastle-Kille Page 5
313 RFC 1279 X.500 and Domains November 1991
316 Note that the attribute AssociatedName is defined in Section 11. The
317 manager attribute is defined in the COSINE and Internet naming
318 architecture [BHK91]. It allows a manager to be associated with the
319 domain, which is useful where the manager of the domain is different
320 to the manager of the object defined by the AssociatedName. This will
321 allow any domain to be represented in an X.500 hierarchy. The local
322 part of an RFC 822 mailbox is treated as a special sort of domain
323 component, and so these can be represented in the tree as a natural
324 extension of the hierarchy.
325 For example, consider the mailbox S.Kille@cs.ucl.ac.uk. This will
326 lead to the following structure in the DIT:
328 ___________________________________________
329 |_Object_Class__|RDN_Type________|RDN_Value_|
330 | Domain |DomainComponent |UK |
331 | Domain |DomainComponent |AC |
332 | Domain |DomainComponent |UCL |
333 | Domain |DomainComponent |CS |
334 |_RFC822Mailbox_|DomainComponent_|S.Kille__ |
336 This can be represented in User Friendly Name format as:
339 DomainComponent=S.Kille, DomainComponent=CS, DomainComponent=UCL,
340 DomainComponent=AC, DomainComponent=UK
342 Note that the RFC822Mailbox Object Class is a subclass of Domain.
343 Some attributes are allowed to be associated with these objects.
344 There may be other additional management attributes which it is useful
345 to define (e.g., Machine Type, Owner, Location etc.). This allows
346 some information which truly belongs to the domain to be represented
347 there. It also allows for further information to be associated with
348 the domain/mailbox when there is not a relevant part of the
349 organisationally structure DIT to be pointed at. When there is an
350 associated part of the DIT, information from that part of the DIT
351 should not be duplicated in the domain entry.
357 Wildcards are supported by having "*" as a special domain component
358 name. If there is a need to emulate wildcard matching using the
359 directory, the following algorithm must be employed. For example, the
361 Hardcastle-Kille Page 6
366 RFC 1279 X.500 and Domains November 1991
369 wildcard entry for *.*.PODUNK.COM would be represented in the DIT as:
371 DomainComponent=*, DomainComponent=*,
372 DomainComponent=MIT, DomainComponent=COM
375 If A.B.PODUNK.COM is looked up in the directory, the query will fail
376 and indicate that two components are matched. A substitution should
377 be made, and *.*.PODUNK.COM looked up explicitly to identify the
378 associated information.
383 DNS information can be associated with an entry in the DIT. It is
384 important that this is done in a manner which is exactly equivalent to
385 the information stored in the DNS. This will allow the DIT to have
386 information loaded from the DNS or vice versa. All (authoritative)
387 records associated with a domain will be stored in the DIT. There is
388 no attempt made by the OSI Directory to emulate DNS caching or TTL
389 handling. It is assumed that the master entries are maintained by use
390 of DNS Zone Transfer (or equivalent), and that they can be treated as
391 authoritative. There is a need to define an attribute syntax which
392 represents a DNS record. This then allows DNS records to be stored in
393 the DIT. There are three possible encodings of this record:
395 ASN.1 Encoded This is the most natural approach in terms of X.500.
396 However, it would require all users of this service to handle the
397 new syntax, which would be awkward. There is a problem with
398 handling the resource format in a general manner.
400 DNS Binary Encoded Use the formally defined record syntax. This
401 would be convenient for access to the data by DNS related
402 software, but would be an awkward encoding for independent X.500
405 Text encoded Use of a text encoding derived from the DNS
406 specifications. This is straightforward to map onto DNS protocol,
407 and easy to support in a naive X.500 DUA. This approach is chosen.
410 The syntax is defined in IA5 characters. The BNF of the record uses
411 the definitions of section 5.1 of RFC 1035. It is
414 Hardcastle-Kille Page 7
419 RFC 1279 X.500 and Domains November 1991
422 <rr> [ ";" <comment> ]
424 Three examples of this (for domain C.ISI.EDU) might be:
427 500 A 10.1.0.52 ; Basic address record
428 IN 600 MX 10 VENERA.ISI.EDU. ; MX record
429 600 IN MX 10 VENERA.ISI.EDU. ; MX record - other order
434 o The class and TTL may be in either order (following RFC 1035)
436 o The class defaults to IN
438 o Domains must always be fully specified (i.e., master file
439 abbreviate rules are not used).
441 o The TTL for a record must always be present (this saves looking at
442 the parent entry to find the SOA record).
444 o Records (e.g., SOA) may be multiline. Lines should be separated
445 with the two IA5 characters <CR><LF>.
447 CNAME records are mapped symmetrically onto Directory Aliases.
449 This is now defined in terms of attribute and object class
450 definitions. A single record type is defined, as opposed to one
451 attribute type per record type. This allows the definition to not
452 require extension when new DNS Record types are define. However,
453 there is some loss of efficiency if only a single record type is
454 needed, as filtering must be done by the DUA.
455 Similarly, no distinction is made on the basis of DNS class. This
456 means that if there are two class hierarchies, that they must be
457 represented in a single DIT, and that information for different
458 classes must be separated by DUA filtering.
461 DNSDomain OBJECT-CLASS
467 Hardcastle-Kille Page 8
472 RFC 1279 X.500 and Domains November 1991
476 ATTRIBUTE-SYNTAX IA5String
480 Lookup of a domain is achieved by translating it algorithmically to a
481 Distinguished Name (DN), and reading back attributes desired. This
482 information can be managed and searched in a straightforward fashion.
484 The information may also be downloaded into a DNS database. This
485 should be done by use of zone transfer. A tool to perform zone
486 transfer (in both directions) between a DNS Server and a DSA would
487 seem to be both straightforward and useful. This would be a key tool
488 in a transition to X.500 based management of the DNS. It would also
489 allow a large part of the DNS namespace to be rapidly made available
491 Inverse information can be derived by the usual IN-ADDR domain, which
492 will be represented in the same manner in the DIT.
497 Information associated with the UK NRS (Name Registration Scheme) can
498 be handled in a similar manner [Lar83]. This is being developed in a
499 separate document by Alan Turland.
502 9 Application Entity Titles
504 In many cases, Application entities will be closely related to
505 domains. In some cases, it may be appropriate to give Application
506 Entities names which are related to the DNS part of the DIT. In this
507 case, the Domain Name will be used to identify the application, and
508 the entry for the domain will also be of object class Application
509 Process. The children of this entry will identify Application
510 Entities, with names such as ``FTAM Service''.
516 It is clearly useful to represent networks within the DIT. A short
517 note on how to do this is given here. It is likely that this
518 specification will later be evolved in a separate document. This
520 Hardcastle-Kille Page 9
525 RFC 1279 X.500 and Domains November 1991
528 defines an Object Class for a general network, and shows how it can be
529 subclassed to define technology specific networks.
538 IPNetwork OBJECT-CLASS
540 MUST CONTAIN -AssociatedDomain"
543 The Network Object Class allows networks to be defined, and for useful
544 attributes to be associated with the entry. A network will often
545 appear in more than one organisational structure, and this linkage
546 should be achieved by use of aliases. This grouping can facilitate
547 management of networks.
548 The subclass IPNetwork mandates linkage into the DNS part of the DIT.
549 This will be represented in the DIT using the structures of RFC 1101
550 [Moc89]. Both of the domains which identify the network should be
551 represented in the Object Class. For example, a network might have
552 the (user friendly) name:
554 UCL-Ethernet, University College London, GB
557 This would have associated domains 0.0.40.128.IN-ADDR.ARPA and
558 UCL-ETHERNET.UCL.AC.UK. These would both have the analogous DIT
559 representations. For example:
561 DomainComponent=0, DomainComponent=0, DomainComponent=40,
562 DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=ARPA
568 There is a need to associate the organisational X.500 DIT and the DNS
569 tree. The objects represented are different (Domain 6= Organisation;
570 Person 6= RFC 822 Mailbox). Therefore aliasing is not an appropriate
571 linkage. However, in many cases, there is a linkage which is rather
573 Hardcastle-Kille Page 10
578 RFC 1279 X.500 and Domains November 1991
581 stronger than that implied by the seeAlso attribute. Therefore, we
582 define new attributes, which represent this stronger cross-linkage.
583 The same mechanism can be used to link a domains with an Application
584 Entity or an Application Process.
585 Links from the organisational X.500 DIT to the DNS tree are provided
586 by a new attribute, which could be present in Organisation or
587 Organisational Unit entries.
590 ObjectWithAssociatedDomain OBJECT-CLASS
592 MUST CONTAIN -AssociatedDomain"
594 AssociatedDomain ATTRIBUTE
595 WITH ATTRIBUTE-SYNTAX ia5StringSyntax
597 For example, the organisational entry:
599 University College London, GB
602 would have an attribute:
604 AssociatedDomain = UCL.AC.UK
607 Similarly, an RFC 822 mailbox attribute is used to link entries of
608 Person Object Class to their associated DNS entry. This attribute is
609 defined in the Cosine and Internet Naming Architecture [BHK91].
610 Conversely, there are pointers from the DNS represented tree into the
611 organisational X.500 DIT:
614 AssociatedName ATTRIBUTE
615 WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
617 This attribute is associated with the Domain object class.
619 This entry is used to provide linkage from the DNS X.500 Hierarchy
620 into the organisational X.500 hierarchy. Where such entries do not
621 exist, attributes in the DNS entry (such as phone number) may be used.
622 It is recommended that information is not duplicated. The preferred
623 setup is for the DNS attributes to be rather skeletal, with pointers
624 into the organisational X.500 DIT.
626 Hardcastle-Kille Page 11
631 RFC 1279 X.500 and Domains November 1991
634 For example, the domain UCL.AC.UK would be represented in the DIT as:
636 DomainComponent=UCL, DomainComponent=AC,
640 This entry would have in it an AssociatedName attribute with value:
642 University College London, GB
645 This example shows a simple case with 1:1 linkage. There are cases
646 where a domain might be associated with multiple organisations, or an
647 organisation with multiple domains.
650 12 Conclusions and proposals for evaluation
652 Experiments should be undertaken to determine the practicality and
653 utility of this scheme, in a pilot environment. A possible approach
654 to this experimentation is described in Appendix A.
655 Object Identifiers have been assigned for this purpose in the Cosine
656 and Internet Naming Architecture [BHK91].
661 [BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
662 X.500 schema. Request for Comments RFC 1274, Department of
663 Computer Science, University College London, November 1991.
665 [CCI88] The Directory --- overview of concepts, models and services,
666 December 1988. CCITT X.500 Series Recommendations.
668 [Cro82] D.H. Crocker. Standard of the format of ARPA internet text
669 messages. Request for Comments 822, University of Delaware,
672 [HK91] S.E. Hardcastle-Kille. Using the OSI directory to achieve
673 user friendly naming. Request for Comments in preparation,
674 Department of Computer Science, University College London,
679 Hardcastle-Kille Page 12
684 RFC 1279 X.500 and Domains November 1991
687 [Lar83] J. Larmouth. JNT name registration technical guide, April
690 [Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail:
691 Part 1 --- Message Encipherment and Authentication
692 Procedures. Request for Comments 1113, Bolt, Beranek, and
695 [Moc87a] P. Mockapetris. Domain names - concepts and facilities.
696 Request for Comments RFC 1034, USC/Information Sciences
697 Institute, November 1987.
699 [Moc87b] P. Mockapetris. Domain names - implementation and
700 specification. Request for Comments RFC 1035,
701 USC/Information Sciences Institute, November 1987.
703 [Moc89] P. Mockapetris. DNS encoding of network names and other
704 types. Request for Comments RFC 1101, USC/Information
705 Sciences Institute, April 1989.
708 13 Security Considerations
710 This memo does not directly address security issues. However, due to
711 the facilities of X.500, this proposal could lead to a more secure way
712 to access and manage domain information.
717 Steve Hardcastle-Kille
718 Department of Computer Science
719 University College London
724 Phone: +44-71-380-7294
727 EMail: S.Kille@CS.UCL.AC.UK
732 Hardcastle-Kille Page 13
737 RFC 1279 X.500 and Domains November 1991
740 A Possible Deployment Approach
742 This appendix notes a possible approach to deploying an experiment to
743 evaluate this mechanism. The following components of a possible
744 experiment are noted.
747 1. User tool. This will take a domain or mailbox as input. This
748 will be looked up in the DIT. This tool should be capable of:
750 o Attempting to correct user input
754 o Looking up information associated with the domain (or mailbox)
755 and associated name, in particular the manager (of both domain
756 and associated name) and information on the manager (e.g.,
757 phone number and mailbox).
761 o Handle IN-ADDR.ARPA inverse lookups if supplied with an IP
766 2. A procedural library to allow user interfaces to make easy use of
769 3. Zone transfer tool. This will use the zone transfer protocol to
770 transfer information between a DSA and Domain Nameserver. When
771 writing to the DSA, attributes in an entry which are not DNS
772 records should remain untouched.
774 4. Linkage patching tool. When the organisational DIT is
775 established, associated domain pointers are usually inserted. A
776 tool can be written to search the DIT and insert the reverse
779 5. DNS Manager Tool. This will allow user addition of additional
780 information into the DNS part of the DIT. A standard DUA can
781 probably be used for this.
785 Hardcastle-Kille Page 14
790 RFC 1279 X.500 and Domains November 1991
793 6. Mailbox download tool. This will allow download of local
794 mailboxes, with pointers to the user entries.
796 7. Emulation DNS Server, using the Directory as a database. The
797 server should maintain a permanent connection to its local DSA. As
798 there is no OSI bind, the response of this server can be at least
799 as fast as a normal DNS server. There can be two variants of this
802 (a) Using a local DSA as a local database but using DNS
803 distributed operations.
805 (b) Do all lookups in the directory (using Directory Distributed
808 An initial experiment is straightforward. The Zone Transfer Tool (3)
809 can be used to download a large part of the DNS space into a single
810 DSA (there will be some restrictions, as parts of the DNS hierarchy do
811 not permit zone transfer). This can be used repeatedly to maintain
812 the information. The linkage patching tool (4) can be used to put in
813 pointers to parts of the DIT. The user tool can then be used (by all
814 sites participation the the directory pilot) to look up domain
815 information. This will allow the utility of the approach to be
816 evaluated. The manager tool (5) will allow extra information to be
817 added to parts of the DNS tree.
819 The next stage will be to distribute the DNS part of the DIT over
820 multiple DSAs using Directory distribution techniques.
821 The emulation DNS Server (7) will be useful to ensure that equivalent
822 functionality is being offered by the Directory. It can also be used
823 to examine performance differences.
824 A final step is to master some parts of the DNS hierarchy in the DIT.
825 Because of the zone transfer technique, this will be entirely
826 transparent to the DNS user. Management benefits can then be
838 Hardcastle-Kille Page 15