Administrivia Naming Domain Name System _DNS_ Challenges and Concerns
Document Sample


A-PDF Watermark DEMO: Purchase from www.A-PDF.com to remove the watermark
1
2
• Feedback forms today; please remind me 15 mins early
– Please do the online SOOTs on blacboard
Administrivia
Naming
End point admission control paper
∗ A set of Name to value bindings
∗ Define membership in a group
∗ Yellow pages vs. white pages
∗ What are they used for?
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23
Weighted Fair Queueing
∗ Help locate objects
– What do names do?
Integrated Services
– Directory services
∗ Identify objects
∗ Specify a role
Leaky Bucket
• Last time– QoS
• Overview
–
–
–
–
Domain Name System (DNS) Challenges and Concerns
User 1
2
cs.princeton.edu user @ cs.princeton.edu
Name Mail
• Challenges
server program
– How to build a directory system for the whole
192.12.69.5 4
192.12.69.5 internet?
3
TCP – Can you suggest some approaches (dumb or
otherwise)?
192.12.69.5 5
∗ HOSTS.txt – until mid-1980s
IP – Is there a phone directory for the whole world?
• Concerns/Requirements
• Scalable directory services protocol for the
– Ease of administration
Internet
– Availability
• Berkeley Internet Name Domain (bind) on unix – Scalability
machines – Security
– Extensibility
• Most common use: directory service to map from
host name to IP address
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 3 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 4
Name Server DNS
• Each server maintains a collection of resource records (RR) • The naming system for the Internet
– highly successful
• Each record: (Name, Value, Type, Class, TTL) – widely distributed administration
– Record indicates binding Name to Value – good for long-lived, static information
– Type specifies the type of binding – not extensible
– Class allows other entities to define types – simple API
– TTL: how long the record is valid for
• Name Servers and Resolvers
– Name servers are the directory databases
– Resolvers generate the queries that do the lookup (tree walk)
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 7 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 5
ux01 ux04
• Each zone supported by two or more name
• Break the domains into zones
• Idea: use a hierarchy of domains; hosts defined
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23
cs
servers (why?)
within a domain
– Secondary polls primary for updates
– Primary and secondary are exact copies of
– Each zone administered independently
Domain Name System Hierarchy
each other
princeton … mit
Resource Record Types
ee
physics
edu
cisco … yahoo nasa … nsf
com
• A: Value gives the 32-bit IPv4 address
• PTR: value gives hostname for the IP address in the name field
gov
• NS: Value is the name for the host running the name server that
knows how to resolve names within the specified domain name
arpa … navy
• CNAME: provides canonical name for specified host; used for aliases
mil
• MX: value gives the name for the host running mail server that
acm … ieee
accepts messages for the specified domain
org
• Not easily extensible; everyone must agree on changes
net
uk
fr
6
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 8
Server Hierarchy MX Example
• At the top level is the root domain managed by a set of root name • When you send mail to nael@opal.cs.binghamton.edu
servers • Mail program queries DNS for an MX record for opal
• The following info is returned (I used nslookup, querytype=mx):
– Give a starting point to the full DNS database
– Thirteen servers distributed all over the world; why not just two? opal.cs.binghamton.edu canonical name = cs.binghamton.edu
– Manages top level domains such as .edu, .com, .net and .org cs.binghamton.edu preference = 0, mail exchanger = cs.bing...
– Also manages geographical (country) domains such as .us, .in, cs.binghamton.edu internet address = 128.226.123.101
and even .jo cs.binghamton.edu name server=bingnet1.cc.binghamton.edu
– US domains are maintained by the Network Information Center
• These correspond to:
(InterNIC)
– (opal.cs.binghamton.edu,cs.binghamton.edu,CNAME,IN)
• Next level is middle-level domains like binghamton.edu and
– (cs.binghamton.edu,cs.binghamton.edu,MX,IN)
yahoo.com – (cs.binghamton.edu,128.226.123.101,A,IN)
• Where do the root name servers get their information? – (cs.binghamton.edu,bingnet1...,NS,IN)
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 11 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 9
Name Resolution Name Resolution – Server Hierarchy
Root
2
name
server Root
u
.ed name server
ton
rince .2 33
.cs.p 128 3
ada 96.
cic 8.1
du , 12
to n.e
nce 4
1 pri Princeton … Cisco
cicada.cs.princeton.edu Local cicada.cs.princeton.edu Princeton name server name server
Client name name
192.12.69.60 server cs.princeton.edu, 192.12.69.5 server
8 5
cic
ad CS EE
cic a.c
s.p
…
19 ada. rin name server name server
2.1 cs. cet
2.6 pri on
9.6 nce .ed
0 ton u 6
.ed
u,
CS • Each zone managed by its own name server
name
7 server
• Should the name server include the full directory?
• Site-wide cache to speed up resolution of frequently used names
• Server hierarchy provides scalability and distributed management
• gethostbyname() and gethostbyaddr()
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 12 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 10
Aside: DNS Cache Poisoning Caching and Replication
• Spoofing attack (security next time)
• 13 root servers (top level servers)
• Mallory (man-in-the-middle) asks its DNS server for the address of
hotmail.com – Recently, there was a denial of service attack on those
• DNS server recursively sends the request to dns.hotmail.com – What would happen if the attack was successful?
• Before it can answer, Mallory spoofs the answer telling the DNS • Caching: to reduce DNS traffic, each resolution is cached locally
server that hotmail.com is his own machine
– Recommended TTL for hosts is 2 days
• Users now connect to Mallory instead of hotmail.com and volunteer
– Record specifies TTL field (can set it to 0 if no caching is desired)
their passwords
• Solution: authenticate DNS replies/updates
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 15 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 13
• Core operation in p2p applications: finding data
• Peer-to-peer applications can provide
• Chord: general lookup service for peer-to-peer
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23
applications
– Why not use DNS?
– Given a key, find the value corresponding to it
–
–
–
–
–
– Permenance (your stuff available when you are
– redundant storage
hierarchical naming
authentication
search
anonymity
anycast
disconnected)
Who are you – reverse DNS
• the domain in-addr.arpa provides reverse mapping
Chord Paper
• Used by servers to figure out who is connecting to them
• Records of type PTR
• nslookup with querytype=ptr on 128.226.123.101
101.123.226.128.in-addr.arpa name = cs.binghamton.edu
123.226.128.in-addr.arpa nameserver = bingnet1.cc.binghamton.edu
...
• Dynamic DNS
16
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 14
Aside: SETI@home Why not DNS
• Largest and best known peer-to-peer computing project • Presumes structure: permenant nodes in a hierarchy, root servers,
etc...
• SETI: Search for Extraterrestrial Intelligence
• Requires manual management of routing information (NS records)
– Gobs of data from radio telescopes need to be analyzed
• Requires naming structure (nodes in .edu zones have to end with
– No one will fund them, cant buy computing resources
.edu)
• Big success:
• Updates difficult, dynamic DNS here but optional and not everywhere
– Around 4 mil. clients downloaded • For P2P:
– Total CPU time: 1246848 years! 54.8 TFLOPS
– ASCI RED (biggest supercomputing cluster) is 12 TFLOPS with – Hosts can come and go
cost $100 million – No host hierarchy
– Get your own copy: http://setiathome.ssl.berkeley.edu/ – No naming structure
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 19 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 17
Searching in Peer-2-Peer Networks Some Peer to Peer Applications
• What possible ways are there to organize a P2P network? • Cooperative Mirroring: content providers cache each other’s data –
provide load balancing (plan for average rather than peak)
– Napster – centralized index
– Gnutella – flood the “overlay network”, get responses • Time-shared storage: if intermittently connected, someone else can
make your “stuff” available. When you are connected, you make
• Neither is scalable, especially given the resolution and update theirs available in return
frequency
• Distributed index: finding data based on keyword input as in
• How do we carry out such generalized resolution in such a dynamic Napster/Gnutella
network?
• Embarrasingly parallel applications (e.g., breaking code, SETI@home)
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 20 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 18
Classifying Peer to Peer Networks Searching in Decentralized
Unstructured P2P Networks
• Structured vs. Unstructured • Example: (the old) Gnutella
– Unstructured: data can be stored anywhere
– Structured: data has to be stored at a specific • Basically, we have no idea where the data is;
place (e.g., according to a hash function) devolves to random search
– Terms of Data and Network Structure
– What is the tradeoff? • Some approaches (assume existence of overlay
network connecting nodes)
• Centralized vs. Decentralized – Flood
– Expanding Ring
– Centralized support or no centralized support
– Random Walkers
– For indexing and for joining/leaving
– Keep score of replies you receive from
neighbors – use highest scores on similar
searches
– Local indices
– Replication of popular search items
– ...
• What if centralized unstructured?
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 21 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 22
Structured P2P Chord Protocol
• Enforce a structure on the network, Typically
using Distributed Hash Tables (DHT)
• A DHT is a hash table where each node is
responsible for a portion of the hash space
– A data item is placed at the node responsible
for the hash value for its search key
∗ Search key is predetermined – cannot do
general searches
• Key idea:
– Finding a data item is quick – we know where
its stored! – Arrange the nodes in a logical circle, where
∗ But how do we know the responsible node? every node knows its successor node
∗ What happens as nodes join and leave? ∗ Pass the request along the circle until
someone replies
∗ Very slow: O(N) messages needed, sequental
resolution
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 23 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 24
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23
– Joins/Stabilization in the background to keep
– Keep track of your power-of-2 successors in a
– Use consistent hashing to map the key to a node
∗ log N entries per node; O(Log N) messages
∗ Each node is responsible for the keys that hash
pointers current
routing table
Main Improvement – Use Routing
Other Ideas and Open Problems
needed to resolve
to the range [predecessor,id)
• Other Structured Organizations have been studied
– DHT based: CAN (Hypercube), Tapestry (Plaxon Tree), Debruijn
Pointers
Network, XOR Network, ...
– Skip Lists
– SIGCOMM 2003 paper argues that ring is best from a robustness
perspective
• Loosely structured (super-peers that are structured)?
• Incentives for participation?
• Freenet, BT...
25
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 27
Internet Indirection Infrastructure Paper Discussion
• Contribution: a generic indirection overlay architecture • Structured vs. unstructured
– Decouples sending from receiving
• Hash is random, neighbors may be very far from each other
– Receivers install triggers for addresses they want to receive from
– Senders send to an address
– Packet is forwarded to all triggers associated with the address • What about restricting where the data goes (e.g., for security
reasons?)
• Paper shows how such an architecture can be used for mobility,
multicast, anycast and service composition
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 28 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 26
Supporting Mobility Multicast and Anycast I3 – API
• Rendevous based communication model
1. sendPacket(p)
2. insertTrigger(t)
3. removeTrigger(t)
• How is it implemented?
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 31 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 29
Key Generalization Match Rules
• Stackable Identiers • Packet represented as pair (id, data)
– an id-list generalization discussed later
• Packet p = (idstack , data)
– Sends a packet to a series of identifiers • Assume identifier is m-bits long
– Similar to source routing
• exact match threshold is k, k < m
• Trigger t = (id, idstack )
• A packet id matches a trigger id (idt) if
– Sends packet to another identifier instead of just address
– id and idt have a prefix match of at least k bits
• Their examples are a little confusing – There is no trigger with a longer prefix match
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 32 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 30
Implementation Supporting Service Composition – Heterogeneous
Multicast Example
• Need a robust, stable, scalable and efficient overlay network
• They implement on top of Chord
– Lookup key hashes to a unique “server” that acts as the rendevous
point.
– Look up and execute the trigger at the server
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 35 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 33
Security Issues Chains of Triggers Example – Hierarchical MCast
• Eavesdropping: Can subscribe to somebody else’s trigger
– Use private triggers; low probability of intercept – have to guess
the trigger
∗ Is this really true? What if we figure out where the packets are
going?
– Change these triggers periodically
– Use multiple trigger servers, and send to them randomly
• Trigger hijacking; install your own trigger to replace a valid one (e.g.,
replace the public trigger for a host so you get all its traffic)
• DoS attacks
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 36 SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 34
Performance Issues
• They use simulation to study performance penalties and issues
• Problem, Chord performance may be bad for the initial lookup; even
though O(log(N)) lookups only, the location of the servers can be all
over the place
– They cache multiple successors for each next hop and choose the
one that is closest in network distance
• Overall, “latency stretch” relative to native IP can be lowered to 1.5–2
(90th percentile) A-to-S-to-R
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 37
Discussion
• What lessons can we learn from this paper?
• Fundamentally, what is it that is being proposed?
• How does it relate to other works we saw? Mobility, Multicast ...
• How will this perform?
• On the face of it, it seems that major “triangulation problems” can
occur
• Can anything be done to help?
SUNY-B INGHAMTON – CS528 FALL ’05 L EC. #23 38
Related docs
Get documents about "