Your SlideShare is downloading. ×
Katz, Stoica F04 EE122: DNS and the Web
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Katz, Stoica F04 EE122: DNS and the Web

727
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
727
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. EE122: DNS and the Web (after a little more multicast) October 27, 2003
  • 2. EECS 122: Introduction to Computer Networks DNS and WWW Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776
  • 3. Barriers to Multicast
    • Hard to change IP
      • multicast means change to IP
      • details of multicast were very hard to get right
    • Not always consistent with ISP economic model
      • charging done at edge, but single packet from edge can explode into millions of packets within network
    • Troublesome security model
      • Anyone can send to a group
      • Denial-of-service attacks on known groups
  • 4. Application Layer Multicast (ALM)
    • Let the hosts do all the “special” work
      • only require unicast from infrastructure
    • Basic idea:
      • hosts do the copying of packets
      • set up tree between hosts
    • Example: Narada [Yang-hua et al, 2000]
      • Small group sizes <= hundreds of nodes
      • Typical application: chat
  • 5. Narada: End System Multicast Stanford CMU Stan1 Stan2 Berk2 “Overlay” Tree Gatech Berk1 Berkeley Gatech Stan1 Stan2 CMU Berk1 Berk2
  • 6. Algorithmic Challenge
    • Choosing replication/forwarding points among hosts
      • how do the hosts know about each other
      • and know which hosts should forward to other hosts
  • 7. Advantages of ALM
    • No need for changes to IP or routers
    • No need for ISP cooperation
    • End hosts can prevent other hosts from sending
    • Easy to implement reliability
      • use hop-by-hop retransmissions
  • 8. Performance Concerns
    • Stretch
      • ratio of latency in the overlay to latency in the underlying network
    • Stress
      • number of duplicate packets sent over the same physical link
  • 9. Performance Concerns Duplicate Packets: Bandwidth Wastage CMU Stan1 Stan2 Berk2 Gatech Berk1 Delay from CMU to Berk1 increases Stanford Berkeley Gatech Stan1 Stan2 CMU Berk1 Berk2
  • 10. Single Sender Multicast
    • Many problems with IP multicast disappear if each group is associated with a single source
    • Hosts joining multicast group can send join messages to source
      • this sets up delivery tree
      • no worry about “root” being in wrong place
    • This solves several problems:
      • better security and charging model
      • simple algorithm
  • 11. Example
    • Group members: M1, M2, M3
    source M1 M2 M3 control (join) messages data
  • 12. What’s Wrong with SSM?
    • Multiple sources?
      • can set up group per source, or...
      • source can serve as relay for other senders
    • Algorithm?
      • trivial
    • So, why isn’t SSM the answer?
      • multicast no longer serves as “rendezvous”
      • ok for “broadcast” apps, not good for “meeting” apps
  • 13. What Do You Need to Know?
    • DVRMP
    • CBT
    • SSM
    • How they compare
  • 14. Today’s Lecture: 17 Network (IP) Application Transport Link Physical 2 7, 8, 9 10,11 17 , 18, 19 14, 15, 16 21, 22, 23 25 6
  • 15. Internet Names & Addresses
    • Names: e.g. ariachne.berkeley.edu
      • human-usable labels for machines
      • conforms to “organizational” structure
    • Addresses: e.g. 169.229.131.109
      • router-usable labels for machines
      • conforms to “network” structure
    • How do you map from one to another?
      • Domain Name System (DNS)
  • 16. DNS: History
    • Initially all host-addess mappings were in a file called hosts.txt (in /etc/hosts)
      • Changes were submitted to SRI by email
      • New versions of hosts.txt ftp’d periodically from SRI
      • An administrator could pick names at their discretion
    • As the internet grew this system broke down because:
      • SRI couldn’t handled the load
      • Names were not unique
      • Many hosts had inaccurate copies of hosts.txt
    • Internet growth was threatened!
      • Domain Name System (DNS) was born
  • 17. Basic DNS Features
    • Hierarchical namespace
      • as opposed to original flat namespace
    • Distributed storage architecture
      • as opposed to centralized storage (plus replication)
    • Client--server interaction on UDP Port 53
      • but can use TCP if desired
  • 18. Naming Hierarchy
    • “ Top Level Domains” are at the top
    • Depth of tree is arbitrary (limit 128)
    • Domains are subtrees
      • E.g: .edu, berkeley.edu, eecs.berkeley.edu
    • Name collisions avoided
      • E.g. berkeley.edu and berkeley.com can coexist, but uniqueness is job of domain
    root edu com gov mil org net uk fr berkeley mit eecs sims argus etc.
  • 19. Host names are administered hierarchically
    • A zone corresponds to an administrative authority that is responsible for that portion of the hierarchy
    • eecs controls names: x.eecs.berkeley.edu
    • berkeley controls names: x.berkeley.edu and y.sims.berkeley.edu
    root edu com gov mil org net uk fr berkeley mit eecs sims argus root edu com gov mil org net uk fr berkeley eecs sims
  • 20. Server Hierarchy
    • Each server has authority over a portion of the hierarchy
      • A server maintains only a subset of all names
    • Each server contains all the records for the hosts in its zone
      • might be replicated for robustness
    • Each server needs to know other servers that are responsible for the other portions of the hierarchy
      • Every server knows the root
      • Root server knows about all top-level domains
  • 21. DNS Name Servers
    • Local name servers:
      • Each ISP (company) has local default name server
      • Host DNS query first goes to local name server
    • Authoritative name servers:
      • For a host: stores that host’s (name, IP address)
      • Can perform name/address translation for that host’s name
    • Can also do IP to name translation, but won’t discuss
  • 22. 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
    • ~ Dozen root name servers worldwide
  • 23. Simple DNS Example
    • Host whistler.cs.cmu.edu wants IP address of www.berkeley.edu
    • 1. Contacts its local DNS server, mango.srv.cs.cmu.edu
    • 2. mango.srv.cs.cmu.edu contacts root name server, if necessary
    • 3. Root name server contacts authoritative name server, ns1.berkeley.edu, if necessary
    requesting host whistler.cs.cmu.edu www.berkeley.edu root name server authorititive name server ns1.berkeley.edu 1 2 3 4 5 6 local name server mango.srv.cs.cmu.edu
  • 24. Example of Recursive DNS Query
    • Root name server:
    • May not know authoritative name server
    • May know intermediate name server : who to contact to find authoritative name server?
    • Recursive query:
    • Puts burden of name resolution on contacted name server
    • Heavy load?
    requesting host whistler.cs.cmu.edu www.berkeley.edu root name server 1 2 3 4 5 6 authoritative name server ns1.berkeley.edu 7 8 local name server mango.srv.cs.cmu.edu intermediate name server (edu server)
  • 25. Example of Iterated DNS Query
    • Iterated query:
    • Contacted server replies with name of server to contact
    • “ I don’t know this name, but ask this server”
    requesting host whistler.cs.cmu.edu www.berkeley.edu root name server 1 2 3 4 6 7 authoritative name server ns1.berkeley.edu 5 8 iterated query local name server mango.srv.cs.cmu.edu intermediate name server (edu server)
  • 26. DNS Records
    • Four fields: (name, value, type, TTL)
    • Type = A:
      • name = hostname
      • value = IP address
    • Type = NS:
      • name = domain
      • value = name of dns server for domain
  • 27. DNS Records (cont’d)
    • Type = CNAME:
      • name = hostname
      • value = canonical name
    • Type = MX:
      • name = domain in email address
      • value = canonical name of mail server
  • 28. DNS as Indirection Service
    • Can refer to machines by name, not address
      • not only easier for humans
      • also allows machines to change IP addresses without having to change way you refer to machine
    • Can refer to machines by alias
      • www.berkeley.edu can be generic web server
      • but DNS can point this to particular machine that can change over time
    • But, this flexibility applies only within domain!
  • 29. Special Topics
    • DNS caching
      • improve performance by saving results of previous lookups
    • DNS “hacks”
      • return records based on requesting IP address
    • dynamic DNS
      • allows remote updating of IP address for mobile hosts
    • DNS politics (ICANN) and branding battles
  • 30. Important Properties of DNS
    • Administrative delegation and distributed server architecture results in:
    • Easy unique naming
    • Fate sharing for network failures
    • Reasonable trust model
  • 31. The Web
    • A distributed database of “pages”
    • Core components:
      • Servers: store files and execute remote commands
      • Browsers: retrieve and display “pages”
      • URLs: way to refer to pages
    • Need a protocol to transfer information between clients and servers
      • HTTP
  • 32. Uniform Record Locator
    • protocol://host-name:port/directory-path/resource
    • Extend the idea of hierarchical namespaces to include anything in a file system
      • ftp://www.eecs.berkeley.edu/122/Lecture6/presentation.ppt
    • Extend to program executions as well…
      • http://us.f413.mail.yahoo.com/ym/ShowLetter?box=%40B%40Bulk&MsgId=2604_1744106_29699_1123_1261_0_28917_3552_1289957100&Search=&Nhead=f&YY=31454&order=down&sort=date&pos=0&view=a&head=b
      • Server side processing can be incorporated in the name
  • 33. Web and DNS
    • URLs use hostnames
    • Thus, content names are tied to specific hosts
    • This is bad!
    • URNs are one proposal to achieve persistence
  • 34. Hyper Text Transfer Protocol
    • Client-server architecture
    • Synchronous request/reply protocol
      • Runs over TCP, Port 80
    • Stateless
    • Uses unicast
  • 35. Big Picture Client Server TCP Syn TCP syn + ack TCP ack + HTTP GET Establish connection Request response Client request Close connection . . .
  • 36. Hyper Text Transfer Protocol Commands
    • GET – transfer resource from given URL
    • HEAD – GET resource metadata (headers) only
    • PUT – store/modify resource under given URL
    • DELETE – remove resource
    • POST – provide input for a process identified by the given URL (usually used to post CGI parameters)
  • 37. Response Codes
    • 1x informational
    • 2x success
    • 3x redirection
    • 4x client error in request
    • 5x server error; can’t satisfy the request
  • 38. Client Request
    • Steps to get the resource: http://www.eecs.berkeley.edu/index.html
      • Use DNS to obtain the IP address of www. eecs . berkeley . edu
      • Send to an HTTP request:
    GET /index.html HTTP/1.0
  • 39. Server Response HTTP/1.0 200 OK Content-Type: text/html Content-Length: 1234 Last-Modified: Mon, 19 Nov 2001 15:31:20 GMT <HTML> <HEAD> <TITLE>EECS Home Page</TITLE> </HEAD> … </BODY> </HTML>
  • 40. Example (from Kurose and Ross)
    • http://www.mylife.org/mypictures.htm
    • After finding out the IP address of the host…
    • http client initiates a TCP connection on :80
    • Client sends the get request via socket established in 1
    • Server sends the html file, which is encapsulated in its response
    • http server tells tcp to terminate connection
    • http client receives the file and the browser parses it…contains ten jpeg images
    • Client repeats steps 1-4
  • 41. HTTP/1.0 Example Client Server Request image 1 Transfer image 1 Request image 2 Transfer image 2 Request text Transfer text Finish display page
  • 42. HHTP/1.0 Performance
    • Create a new TCP connection for each resource
      • Large number of embedded objects in a web page
      • Many short lived connections
    • TCP transfer
      • Too slow for small object
      • May never exit slow-start phase
    • Connections may be set up in parallel (5 is default in most browsers)
  • 43. HTTP/1.0 Caching
    • Exploit locality of reference
    • A modifier to the GET request:
      • If-modified-since – return a “not modified” response if resource was not modified since specified time
    • A response header:
      • Expires – specify to the client for how long it is safe to cache the resource
    • A request directive:
      • No-cache – ignore all caches and get resource directly from server
    • These features can be best taken advantage of with HTTP proxies
      • Locality of reference increases if many clients share a proxy
  • 44. Web Proxies
    • Intermediaries between client and server
    Client 1 Proxy Proxy Server Client 2 Client N . . .
  • 45. HTTP/1.1 (1996)
    • Performance:
      • Persistent connections
      • Pipelined requests/responses
    • Support for virtual hosting
    • Efficient caching support
      • Network Cache assumed more explicitly in the design
      • Gives more control to the server on how it wants data cached
  • 46. Persistent Connections
    • Allow multiple transfers over one connection
    • Avoid multiple TCP connection setups
    • Avoid multiple TCP slow starts
  • 47. Pipelined Requests/Responses
    • Buffer requests and responses to reduce the number of packets
    • Multiple requests can be contained in one TCP segment
    • Note: order of responses has to be maintained
    Client Server Request 1 Request 2 Request 3 Transfer 1 Transfer 2 Transfer 3
  • 48. What You Need to Know
    • DNS: record types, and how they are used
    • HTTP basics (and essential differences between 1.0 and 1.1)
  • 49. What’s the Moral of this Story?
    • QoS and IP Multicast:
      • interesting algorithmic and architectural issues
      • thousands of academic papers
      • ubiquitous in routers, but not deployed by ISPs
      • little or no impact on end users
    • DNS and the Web:
      • no research papers on topic before deployment
      • really boring designs
      • they changed the world....