Movatterモバイル変換

[RFC Home] [TEXT|PDF|PS|PDF|HTML] [Tracker] [IPR] [Info page]

EXPERIMENTAL

Network Working Group                            S.E. Hardcastle-KilleRequests for Comments 1279                   University College London                                                         November 1991X.500 and DomainsStatus of this Memo    This memo defines an Experimental Protocol for the Internet    community.  Discussion and suggestions for improvement are    requested.  Please refer to the current edition of the ``IAB    Official Protocol Standards'' for the standardization state and    status of this protocol.  Distribution of this memo is unlimited.Abstract    This RFCconsiders X.500 in relation to Internet and UK Domains.    A basic model of X.500 providing a higher level and more    descriptive naming structure is emphasised.  In addition, a    mapping of domains onto X.500 is proposed, which gives a range of    new management and user facilities over and above those currently    available.  This specification proposes an experimental new    mechanism to access and manage domain information on the Internet    and in the UK Academic Community.  There is no current intention    to provide an operational replacement for DNS.

RFC 1279                X.500 and Domains                November 19911  The Domain Name SystemThe Domain (Nameserver) System (DNS) provides a hierarchical resourcelabelling system [Moc87a] [Moc87b] [Lar83].  Example domains are:MIT.EDUVENERA.ISI.EDUCS.UCL.AC.UKEntries usually have a single name, although pointers to entries (notsubtrees) may be provided by CNAME records.  Information (resourcerecords) is associated with each entry.  Name components are typicallychosen to be shortish (e.g., ``CS'').RFC 822 mailbox names are closely related [Cro82].  For example:    <S.Kille@CS.UCL.AC.UK>The local-part of theRFC 822 mailbox can be considered as one levellower in the domain hierarchy.2  X.500The OSI Directory, usually known as X.500, provides a very generalnaming framework [CCI88].  A basic usage of X.500 is to provideOrganisationally Structured Names.  A Schema for this is definedwithin the standard.  Name components will typically have longishvalues.  This is an example directory name represented in Tabularform:           Country              GB           Organisation         University College London           Organisational Unit  Computer Science           Common Name          Stephen E. Hardcastle-KilleThis can also be written in the ``User Friendly Name'' notationdefined in [HK91].  This syntax is used for names in the rest of thisdocument:    Stephen E. Hardcastle-Kille, Computer Science,Hardcastle-Kille                                                Page 1

RFC 1279 X.500 and Domains November 1991 University College London, GBThis type of structure is termed ``organisational X.500''. This is asubset of the general capabilities.3 The basic model X.500 has as much relation to the DNS as DNS has to ARP. Paul MockapetrisThis is, essentially, the position adopted here. The basic model isthat organisational X.500 is providing a layer of naming at the levelabove domain names. These structured names can be considered to forma naming layer above domain names. There are the following keydifferences: o Organisational X.500 tends to use longer and more descriptive values o The organisational X.500 DIT is slightly shallower than the DNS tree o X.500 has a richer information framework than DNSThese differences suggest that the following should NOT be done: o Represent X.500 information in the DNS o Have an algorithmic mapping between the two hierarchiesThis note proposes to represent DNS information in the DIT, and toprovide for a loose coupling between the two trees. This note doesnot propose an equivalencing of X.500 and Domains.The proposed model is illustrated in Figure 1. Both an organisationaland domain structure is represented in the DIT, by use of appropriateobject classes and attribute types. A weak linkage is providedbetween the two parts of the tree by use of special attributes. Here,the linkage is 1:1, but it may be more complex for some parts of theorganisational DIT or domain namespace. The linkage is achieved byuse of special attributes, as described inSection 11.Hardcastle-Kille Page 2

RFC 1279                X.500 and Domains                November 1991                  j jZ Z               j j       ZZ            jj              Z Z        jjj                    ZZDomain Component=UK          Country Name=GB                                |                                |                                |Domain Component=AC       Organisation Name=Univeristy College London                        *        BB              ss                  BBBDomain Component=UCL      Org Unit Name=Computer Science      |                *      ||     ssDomain Component=CS       Common Name=Steve Kille     |                  *     |        ssDomain Component=S.Kille                    Figure 1:  Example X.500 treeHardcastle-Kille                                                Page 3

RFC 1279 X.500 and Domains November 19914 Representing Domains in X.500Domains are at the level below X.500 names of the form illustrated inthe previous section. However, it is also possible to use X.500 inother ways. In particular, there are benefits from representingDomains in X.500. Note that this is very different to equivalencing,as no attempt is made to represent X.500 information within the domainscheme. There are the following potential advantages: o 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. o 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. o 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. o User access to the domain data, and in particular searching, could be provided. This would allow users to browse the domain namespace, and to determine information associated with the domains. o The X.500 framework would allow for additional management information to be stored, and to relate the domain names into a more complex structure of information. For example, this might allow for the managers of a system to be identified, and information on how to contact the manager.Hardcastle-Kille Page 4

RFC 1279                X.500 and Domains                November 1991 o  A facility to mapRFC 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. o  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    enchanced mail work [Lin89].5  Representing Domain NamesA new attribute syntax is defined:CaseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX    IA5String    MATCHES FOR EQUALITY SUBSTRINGS ORDERINGA new attribute and two new object classes are defined:DomainComponent ATTRIBUTE    WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax    SINGLE VALUEDomain 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 "Hardcastle-Kille                                                Page 5

RFC 1279                X.500 and Domains                November 1991Note that the attribute AssociatedName is defined inSection 11.  Themanager attribute is defined in the COSINE and Internet namingarchitecture [BHK91].  It allows a manager to be associated with thedomain, which is useful where the manager of the domain is differentto the manager of the object defined by the AssociatedName.  This willallow any domain to be represented in an X.500 hierarchy.  The localpart of anRFC 822 mailbox is treated as a special sort of domaincomponent, and so these can be represented in the tree as a naturalextension of the hierarchy.For example, consider the mailbox S.Kille@cs.ucl.ac.uk.  This willlead 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=UKNote 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 usefulto define (e.g., Machine Type, Owner, Location etc.).  This allowssome information which truly belongs to the domain to be representedthere.  It also allows for further information to be associated withthe domain/mailbox when there is not a relevant part of theorganisationally structure DIT to be pointed at.  When there is anassociated part of the DIT, information from that part of the DITshould not be duplicated in the domain entry.6  WildcardsWildcards are supported by having "*" as a special domain componentname.  If there is a need to emulate wildcard matching using thedirectory, the following algorithm must be employed.  For example, theHardcastle-Kille                                                Page 6

RFC 1279 X.500 and Domains November 1991wildcard entry for *.*.PODUNK.COM would be represented in the DIT as: DomainComponent=*, DomainComponent=*, DomainComponent=MIT, DomainComponent=COMIf A.B.PODUNK.COM is looked up in the directory, the query will failand indicate that two components are matched. A substitution shouldbe made, and *.*.PODUNK.COM looked up explicitly to identify theassociated information.7 DNS InformationDNS information can be associated with an entry in the DIT. It isimportant that this is done in a manner which is exactly equivalent tothe information stored in the DNS. This will allow the DIT to haveinformation loaded from the DNS or vice versa. All (authoritative)records associated with a domain will be stored in the DIT. There isno attempt made by the OSI Directory to emulate DNS caching or TTLhandling. It is assumed that the master entries are maintained by useof DNS Zone Transfer (or equivalent), and that they can be treated asauthoritative. There is a need to define an attribute syntax whichrepresents a DNS record. This then allows DNS records to be stored inthe DIT. There are three possible encodings of this record:ASN.1 Encoded This is the most natural approach in terms of X.500. However, it would require all users of this service to handle the new syntax, which would be awkward. There is a problem with handling the resource format in a general manner.DNS Binary Encoded Use the formally defined record syntax. This would be convenient for access to the data by DNS related software, but would be an awkward encoding for independent X.500 DUAs.Text encoded Use of a text encoding derived from the DNS specifications. This is straightforward to map onto 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 usesthe definitions ofsection 5.1 of RFC 1035. It isHardcastle-Kille Page 7

RFC 1279                X.500 and Domains                November 1991    <rr> [ ";" <comment> ]Three examples of this (for domain C.ISI.EDU) might be:500 A 10.1.0.52                        ; Basic address recordIN 600 MX  10 VENERA.ISI.EDU.                ; MX record600 IN MX10 VENERA.ISI.EDU.                ; MX record - other orderNote that: o  The class and TTL may be in either order (followingRFC 1035) o  The class defaults to IN o  Domains must always be fully specified (i.e., master file    abbreviate rules are not used). o  The TTL for a record must always be present (this saves looking at    the parent entry to find the SOA record). o  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 classdefinitions.  A single record type is defined, as opposed to oneattribute type per record type.  This allows the definition to notrequire extension when new DNS Record types are define.  However,there is some loss of efficiency if only a single record type isneeded, as filtering must be done by the DUA.Similarly, no distinction is made on the basis of DNS class.  Thismeans that if there are two class hierarchies, that they must berepresented in a single DIT, and that information for differentclasses must be separated by DUA filtering.DNSDomain OBJECT-CLASS    SUBCLASS OF Domain    MAY CONTAIN -        DNSRecord "Hardcastle-Kille                                                Page 8

RFC 1279                X.500 and Domains                November 1991DNSRecord ATTRIBUTE    ATTRIBUTE-SYNTAX IA5String    MATCHES FOR EQUALITYLookup of a domain is achieved by translating it algorithmically to aDistinguished Name (DN), and reading back attributes desired.  Thisinformation can be managed and searched in a straightforward fashion.The information may also be downloaded into a DNS database.  Thisshould be done by use of zone transfer.  A tool to perform zonetransfer (in both directions) between a DNS Server and a DSA wouldseem to be both straightforward and useful.  This would be a key toolin a transition to X.500 based management of the DNS. It would alsoallow a large part of the DNS namespace to be rapidly made availablein an X.500 pilot.Inverse information can be derived by the usual IN-ADDR domain, whichwill be represented in the same manner in the DIT.8  NRS InformationInformation associated with the UK NRS (Name Registration Scheme) canbe handled in a similar manner [Lar83].  This is being developed in aseparate document by Alan Turland.9  Application Entity TitlesIn many cases, Application entities will be closely related todomains.  In some cases, it may be appropriate to give ApplicationEntities names which are related to the DNS part of the DIT. In thiscase, the Domain Name will be used to identify the application, andthe entry for the domain will also be of object class ApplicationProcess.  The children of this entry will identify ApplicationEntities, with names such as ``FTAM Service''.10  NetworksIt is clearly useful to represent networks within the DIT. A shortnote on how to do this is given here.  It is likely that thisspecification will later be evolved in a separate document.  ThisHardcastle-Kille                                                Page 9

RFC 1279 X.500 and Domains November 1991defines an Object Class for a general network, and shows how it can besubclassed 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 allows networks to be defined, and for usefulattributes to be associated with the entry. A network will oftenappear in more than one organisational structure, and this linkageshould be achieved by use of aliases. This grouping can facilitatemanagement of networks.The subclass IPNetwork mandates linkage into the DNS part of the DIT.This will be represented in the DIT using the structures ofRFC 1101[Moc89]. Both of the domains which identify the network should berepresented in the Object Class. For example, a network might havethe (user friendly) name: UCL-Ethernet, University College London, GBThis would have associated domains 0.0.40.128.IN-ADDR.ARPA andUCL-ETHERNET.UCL.AC.UK. These would both have the analogous DITrepresentations. For example:DomainComponent=0, DomainComponent=0, DomainComponent=40,DomainComponent=128, DomainComponent=IN-ADDR, DomainComponent=ARPA11 LinkageThere is a need to associate the organisational X.500 DIT and the DNStree. The objects represented are different (Domain 6= Organisation;Person 6=RFC 822 Mailbox). Therefore aliasing is not an appropriatelinkage. However, in many cases, there is a linkage which is ratherHardcastle-Kille Page 10

RFC 1279                X.500 and Domains                November 1991stronger than that implied by the seeAlso attribute.  Therefore, wedefine new attributes, which represent this stronger cross-linkage.The same mechanism can be used to link a domains with an ApplicationEntity or an Application Process.Links from the organisational X.500 DIT to the DNS tree are providedby a new attribute, which could be present in Organisation orOrganisational Unit entries.ObjectWithAssociatedDomain OBJECT-CLASS  SUBCLASS OF top  MUST CONTAIN -AssociatedDomain"AssociatedDomain ATTRIBUTE  WITH ATTRIBUTE-SYNTAX ia5StringSyntaxFor example, the organisational entry:    University College London, GBwould have an attribute:    AssociatedDomain = UCL.AC.UKSimilarly, anRFC 822 mailbox attribute is used to link entries ofPerson Object Class to their associated DNS entry.  This attribute isdefined in the Cosine and Internet Naming Architecture [BHK91].Conversely, there are pointers from the DNS represented tree into theorganisational X.500 DIT:AssociatedName ATTRIBUTE  WITH ATTRIBUTE-SYNTAX distinguishedNameSyntaxThis attribute is associated with the Domain object class.This entry is used to provide linkage from the DNS X.500 Hierarchyinto the organisational X.500 hierarchy.  Where such entries do notexist, attributes in the DNS entry (such as phone number) may be used.It is recommended that information is not duplicated.  The preferredsetup is for the DNS attributes to be rather skeletal, with pointersinto the organisational X.500 DIT.Hardcastle-Kille                                               Page 11

RFC 1279 X.500 and Domains November 1991For example, the domain UCL.AC.UK would be represented in the DIT as: DomainComponent=UCL, DomainComponent=AC, DomainComponent=UKThis entry would have in it an AssociatedName attribute with value: University College London, GBThis example shows a simple case with 1:1 linkage. There are caseswhere a domain might be associated with multiple organisations, or anorganisation with multiple domains.12 Conclusions and proposals for evaluationExperiments should be undertaken to determine the practicality andutility of this scheme, in a pilot environment. A possible approachto this experimentation is described inAppendix A.Object Identifiers have been assigned for this purpose in the Cosineand Internet Naming Architecture [BHK91].References[BHK91] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet X.500 schema. Request for CommentsRFC 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.Hardcastle-Kille Page 12

RFC 1279                X.500 and Domains                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 CommentsRFC 1034, USC/Information Sciences         Institute, November 1987.[Moc87b] P. Mockapetris. Domain names - implementation and         specification. Request for CommentsRFC 1035,         USC/Information Sciences Institute, November 1987.[Moc89]  P. Mockapetris. DNS encoding of network names and other         types. Request for CommentsRFC 1101, USC/Information         Sciences Institute, April 1989.13  Security ConsiderationsThis memo does not directly address security issues.  However, due tothe facilities of X.500, this proposal could lead to a more secure wayto access and manage domain information.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.UKHardcastle-Kille                                               Page 13

RFC 1279 X.500 and Domains November 1991A Possible Deployment ApproachThis appendix notes a possible approach to deploying an experiment toevaluate this mechanism. The following components of a possibleexperiment are noted.1. User tool.This will take a domain or mailbox as input. This will be looked up in the DIT. This tool should be capable of: o Attempting to correct user input o Helping browsing o 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). o Supply DNS records o Handle IN-ADDR.ARPA inverse lookups if supplied with an IP Address o Look up networks2. 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.Hardcastle-Kille Page 14

RFC 1279 X.500 and Domains November 19916. 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.The server should maintain a permanent connection to its local DSA. As there is no OSI bind, the response of this server can be at least as fast as a normal DNS server. There can be two variants of this server. (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 be used to download a large part of the DNS space into a singleDSA (there will be some restrictions, as parts of the DNS hierarchy donot permit zone transfer). This can be used repeatedly to maintainthe information. The linkage patching tool (4) can be used to put inpointers to parts of the DIT. The user tool can then be used (by allsites participation the the directory pilot) to look up domaininformation. This will allow the utility of the approach to beevaluated. The manager tool (5) will allow extra information to beadded to parts of the DNS tree.The next stage will be to distribute the DNS part of the DIT overmultiple DSAs using Directory distribution techniques.The emulation DNS Server (7) will be useful to ensure that equivalentfunctionality is being offered by the Directory. It can also be usedto 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 entirelytransparent to the DNS user. Management benefits can then beexamined.Hardcastle-Kille Page 15

[8]ページ先頭