1 DNS,NFS & RPC Rizwan Rehman, CCS, DU

Netprog: DNS and name lookups 2 Hostnames IP Addresses are great for computers –IP address includes information used for routing. IP addresses are tough for humans to remember. IP addresses are impossible to guess. –ever guessed at the name of a WWW site?

3 The Domain Name System The domain name system is usually used to translate a host name into an IP address. Domain names comprise a hierarchy so that names are unique, yet easy to remember.

4 DNS Hierarchy educomorgjp rpialbany

Netprog: DNS and name lookups 5 Host name structure Each host name is made up of a sequence of labels separated by periods. –Each label can be up to 63 characters –The total name can be at most 255 characters. Examples: –whitehouse.gov –barney.the.purple.dinosaur.com –monica.cs.rpi.edu

Netprog: DNS and name lookups 6 Domain Name The domain name for a host is the sequence of labels that lead from the host (leaf node in the naming tree) to the top of the worldwide naming tree. A domain is a subtree of the worldwide naming tree.

Netprog: DNS and name lookups 7 Top level domains edu, gov, com, net, org, mil, … Countries each have a top level domain (2 letter domain name). New top level domains include:.aero.biz.coop.info.name.pro

Netprog: DNS and name lookups 8 DNS Organization Distributed Database –The organization that owns a domain name is responsible for running a DNS server that can provide the mapping between hostnames within the domain to IP addresses. –So - some machine run by RPI is responsible for everything within the rpi.edu domain.

Netprog: DNS and name lookups 9 rpi.edu DNS DB rpi.edu DNS DB DNS Distributed Database There is one primary server for a domain, and typically a number of secondary servers containing replicated databases. rpi.edu DNS DB Authoritative rpi.edu DNS DB Replicas rpi.edu DNS server

Netprog: DNS and name lookups 10 DNS Clients A DNS client is called a resolver. A call to gethostbyname() is handled by a resolver (typically part of the client). Most Unix workstations have the file /etc/resolv.conf that contains the local domain and the addresses of DNS servers for that domain.

Netprog: DNS and name lookups 11 /etc/resolv.conf domain rpi.edu

Netprog: DNS and name lookups 12 nslookup nslookup is an interactive resolver that allows the user to communicate directly with a DNS server. nslookup is usually available on Unix workstations. ( dig and host are also DNS clients).

Netprog: DNS and name lookups 13 DNS Servers Servers handle requests for their domain directly. Servers handle requests for other domains by contacting remote DNS server(s). Servers cache external mappings.

Netprog: DNS and name lookups 14 Server - Server Communication If a server is asked to provide the mapping for a host outside it’s domain (and the mapping is not in the server cache): –The server finds a nameserver for the target domain. –The server asks the nameserver to provide the host name to IP translation. To find the right nameserver, use DNS!

Netprog: DNS and name lookups 15 DNS Data DNS databases contain more than just hostname-to-address records: –Name server recordsNS –Hostname aliases CNAME –Mail ExchangersMX –Host InformationHINFO

Netprog: DNS and name lookups 16 The Root DNS Server The root server needs to know the address of 1st (and many 2nd) level domain nameservers. educomorgjp albany rpi

Netprog: DNS and name lookups 17 Server Operation If a server has no clue about where to find the address for a hostname, ask the root server. The root server will tell you what nameserver to contact. A request may get forwarded a few times.

18 DNS Message Format HEADER QUERIES Response RESOURCE RECORDS Response AUTHORITY RECORDS Response ADDITIONAL INFORMATION HEADER QUERIES Response RESOURCE RECORDS Response AUTHORITY RECORDS Response ADDITIONAL INFORMATION

NFS (Network File System) NFS (Network File System) allows hosts to mount partitions on a remote system and use them as though they are local file systems. This allows the system administrator to store resources in a central location on the network, providing authorized users continuous access to them. Three versions of NFS are currently in use: –NFSv2 –NFSv3 –NFSv4

NFS (Network File System)

There are three ways to implement network file system: –Upper kernel layer –Lower kernel layer –Middle kernel layer (vnode layer) Important aspect of NFS implementation – implementing effective cache mechanism to boost performance.

NFS (Network File System) We take a look at NFSv3. NFSv3: –Client –server application –Client side import file system from remote machine –Server side export file system to remote machine –Each machine can be client, server and client+server.

NFS (Network File System) Main goal of NFS protocol: –NFS protocol designed without states. That’s why it’s very easy to recover server or client, because there are no states for them. –NFS designed to support UNIX file system semantic, but protocol design can be adopted to support any file system semantic –Security and access check mechanisms based on Unix UID and GID mechanism.

NFS (Network File System) NFS constrains: –NFS protocol works good on high speed networks, but works no so good on slow links. –Works not good when NFS connected with gateways in the middle and using UDP protocol. –Not very good for mobile and long time calculations without accessing NFS server. –Cache design implemented, that not very much files are used together same time. If it is so, performance may decrease –As NFS doesn’t have states, then file system locks (flock()) should be implemented using different daemons

Remote procedure call Client/server architecture

Client-server architecture Client sends a request, server replies w. a response –Interaction fits many applications –Naturally extends to distributed computing Why do people like client/server architecture? –Provides fault isolation between modules –Scalable performance (multiple servers) –Central server: Easy to manage Easy to program

Remote procedure call A remote procedure call makes a call to a remote service look like a local call –RPC makes transparent whether server is local or remote –RPC allows applications to become distributed transparently –RPC makes architecture of remote machine transparent

Developing with RPC 1.Define APIs between modules Split application based on function, ease of development, and ease of maintenance Don’t worry whether modules run locally or remotely 2.Decide what runs locally and remotely Decision may even be at run-time 3.Make APIs bullet proof Deal with partial failures

RPC protocol Guarantee at-most-once semantics by tagging requests and response RPC request header: –Request once –Service Identifier –Call identifier Protocol: –Client resends after time out –Server maintains table of nonces and replies

RPC transport Use reliable transport layer –Flow control –Congestion control –Reliable message transfer Combine RPC and transport protocol –Reduce number of messages RPC response can also function as acknowledgement for message transport protocol