Naming

1. Naming Chapter 4

2. Naming Entities • A name is a character string used to refer to an entity. • An entity can be practically anything, mailboxes, newsgroups, web pages… • To operate on an entity we need to access it via the entity “access point” • Entities can have more than one access point. • Entities may change their access points

3. Naming Entities • Entity names are commonly independent of their addresses. • This attribute make names location independent. DNS aliases are a good example of this characteristic.

4. Naming Entities • Some names uniquely identify entities, these type of names are called identifiers. • A true identifier (MAC address) • Refers to at most one entity • Each entity is referred to at most by one identifier • Identifiers always refers to the same entity.

5. Names Organized in a Name Spaces Directed Acyclic Graph (no cycles) Root Node. • A general naming graph with a single root node. Equivalent path name n0:<home,steen,mbox> Leaf Nodes store entity information such as address or state. Directory Nodes store table of outgoing edges represented by a pair (edge label,node identifier).

6. Name Spaces (2) • The general organization of the UNIX file system implementation on a logical disk of contiguous disk blocks. Inodes are identifiers and file names are names.

7. Name Resolution • Path names provide a convenient mechanism for retrieving information about entities. • The convenience depends on knowing where to start. Knowing how and where to start is referred to as a closure mechanism. i.e. in a UNIX file system the root directory if the first inode in the logical disk representing the file system.

8. Linking and Mounting (1) • The concept of a symbolic link explained in a naming graph.

9. A hard link is when a directory entry refers to a particular file inode. Each file inode has at least one hard link or it wouldn't make sense. We usually say that a particular file is hard-linked if multiple directory entries in the file system refer to that file's inode. This means that the file is referenced by more than one directory (and therefore by more than one name). The problem here is that we cannot allow hard links to directories since this could create circular links and would violate the tree structure design of the file hierarchy, as discussed earlier. These circular links would also complicate garbage collection. • A symbolic link is a special file type whose data contains a filename. This filename is essentially a "soft link" to another file. Whenever the kernel encounters a symbolic link file type, it reads the filename in the data part of the file and goes to that filename. It's as if the Kernel traverses the namespace for the user. Symbolic links are nice in that they are links at the namespace level rather than at the block level (like hard links).

10. Mounting • Two name spaces can be merged by having a mount point in one name space and a mounting point in a second name space. The mount point stores the identifier of the directory node from the different name space.

11. Mounting • The following information is required to mount a foreign name space • The name of the access protocol • The name of the server • The name of the mounting point.

12. Linking and Mounting (2) Protocol • Mounting remote name spaces through a specific process protocol. server Mounting point

13. DEC’s Global Name Service Linking and Mounting (3) New root, old roots children • Organization of the DEC Global Name Service GNS expands path names to include node identifier The new relative path becomes /vu/home/steen/keys Alternative approach to mounting

14. Name Space Distribution (1) • An example partitioning of the DNS name space, including Internet-accessible files, into three layers.

15. Name Space Distribution (2) • A comparison between name servers for implementing nodes from a large-scale name space partitioned into a global layer, as an administrational layer, and a managerial layer.

16. Implementation of Name Resolution (1) • The principle of iterative name resolution. Iterative name Resolution

17. Implementation of Name Resolution (2) • The principle of recursive name resolution. Recursive name Resolution

18. Implementation of Name Resolution (3) • Recursive name resolution of <nl, vu, cs, ftp>. Name servers cache intermediate results for subsequent lookups.

19. Implementation Of Name Resolution • In recursive name resolution after caching has resulted in the root knowing the address of cs from the request <nl,vu,cs,ftp> later when the request <nl,vu,vs,flits> comes in the root forwards the request flits directly to cs which resolves cs:<flits>

20. Implementation of Name Resolution (4) • The comparison between recursive and iterative name resolution with respect to communication costs.

21. The DNS Name Space • The most important types of resource records forming the contents of nodes in the DNS name space.

22. DNS Implementation (1) • An excerpt from the DNS database for the zone cs.vu.nl.

23. DNS Implementation (2) • Part of the description for the vu.nl domain which contains the cs.vu.nl domain.

24. DNS Implementation • The tools used to access DNS information include • nslookup • dig • host

25. DNS Recursion • DNS Recursion DNS requests can either be "recursive" or "non-recursive". Client applications typically requests that the DNS server performs recursion for them by setting an "RD" (recursion desired) flag in the request packet. This is a recursive request. Client applications do this both because they do not posses the ability to resolve domain names themselves, and also to take advantage of centralized caching on the DNS server. However, when a DNS server sends requests to other DNS servers as part of the recursion process, these requests are typically non-recursive (the RD flag is not set). The DNS server indicates back to the client if it is willing to perform recursion or not by setting or not setting an "RA" (recursion available) flag in the response packet. When a DNS server receives a recursive request from a client that it is willing to perform recursion for, it will go through the process of resolving the requested domain name by first asking the root servers, which respond with a referral to the top level DNS servers, then asking one of those servers, which respond with a referral to the next level DNS servers, etc. When a DNS server receives a non-recursive request or a request from a client that it is not willing to perform recursion for, it typically responds immediately with whatever local data it has available at the time without doing any additional processing.

26. DNS Root Servers • Typically DNS servers require root-server data before they can even function. • There are 13 root servers

27. DNS Root Servers • Root servers are operated by twelve organizations often referred to as the "root server operators". They are • A - VeriSign Global Registry Services • B - Information Sciences Institute • C - Cogent Communications • D - University of Maryland • E - NASA Ames Research Center • F - Internet Systems Consortium, Inc. • G - U.S. DOD Network Information Center • H - U.S. Army Research Lab • I - Autonomica/NORDUnet • J - VeriSign Global Registry Services • K - RIPE NCCL - ICANN • M - WIDE Project

28. DNS Root Servers • The root zone file lists the names and numeric IP addresses of the authoritative DNS servers for all top-level domains (TLDs) such as ORG, COM, NL and AU. On 12-Dec-2004 there were 258 TLDs and 773 different authoritative servers for those TLDs listed. • Type command dig in UNIX to see root server hostnames.

29. X.500 • X.500 is another name space protocol that has grown in popularity through the broad acceptance of a light weight version of this protocol called LDAP.

30. X.500 • X.500 is the name given to a series of standards produced by the ISO/ITU-T defining the protocols and information model for a global directory service. • X.500 Directory Service is a standard way to develop an electronic directory of people in an organization so that it can be part of a global directory available to anyone in the world with Internet access. • X.500 is highly scaleable and robust • X.500 directory servers are fully co-operable

31. Directory Entires • Entries are made up of a pair (attribute,value), where each attribute has an associated type.

32. The X.500 Name Space (1) • A simple example of a X.500 directory entry using X.500 naming conventions.

33. Naming Attributes • An entry is unambiguously identified by a distinguished name (DN). • A distinguished name is the concatenation of selected attributes from each entry, called the relative distinguished name (RDN), in the tree along a path leading from the root down to the named entry.

34. The X.500 Name Space (2) • Part of the directory information tree (DIT).

35. The X.500 Name Space (3) • Two directory entries having Host_Name as RDN. RDN = Relative Distinguishing Name

36. X.500 and LDAP • Did anyone notice the similarities between X.500 and LDAP? • What is LDAP?

37. LDAP • Light Weight Directory Access Protocol • The LDAP protocol enables organizations to arrange and access directory information in a hierarchy. In this context, directory refers to a collection of information, such as a telephone directory. (Same as X.500)

38. LDAP • LDAP was designed in the mid-1990s at the University of Michigan to adapt a complex enterprise directory system (X.500) to the modern Internet. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service "for the rest of us."

39. LDAP • An LDAP directory is similar to the X.500 model. • Typically a hierarchically structured database where each layer in the hierarchy typically corresponds to a level of organizational structure.

40. Simple Directory Structure This example is fully symmetrical: all the entries at each layer are of the same type.

41. Asymmetrical Directory • An LDAP directory can be structured so that the layers under one entry contain different information from the layers under another entry.

42. LDAP • LDAP’s complexity and flexibility is a key to LDAP's usefulness. With it, you can represent any organizational structure. • LDAP offers performance advantages over conventional databases for accessing hierarchical, directory-like information that is read frequently and changed infrequently. • Although LDAP is often used for e-mail, address, telephone, or other organizational directories, it is not limited to these types of applications.

43. LDAP • You can put just about anything you want into the directory... • Text • Photos • URLs • Pointers to whatever • Binary data • Public Key Certificates • Though, there may be implementation-dependent limitations on the amount of data of a given type you can store.

44. LDAP • Why is LDAP important?

45. LDAP • LDAP is an established Internet standard that enables cross-network operating system interoperability between directory services that support it. In Windows 2000, LDAP is the primary way the Operating System accesses the Active Directory database. By using this open standard, Microsoft is enabling 3rd party vendors and other platforms (Unix) to be able to work in a Windows 2000 environment and use AD services.

46. LDAP • Like X.500 the basic information object of LDAP is the entry. An entry is composed of one or more attributes. Entries are subject to content rules defined by the directory schema.

47. LDAP • An LDAP directory entry consists of one or more attributes. Attributes have types and values. The type determines the information that the values can contain. The type also specifies how the value is processed. For example, the type determines whether an attribute can have multiple values. The mail attribute type, which contains an e-mail address, is multivalued so you can store multiple e-mail addresses for one person.

48. Schema • A directory schema is a set of rules that determines what can be stored in a directory. It defines, at a minimum, the following two basic directory characteristics: • The object classes to which entries can belong • The directory attribute types • The table shown earlier is based on a common schema.

49. Object Class • Object classes enable LDAP to group related information. Frequently, an object class corresponds to a real object or concept, such as a country, person, room, or domain (in fact, these are all standard object type names). Each entry in an LDAP directory must belong to one or more object classes

50. Object Class • The following characteristics define an object class: • The class name • A unique object ID that identifies the class • The attribute types that entries of the class must contain • The attribute types that entries of the class can optionally contain • (Optional) A superior class from which the class is derived