DISTRIBUTED SYSTEMS

Lecture 5 – Naming

Huber Flores, Xiang Su, Pan Hui {firstname.lastname}@helsinki.fi

Helsinki, Finland, 2019. 2

NAMING

Helsinki, Finland, 2019. 3 Agenda

5.1 NAMES, IDENTIFIERS, AND ADDRESSES

5.2 FLAT NAMING 5.2.1 Simple solutions 5.2.2 Home-based approaches

5.3 STRUCTURED NAMING 5.3.1 Name spaces 5.3.2 Name resolution 5.3.3 The implementation of a name space 5.3.4 Example: The Domain Name System

5.4 ATTRIBUTE-BASED NAMING 5.4.1 Directory services 5.4.2 Hierarchical implementationsHelsinki, Finland,: LDAP2019. 4 Names, identifiers, and addresses

• Name: string of bits for referring to an entity – Hosts, printers, files, processes, users, locations, mailboxes, web pages, … – Entities can be operated on via an access point • The name of an access point is address • An entity can have multiple access points – Location-independent names (independent of address) • Identifier: an unambiguous name – Refers to at most one entity – Each entity is referred to by at most one identifier – Always refers to the same entity (it is never re-used) • Human-friendly names: string of characters • Name-to-address binding maintained by naming service Helsinki, Finland, 2019. 5 Flat naming

• Unstructured or flat names – Identifiers are random bit strings – Do not contain any information on how to locate the access point

• Simple solutions for resolving names and locating entities – Broadcasting and multicasting • Effective in LANs, e.g. ARP (Address Resolution Protocol) • Can never scale beyond local-area networks – Forwarding pointers

Helsinki, Finland, 2019. 6 Forwarding pointers

• Moving entity leaves behind a reference to its new location – Forwarding pointers using (client stub, server stub) pairs • Migration is transparent to client

– Challenges • Long chains are not fault tolerant • Burden on intermediate locations • Vulnerability to broken Helsinki,links Finland, 2019. 7 Forwarding pointers

• Storing a shortcut in a client stub

Helsinki, Finland, 2019. 8 Home-based approaches

• Principle of Mobile IP – Home agent (HA) in home location keeps track of current location of a mobile host (temporary care-of-address)

Helsinki, Finland, 2019. 9 Home-based approaches

• Problems with home-based approaches – Home address has to be supported for entity’s lifetime. – Home address is fixed ⇒ unnecessary burden when the entity permanently moves – Poor geographical scalability (entity may be next to client)

Helsinki, Finland, 2019. 10 Hierarchical Location Services (HLS)

• Build a large-scale search tree for which the underlying network is divided into hierarchical domains. Each domain is represented by a separate directory node.

Helsinki, Finland, 2019. 11 Hierarchical Location Services (HLS)

• Address of entity E is stored in a leaf or intermediate node • Intermediate nodes contain a pointer to a child if and only if the subtree rooted at the child stores an address of the entity • The root knows about all entities

Helsinki, Finland, 2019. 12 HLS: Lookup operation

• Start lookup at local leaf node • Node knows about E ⇒ follow downward pointer, else go up • Upward lookup always stops at root

Helsinki, Finland, 2019. 13 HLS: Insert operation

(a) An insert request is forwarded to the first node that knows about entity E. (b) (b) A chain of forwarding pointers to the leaf node is created

Helsinki, Finland, 2019. 14 Hierarchical location services

• Principle of distributing logical location servers

Domain

Helsinki, Finland, 2019. 15 Structured naming: Name spaces

• A name space can be presented as labeled directed graph – Two types of nodes • Leaf node: named entity (no outgoing edges) • Directory node: entity with outgoing edges stored in directory table (edge label, node identifier) – Root (node): only outgoing, no incoming edges – Path name: N: • If 1st node root ® absolute path name, otherwise relative path name – Global name (/home/steen) vs local name (./steen)

A general naming graph with a single root node (directed acyclic graph, no cycles)

Helsinki, Finland, 2019. 16 Name spaces

• Naming in UNIX file system – Directory node represents a file directory • Each directory is implemented as a file – Leaf node represents a file – Index nodes (inode) • Contents: location of associated file on the disk, owner, time of creation, time of last modification, protection etc. • Index # corresponds to node identifier in the naming graph – #0 root directory

The general organization of the Unix file system implementation on a logic disk of contiguous disk blocks

Helsinki, Finland, 2019. 17 Name resolution

• To resolve a name, we need a directory node. • Name resolution for path N: – Name resolution starts at N – Node identifier n1 corresponding to label-1 is looked up in the directory table of N – Node identifier n2 corresponding to label-2 is looked up in the directory table of n1 – ... – If path exists, resolution stops at the last node referred to by label-n, returning the content of that node

Helsinki, Finland, 2019. 18 Closure mechanism

• Need to know how and where to start name resolution • Unix: the first inode in the logical file system is the root directory • Example: – www.distributed-systems.net: start at a DNS name server – /home/maarten/mbox: start at the local NFS file server (possible recursive search)

Helsinki, Finland, 2019. 19 Linking and mounting

: another name for the same entity – Can be implemented as a hard link or a symbolic link

/keys and /home/steen/keys /home/steen/keys is are hard links to node n5 symbolic link to node n5

Helsinki, Finland, 2019. 20 Linking and mounting

• Merging name spaces via mounting – A directory node (mount point) stores the identifier of a directory node from a foreign name space (mounting point) • Mounting point is typically the root of the foreign name space

– Requires • Name of access protocol • Name of server • Name of mounting point in foreign name space

Helsinki, Finland, 2018. Helsinki,Mounting Finland, 2019.remote name spaces in NFS 21 Implementation of a name space

• Name-to-address-binding maintained by naming service • Naming service implemented by name servers • Names are organized into a name space • Name space distribution – Global layer • Root + its children – Administrational layer • Nodes managed by a single organization – Managerial layer

Helsinki,An example Finland, 2018. partitioning of the DNS name space Helsinki, Finland, 2019. 22 Implementation of a name space

• Comparison between name servers for implementing nodes from a large-scale name space

Helsinki, Finland, 2019. 23 Implementation of name resolution

• Iterative name resolution – Caching restricted to client’s name resolver ® different clients need to do complete resolution – Compromise: intermediate local name server shared by all clients caches results

Helsinki, Finland, 2019. 24 Implementation of name resolution

• Iterative name resolution

Helsinki, Finland, 2019. 25 Implementation of name resolution

• Recursive name resolution

Helsinki, Finland, 2019. 26 Implementation of name resolution

• Recursive name resolution (cont.) – Caching of intermediate results for subsequent lookups

Helsinki, Finland, 2019. 27 Implementation of name resolution

• Comparison of recursive and iterative name resolution with respect to communication costs – Recursive is typically more efficient

Helsinki, Finland, 2019. 28 Example: The Domain Name System

• Hierarchically organized name space with each node having exactly one incoming edge → edge label = node label • Subtree is a zone (~domain) managed by a primary (authoritative) name server providing authoritative resource records (can also have one or more secondary name servers) • Domain ~ a subtree; domain name ~ a path name to a domain’s root node

Helsinki, Finland, 2019. 29 Example: The Domain Name System

Local name servers • Do not strictly belong to hierarchy • Each ISP (e.g. company, university) has one – Also called “default name server” • When a host makes a DNS query, query is sent to its local DNS server – Acts as a proxy, forwards query into hierarchy Helsinki, Finland, 2019. 30 Example: The Domain Name System

• Principal service: IP address Û domain name translation –For hosts, routers, applications • Hierarchical name space –Distributed database implemented in hierarchy of many name servers • Application-level protocol –Complexity at the network’s edge (end-to-end) • Scalable (through hierarchy & caching) • Replicated for reliability • Requires administration

Helsinki, Finland, 2019. 31 DNS: Example

• Mapping of email address to IP address

Helsinki, Finland, 2019. 32 DNS: Additional services

• Host aliasing (canonical and alias names) – Host with complicated name can have aliases (often mnemonic) – relay1.west-coast.enterprise.com (canonical hostname) may have two aliases {enterprise.com, www.enterprise.com} – [email protected] instead of [email protected] coast.hotmail.com

• Load distribution – Replicated web servers (set of IP addresses for one canonical name) • Content Distribution Networks (e.g. Akamai) • Busy sites such as www.cnn.com are replicated over multiple servers

Helsinki, Finland, 2019. 33 DNS: Why not centralized?

• Original Internet naming scheme – Master file (hosts.txt) of host names & their IPs • Maintained by Network Information Center (NIC) • Distributed by email, or downloaded by FTP • Single point of failure • Traffic volume – 1991: 24-hour traces of a top-level server (.edu) • ~1 M requests/day -> ~ 11.5 requests/s – 2008: k-root server in London, 5000 requests/s • Distant centralized database – Communication overhead for clients • Maintenance – Allow organizations to manage their own naming – Authentication for large #clients to update DB

Helsinki, Finland, 2019. 34 DNS: Why not centralized?

Does not scale!

Helsinki, Finland, 2019. 35 DNS: Name space

• An example partitioning of the DNS name space, including Internet-accessible files, into three layers – Subtree is called a domain – Path name to domain’s root node is called domain name

Helsinki, Finland, 2019. 36 DNS: Name space

Helsinki, Finland, 2019. 37 DNS: Domain names

• Hierarchical, cs.helsinki.fi – cs = Department of Computer Science – oulu = University of Helsinki – fi = Finland • Path name – Comprises of components (labels) • Max 63 chars long • Can contain letters, digits and hyphens • Must start with a letter – At most 127 labels – Max 255 chars long – Case insensitive • cs.helsinki.fi = CS.HELSINKI.FI = CS.Helsinki.Fi • Absolute vs relative – Absolute: cs.helsinki.fi. – Relative: cs.helsinki.fi

• UDRP (Uniform Domain Name Dispute Resolution Policy) – Applies to global TLD’s: aero, biz, com, coop, info, museum, name, net, org

Helsinki, Finland, 2019. 38 DNS: Domain names

• Top level domains (TLD)

Currently 239 existing two letter country codes (ISO 3166)

Helsinki, Finland, 2019. 39 DNS: Domain names

• Domain counts (http://www.domaintools.com/internet- statistics/)

Helsinki, Finland, 2019. 40 DNS: Resource records (RR)

• A domain name can have a set of resource records associated with it – For a single host most common resource record is its IP address – Resource records are indexed by the related domain name

Class=IN for Internet information

Helsinki, Finland, 2019. 41 DNS: Resource records

• Most important types of resource records

• Canonical names and aliases – Aliases using Type=CNAME – Provides alias name for a canonical (real) name www.ibm.com is really servereast.backup2.ibm.com

Helsinki, Finland, 2019. 43 DNS: Zones and name servers

• DNS name space is divided into nonoverlapping zones – A zone is divided by its admin

• Each zone has a primary (authoritative) name server – Provides authoritative resource records

• A zone may have a number of secondary name servers – Do not access database directly but via so-called zone transfer by primary servers

Helsinki, Finland, 2019. 44 DNS : Name servers

Name server hierarchy

Client wants IP for www.amazon.com; 1st approximation 1. Client queries a root server to find com DNS server 2. Client queries com DNS server to get amazon.com DNS server 3. Client queries amazon.com DNS server to get IP address for www.amazon.com Helsinki, Finland, 2019. 45 DNS: Name servers

• Root name servers (http://www.root-servers.org) – Contacted by local name server that can not resolve name • Each name server knows the address of a root server – Contacts authoritative name server if name mapping not known – Gets mapping, returns mapping to local name server

13 root name servers worldwide (number of actual server machines is much larger) – {a, b, c, … , m}.root- servers.org – Critical part of the Internet infrastructure !

Helsinki, Finland, 2018. Helsinki, Finland, 2019. 46 DNS: Name servers

• k-root as an example – Global nodes: London, Amsterdam, Tokyo, Delhi, Miami – Local nodes: Budapest, Milan, Helsinki, Reykjavik, Poznan, Frankfurt, Geneva, Athens, Doha, Novosibirsk , Abu Dhabi, Brisbane – Request per second in k-root London

Helsinki, Finland, 2019. 47 DNS: Name servers

• FICIX hosts local mirror copies of i-root and k-root in Helsinki – Only visible to organisations peering on the FICIX and their customers – Requests per second in k-root Helsinki

Helsinki, Finland, 2019. 48 DNS: Name servers

• Top-level domain (TLD) servers – Responsible for com, org, net, edu, etc., and all top-level country domains uk, fr ... – Network solutions maintains servers for com TLD – Educause for edu TLD

• Authoritative DNS servers – Organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., web and mail) – Can be maintained by organization or service provider

• Local name server – Does not strictly belong to hierarchy – Each ISP (residential ISP, company, university) has one • Also called “default name server” – When a host makes a DNS query, query is sent to its local DNS server • Acts as a proxy, forwards query into hierarchy • Caches results for efficiency Helsinki, Finland, 2019. 49 DNS: Local name resolution

• Client application process obtains the IP address of a named host through name resolver – Resolver typically uses UDP (can also be configured to use TCP)

(1) = resolver invoked by client AP with the name of the server host (2) = resolver sends a type-A query containing the name of the server host to its local DNS (3) = local DNS returns a type-A resource record containing the IP address of the server (4) = resolver returns IP address of the server to the client AP (5) / (6) = client and server Aps carry out networkHelsinki, appliationFinland, 2019./ transaction 50 DNS: Iterative name resolution

• Host at cis.poly.edu wants IP address for gaia.cs.umass.edu

Iterative query • Contacted server replies with name of server to contact

• Puts burden of name resolution on local name server

• Queries 2, 4, 6 are iterative (query 1 is recursive)

Helsinki, Finland, 2019. 51 DNS: Recursive name resolution

Recursive query • Host/name server ask name server to obtain mapping on its behalf

• Puts burden of name resolution on contacted name server

• Queries 1-4 recursive

Helsinki, Finland, 2019. 52 DNS: Message format

RRs in response to query

records for authoritative servers additional “helpful” info that may be used QR = query/response bit RCODE = response code AA = authorative answer QDcount = number of entries in question section TC = truncated ANcount = number of resource records in answer section RD = recursion desired AScount = number Helsinki,of name Finland,server resource 2018. recods in authority section RA = recursion available ARcount = number ofHelsinki, resource Finland, records 2019. in additional records section 53 DNS: Caching and updating records

• Caching – Resolved names are stored locally in name servers and in clients – Cached entries are marked as non authoritative with shorter TTL (vs. authoritative with longer TTL) – TLD servers typically cached in local name servers • Thus root name servers not often visited – Key to efficiency: reduces network traffic and load on name servers

• Dynamic DNS (RFC 2136, 2137) – Update: permits dynamic changes to RRs • When a DHCP server assigns IP address to a host, it can inform DNS server about the assignment – Notification: primary DNS server propagates changes to backup DNS servers

Helsinki, Finland, 2019. 54 DNS: DNSSEC (DNS Security Extension)

• Services – Authentication of message origin – Integrity of data

• Mechanism – Digital signatures with public key encryption – Public keys are distributed with DNS!

• Problems remaining to be solved – Does not provide confidentiality • Snooping party knows which names a host looks up – Does not prevent DoS (denial-of-service) attacks

Helsinki, Finland, 2019. 55 DNS: Server software comparison

http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software

Helsinki, Finland, 2019. 56 Attribute-based naming

• Description of entities to support search of information • Entity is associated with a collection of (attribute, value) pairs • Attribute-based naming systems known as directory services (vs structured naming systems)

• Challenge: unified selection of attributes and their values – One solution: RDF (Resource Description Framework) • Triplets (subject, predicate, object), e.g. (person, hasname, Alice) • Subject/predicate/object can be a resource • References are typically URL’s

Helsinki, Finland, 2019. 57 Hierarchical implementations: LDAP

• Derived from OSI X.500 directory service • Combines structured naming with attribute-based naming • Consists of directory entries (aka DNS resource records) – A collection of (attribute, value) pairs – Single-valued attributes vs multiple-valued attributes (arrays, lists)

• DIB (Directory Information Base) ~ all directory entries in an LDAP directory service – Each record in a DIB has a globally unique name formed with a sequence of naming attributes called RDN (Relative Distinguished Name) – E.g. /C=NL/O=Vrije Universiteit/OU=Comp.Sc

Helsinki, Finland, 2019. 58 LDAP

• Listing RDNs in sequence leads to a hierarchy called DIT (Directory Information Tree) – Naming graph of an LDAP directory service – A node can represent both LDAP entry and a traditional directory (parent with multiple children) • Two directory entries having Host_name as RDN

– Distinction supported by two different lookup operations • read: read a single record given its path name in the DIT • list: list the names of all outgoing edges of a given node in the DIT Helsinki, Finland, 2019. 59 LDAP

• In large-scale implementation DIT is usually partitioned and distributed across several servers known as DSA (Directory Service Agent) – A DIT partition corresponds to a zone in DNS – A DSA corresponds to DNS name server with advanced search operations • Clients are represented by DUAs (Directory User Agent) – Similar to name resolver in DNS • Microsoft Active Directory – Forest of LDAP domains (several co-existing and linked DITs) • LDAP often combined with DNS – DIT root known under DNS name (SRV record)

Helsinki, Finland, 2019. 60 Your tasks

• For next lecture session: – Read Chapter 6 Coordination (From Van Steen)

Helsinki, Finland, 2019. 61

QUESTIONS J

Helsinki, Finland, 2019.