Computer Science 425 Distributed Systems

1
Computer Science 425Distributed Systems

• Lecture 14
• NETWORKING Part III (DNS Service and Firewalls)
• DNS Service 3.4.7 9.2
• Firewalls 3.4.8

2
DNS Domain Name System

• Domain Name System
• distributed database implemented in a hierarchy
  of many name servers
• application-layer protocol that is responsible
  for resolving names (address/name translation)

• People many identifiers
• SSN, name, Passport
• Internet hosts, routers
• IP address (32 bit) - used for addressing
  datagrams
• Resource name, e.g., URL sal.cs.uiuc.edu
  human-readable format
• Q given a resource name, how does a client find
  out the IP address of the service/server?

3
DNS Name Servers

• Alternative
• no server has all name-to-IP address mappings
• Hierarchy of name servers
• authoritative name server
• for a resource, stores the mapped IP address for
  that resource
• local name servers
• each institution/company/ISP owns a local
  (default) name server
• host DNS query first goes to local name server
• local name server might be caching an answer

• Why not have a central DNS server?
• single point of failure
• traffic volume
• may be far
• maintenance difficult
• doesnt scale!
• (WWW contains several billion pages today)

4
DNS Root Name Servers

• contacted by local name server that can not
  resolve name
• root name server
• contacts authoritative name server if name
  mapping not known
• gets mapping
• returns mapping to local name server
• 12 root-server operators worldwide
• (http//www.root-servers.org)

5
Simple DNS Example
root name server
2
4

• host surf.eurecom.fr wants IP address of
  dragon.cs.uiuc.edu
• 1. Contacts its local DNS server, dns.eurecom.fr
• 2. dns.eurecom.fr contacts root name server, if
  necessary
• 3. root name server contacts authoritative name
  server, dns.cs.uiuc.edu, if necessary
• Answer returned by first server that is caching
  the mapping tuple

3
5
authoritative name server dns.cs.uiuc.edu
1
6
dragon.cs.uiuc.edu
requesting host surf.eurecom.fr
6
DNS Example
root name server

• Root name server
• may not know the authoritative name server
• may know intermediate name server whom to
  contact to find authoritative name server
• Hierarchy
• .
• .edu .com .mil
• uiuc.edu mit.edu

6
2
3
7
5
4
1
8
authoritative name server dns.cs.uiuc.edu
requesting host surf.eurecom.fr
dragon.cs.uiuc.edu
7
DNS Iterated Queries
root name server

• recursive query
• puts burden of name resolution on servers along
  the way
• may fail if a server does not know next server to
  contact
• iterated query
• contacted server replies with name of server to
  contact
• I dont know this resource name, but ask this
  other server
• takes longer (more replies) but gives client more
  control

iterated query
2
3
4
7
5
6
1
8
authoritative name server dns.cs.uiuc.edu
requesting host surf.eurecom.fr
dragon.cs.uiuc.edu
8
DNS Caching and Updating Records

• once (any) name server learns mapping, it caches
  mapping
• cache entries timeout (disappear) after some time
• update/notify mechanisms
• RFC 2136
• http//www.ietf.org/html.charters/dnsind-charter.h
  tml
• Akamai uses this extensively
• Interesting comparison between DNS and DHT in
  Chord see paper
• Comparative Study of the DNS Design with
  DHT-based Alternatives, Pappas et al., INFOCOM
  2006.

9
Firewalls

• A set of processes that monitor control all
  comm. into and out of an intranet, for
• Service control
• Behavior control
• User control
• Firewall filtering can be done at diff. levels
  of protocol stack
• IP packet filtering
• E.g., disallow packets from certain IP addresses
• TCP gateway filtering
• E.g., check format of TCP packets to avoid
  attacks using malformed TCP packets
• Application gateway filtering
• E.g., web proxy

10
Firewall Configurations

• For efficiency reasons, IP filtering
• done in kernel
• Separated from other filtering

TCP and appl filtering

• - Hosts in intranet
• need not know IP addresses of
• hosts in external network,
• and vice-versa
• Double-walled protection

11
Summary on Networking

• Structure of the Internet
• Protocol stacks (e.g., OSI 7 layer, 5 layer)
• IP packet format
• ARP, DNS
• Routing algorithms distance vector, link state,
  proactive, reactive
• TCP
• Firewalls
• Structure constantly evolving with new networks
  and standards (e.g., data over cellphones, IPv6)

12

• Inter-process Communication Distributed Objects
  (I)
• Sections 4.3-4.4, Chapter 5

13
Search in Chord
What are RPCs?
At node n, send query for key k to largest
successor/finger entry lt k if none exist, return
successor(n) to requestor
Say m7
0
N16
N112
All arrows are RPCs
N96
N32
Who has bad.mp3? (hashes to K42)
File bad.mp3 with key K42 stored here
N45
N80
14
Bank Database Example
How are transactions executed between a client
ATM and a bank server?

• Bank Database Think of two simultaneous deposits
  of 10,000 into your bank account, each from one
  ATM.
• Both ATMs read initial amount of 1000
  concurrently from the bank server
• Both ATMs add 10,000 to this amount (locally at
  the ATM)
• Both write the final amount to the server
• Whats wrong?
• The ATMs need mutually exclusive access to your
  account entry at the server

15
Middleware Layers
RMIRemote Method Invocation CORBACommon Object
Request Brokerage Architecture
16
Local Objects

• Object
• consists of a set of data and a set of methods.
• E.g., C object such as the Chord object (Chord
  data structures functions at a node).
• Object reference
• an identifier via which objects can be accessed.
• i.e., a pointer
• Interface
• provides a definition of the signatures of a set
  of methods (i.e., the types of their arguments,
  return values, and exceptions) without specifying
  their implementation.
• E.g., put(objectname), get(objectname) API for
  Chord object. Same API also applies to other
  objects such as Gnutella, Kazaa, etc.

17
Remote Objects

• Remote method invocation (RMI)
• method invocations between objects in different
  processes (processes may be on the same or
  different host).
• Variant of Remote Procedure Call (RPC), which is
  between different processes (may be on same or
  different host)
• Remote objects
• objects that can receive remote invocations.
• Remote object reference
• an identifier that can be used globally
  throughout a distributed system to refer to a
  particular unique remote object.
• Remote interface
• Every remote object has a remote interface that
  specifies which of its methods can be invoked
  remotely. E.g., CORBA interface definition
  language (IDL)

18
A Remote Object and Its Remote Interface
Example Remote Object reference(IP,port,objectnum
ber,signature,time)
19
Remote and Local Method Invocations
Process
Object
Process
Process
Host A
Host B
Local invocationbetween objects on same
process. Has exactly once semantics Remote
invocationbetween objects on different
processes. Ideally also want exactly once
semantics for remote invocations But difficult
(why?)
20
Failure Modes of RMI/RPC
(and if request is received more than once?)

Request

Execute
lost request
correct function
Reply
Channel fails during reply
Execute
Request
Execute, Crash
crash before reply
Reply
Client machine fails before receiving reply
Request
Execute
Crash
crash before execution
Reply
21
Invocation Semantics
Transparencyremote invocation has same behavior
as local invocation Birrell and Nelson,
inventors of RPC, 1984 Very difficult to
implement in asynchronous network
whether to keep a history of result messages to
enable lost results to be retransmitted
without re-executing the operations
Whether or not to retransmit the request message
until either a reply is received or the server is
assumed to be failed
when retransmissions are used, whether to filter
out duplicate requests at the server.
CORBA
(ok for idempotent operations)
Sun RPC
Java RMI
Idempotentsame result if applied repeatedly
22
Proxy and Skeleton in Remote Method Invocation
Process P2
Process P1
MIDDLEWARE
23
Proxy and Skeleton in Remote Method Invocation
Process P2 (server)
Process P1 (client)
24
Summary

• Inter-process communication
• Remote method invocation
• Local and remote objects
• Distributed objects
• Next lecture distributed objects and RPC
• Read Section 5
• MP1 is out, deadline 10/26
• start early you have 2 ½ weeks two days (48
  hours) as grace period, so desired deadline
  October 26 (midnight), hard-hard deadline October
  28 (midnight)